# Как работает этот блог - Часть 3
> Как устроен этот блог изнутри: Часть 3. Производительность. Сравниваем статику с WordPress под нагрузкой (спойлер: WP падает), настраиваем бесплатный HTTPS и CDN через Cloudflare.
**Published:** 2018-05-01
**Canonical:**
**Translations:** [Русский](https://grishy.dev/ru/posts/about-the-blog-3.md)
---
В прошлой статье я закончил на том, как всё это обрабатывается после генерации
Hugo. Теперь нужно как-то это показывать пользователю. И в простейшем случае это
работает. Если мы просто выложим это на GitHub Pages, то спокойно можно так жить
и не париться. Но всегда есть куда расти. Какие есть у нас проблемы:
1. **Безопасность**
2. **Кэширование**
3. **Скорость**
## Безопасность
Обычно GitHub Pages отдаёт ваши данные по [HTTP](https://ru.wikipedia.org/wiki/HTTP), они идут в открытом виде и их можно модифицировать и читать. Например, если вы сидите в кафе и читаете эту статью, то владелец Wi-Fi может встроить рекламу и мою страницу. Ведь трафик-то открыт. Как этого избежать? Зашифровать трафик или другими словами перейти на [HTTPS](https://ru.wikipedia.org/wiki/HTTPS)!
**HTTP** - (англ. HyperText Transfer Protocol - «протокол передачи гипертекста») - простой протокол передачи данных, используемый для получения информации с веб-сайтов. Этот протокол передает данные незащищенными, из-за чего данные пользователя (пароль, данные банковских карт) могут быть перехвачены злоумышленниками.
**HTTPS** - это расширения протокола HTTP, шифрующее данные. Шифрование происходит посредством протокола [SSL](https://ru.wikipedia.org/wiki/SSL) - протокола, обеспечивающего защищенную передачу информации. Протокол SSL упаковывает ваши данные в надежную зашифрованную оболочку и передает данные на сервер.
Смысл использования **HTTPS** в плане необходимости использования его на моём блоге стремится к нулю. Ну как... у меня не принимаются никакие данные от пользователя. Разве что мои странички будут точно такими же, какими я их задумал. Не появится чужой рекламы 😁.
Но у меня теперь крутая зелёная иконка рядом с именем сайта, и не будет вылезать предупреждение, что мой сайт небезопасен. Google собирается (или уже начал) выводить предупреждения, если сайт не использует HTTPS, что он небезопасен.
Поэтому после подключения к [Cloudflare](https://www.cloudflare.com/) мы подключаем SSL и включаем кэширование.
## Кэширование и скорость
Теперь хочется сравнить результат. Так как кэширования не было на GitHub Pages (или было, но на малый промежуток времени), мы кэшируем на стороне Cloudflare. Примерная схема. Справа - GitHub Pages.
Иии всё. Мы починили основные былые проблемы. А теперь я хочу углубиться в
детали и сравнения с другими. Так сказать - **покрасоваться**.
## Grishy VS Any-WordPress
В чём главное преимущество статики? Простота всего: от поддержки и настройки до
производительности. Блог у меня хостится на GitHub. Допустим, мы не хотим
использовать GitHub Pages. Не солидно. Тогда нам нужен свой сервер. Для переноса
сайта на "свои" мощности единственное, что нам надо, - скопировать файлы из
одной папки в другую.
К слову, кто не знает, что такое WordPress:
> **WordPress** — система управления содержимым сайта с открытым исходным кодом; написана на PHP; сервер базы данных — MySQL; выпущена под лицензией GNU GPL версии 2. Сфера применения — от блогов до достаточно сложных новостных ресурсов и интернет-магазинов. Встроенная система «тем» и «плагинов» вместе с удачной архитектурой позволяет конструировать проекты широкой функциональной сложности.
Он славится своей тормознутостью, дырами и тем, что он очень популярен. У нас задача - поднять свой блог. Сделаем это двумя вариантами.
1. [Как сделано 30% сайтов](https://w3techs.com/technologies/details/cm-wordpress/all/all) - WordPress
2. [Как делаю реальные пацаны](https://p.umputun.com/2015/09/11/ghost-buster-docker/) - Статика
У меня есть пара серверов в запасе. На одном я подниму блог, а на втором я буду создавать нагрузку. Генерировать много-много запросов.
Серверы небольшие по мощности, но для оценки хватит. Многие блоги на таких
хостятся. Правда, не все заморачиваются с установкой и просто используют готовые
образы. Когда ты на сайте хостера выбираешь `Хочу вордпресс`, через пару минут
тебе на почту приходит пароль от сайта.
### Static
Я сгенерировал статику у себя на компьютере, перекинул на сервер и запустил с
помощью стандартного Python HTTP-сервера. Python уже встроен по умолчанию на
всех серверах. Так что даже ничего не устанавливал.
```bash
python -m http.server 8000
```
Всё, мой сервер готов бить рекорды. Слева - сервер под нагрузкой, справа - который нагружает. Я запустил для теста на сайт 1000 пользователей одновременно.
И как видно, сервер со статическим сайтом даже **не нагружен на 100%**. Всё
упёрлось в гигабитный канал. А сайт также был доступен из браузера, только
задержка на отдачу выросла на **600ms**. Для сравнения: без нагрузки она на
уровне 30-40ms для статического сайта.
### WordPress
Установка WordPress не так проста. Там нужно установить целый список программ - [LAMP](https://ru.wikipedia.org/wiki/LAMP). Я небольшой любитель копаться в PHP, поэтому использовал Docker-контейнер. Если упростить - это установочник в мире серверов. Ты там как в Google Play выбираешь, что тебе надо, а оно само ставится тебе на сервер и устанавливает все зависимости. Также ещё и работает в изолированном пространстве. Мне не нужно будет чистить систему после теста. Я просто удалю образ, и всё. В системе не останется никаких следов. Так что же было в контейнере?
1. **Apache** - веб-сервер
2. **MariaDB / MySQL** - СУБД
3. **PHP** - язык программирования, используемый для создания веб-приложений
Скачав и установив этот не маленький контейнер, надо было сгенерировать немного контента. Иначе сайт просто будет отдавать пустую страницу. Для этого я нашёл простейший плагин для WordPress и сгенерировал 10 постов.
Больше настраивать ничего не будем, сразу в бой! И сразу провал: сайт сразу лёг
под такой нагрузкой. Не выдержала база данных. Пришлось уменьшить до 200
одновременных пользователей. Всё равно грузился по 10 секунд. При 100 уже начало
грузиться более-менее:
Без нагрузки, он отдает страницы за 1-1.2 секунды. Что не так уж и много. Для большинства сайтов это не будет критически даже близко.
## Выводы
За всё нужно платить, а если точнее, то за функциональность, большое количество
плагинов и тем WordPress расплачивается безопасностью и скоростью. Почему
безопасностью? Большая часть уязвимостей была и будет в плагинах. У них есть
полный доступ к системе, и малейшая недоработка может дать полный доступ к
сайту.
### WordPress:
#### Плюсы
- Много плагинов
- Много готовых тем
- Проще в понимании как использовать.
Про последнее, в том смысле, что там встроено подобие Word и для обычных людей это проще. Минусы вылезают из текста выше. При небольшой популярности надо ставить кэши и как-то пытаться оптимизировать. Переживать из-за безопасности. Я не раз видел, как относительно большие сайты на WordPress взламывали.
### Статика:
- Просто в плане технологий
- Самое быстрое из имеющегося
- Безопасен, что ты сделаешь файлу то
Но есть и свои минусы. Во-первых, это, как ни странно, отсутствие динамики. Не
сделать соцсеть или чат. Хотя и не для этого он. Если у вас есть информация,
которая нечасто меняется, и не нужно много контактировать с пользователем - это
ваш выбор. Также из минусов можно выделить слабую поддержку визуальных
редакторов статей. В WordPress есть встроенный редактор, где можно перетаскивать
картинки и двигать таблицы.
Тут все это тоже можно прикрутить, но так как многие "гики" просто сидят в своём редакторе, то это никто и не делает.
Хотя и тут есть свои варианты. [Та же статья от umputun'a](https://p.umputun.com/2015/09/11/ghost-buster-docker/), где использует админ панель от готовой системы и переводит это в статику. Потому что статика - это проще и безопаснее.
## CDN
Сеть доставки контента или как ее чаще называют [CDN](https://ru.wikipedia.org/wiki/Content_Delivery_Network) (Content Delivery Network) является сетью серверов по всему миру. Они помогают улучшить производительность вашего веб-сервера и уменьшают нагрузку на ваш трафик.
Суть работы очень простая. Когда пользователь обращается к содержанию вашего сайта, CDN просто перенаправляет его на географически ближайший сервер CDN, который имеет соответствующую статическую веб-страницу.
CDN нам предоставляет Cloudflare из коробки. На википедии сказано, что лучше всего это работает со статическими ресурсами. Угадайте, какой сайт на **100%** состоит из них. Сервера у меня находятся в Америке, но допустим кто-то вдруг решил посмотреть на мой сайт в Австралии. Тогда первый человек, который зайдёт на мой сайт, запросит данные у главного сервера и, получив их, сохранит локально. Дальше любой пользователь, географически близко расположенный к первому, получит данные намного быстрее. Насколько?
Как видите первый загружал значительно дольше второго. И надпись `Faster that 100% of tested sites` говорит сама за себя.
Вот так и получился у меня быстрый и безопасный блог.
Честно говоря статьи довольно скомканные, потому что сказать можно много. А хотелось уложить всего в 3 короткие статьи. Не вышло 😁.
---