Мы живем в эпоху крупных перемен в сообществе WordPress – вышел релиз Calypso, прошел первый успешный форум WordCamp US, а сама система WordPress охватила 25% всех сайтов сети. Развитие WP REST API ознаменовало собой отделение уровня управления контентом от уровня его отображения, что напрямую повлияло на повсеместное принятие и внедрение этой возможности; крупные компании теперь могут писать свой код, который будет подключаться через API, что позволяет обойти различные препятствия и ускорить выпуск новых функций. В то же самое время вся сеть готовится к новой метаморфозе, связанной с фундаментальными изменениями в доставке контента по HTTP/2.

Все эти разработки имеют огромный потенциал для тех из нас, кто тесно связан с WordPress. Давайте детальнее остановимся на том, что будет играть важную роль в производительности системы в будущем.

Важность использования CDN с DDoS-защитой будет расти

Не так давно мы начали тестировать на своем сайте CDN-сервис, предлагающий защиту от DDoS-атак. Несмотря на то, что наш сайт вряд ли является такой уж привлекательной целью для злоумышленников, на него все равно проводились атаки, о чем и уведомил нас данный сервис (более дюжины каждый день; иногда в два или в три раза больше). Основная масса атак – это попытки использования известных уязвимостей в плагинах WordPress (либо в других популярных веб-приложениях), которые перечислены в базе данных WP Vulnerability Database. Смягчение последствий таких атак (или хотя бы уведомление о них) на уровне CDN – очень востребованная опция для многих владельцев сайтов.

Наряду с защитой от известных уязвимостей, CDN-сервисы также позволяют приспосабливаться к резкому приросту трафика. Вместо того чтобы расширять географию своих серверов для управления экспоненциально возросшим трафиком (к примеру, когда история стала вирусной или интернет-магазин поучаствовал в Киберпонедельнике), можно просто положиться на CDN и их распределенную сеть серверов.

Сам по себе CDN не приведет к ускорению работы сайта. Более того, порой можно добиться даже обратного эффекта, если передавать свой сайт по HTTP/2, используя «лучшие практики» оптимизации сайта для HTTP 1.1.

Нужно улучшать способ взаимодействия WordPress-сайтов с CDN

Многие WordPress-сайты используют CDN или облачную систему хранения объектов во взаимозаменяемом режиме. В этом случае основной домен example.com отдается с исходных серверов, а традиционно «статичные» ресурсы (JavaScript, CSS) передаются из CDN при использовании поддомена (или нескольких поддоменов, таких как a.example.com, b.example.com и т.д. – этот процесс называется шардингом домена). Указанный подход позволяет максимизировать количество параллельных соединений, которые клиентский браузер будет использовать для загрузки ресурсов сайта, что выльется в повышение производительности, даже если CDN не будет работать быстрее, чем веб-серверы.

Иногда вместо CDN используются системы хранения объектов, такие как Amazon S3, которые снижают нагрузку с веб-серверов, сохраняют дисковое пространство, а также предлагают те же самые преимущества параллельных соединений, что и CDN. Этот плюс становится минусом, когда мы добавляем HTTP/2.

В случае с HTTP/2 отдельное TCP-соединение поддерживает полное мультиплексирование, т.е. многочисленные ресурсы могут быть параллельно переданы браузеру без необходимости создания разных поддоменов. В действительности наличие многих поддоменов негативно отражается на производительности, поскольку каждый новый поддомен требует открытия нового TCP-соединения, вместо того чтобы использовать соединение, которое уже открыто для главного домена.

Кроме того, все текущие браузерные реализации HTTP/2 требуют SSL/TLS, т.е. WordPress должен быть сконфигурирован для работы по HTTPS. Хорошие новости: HTTP/2 мультиплексирование в связке с HTTPS прекрасно работает с CDN (предполагая, что ваш CDN-провайдер предлагает HTTP/2). Соответственно, можно просто пропустить все DNS-записи главного сайта через CDN.

Этот подход дает несколько преимуществ: во-первых, вы можете использовать все плюсы CDN по снижению времени поиска DNS для ваших посетителей. Во-вторых, вы сможете все очень просто настроить, поскольку вам не нужно фильтровать URL-адреса для ваших статичных ресурсов в WordPress (зачастую достаточно указать DNS и активировать сайт в консоли CDN-провайдера). Естественно, если служба DNS CDN-провайдера перестанет работать, то ваш сайт будет недоступен, поэтому выбирайте CDN-провайдера очень тщательно.

SSL станет стандартом для WordPress-сайтов

Несмотря на то, что SSL – одна из базовых мер защиты консоли WordPress, большинство веб-ресурсов продолжают использовать HTTP для общедоступного контента. HTTP/2 станет главным толчком к полному переходу на «рельсы» SSL. Можно изучить обсуждение в блоге Make WordPress Core, где описываются конкретные шаги по подготовке к более активному внедрению SSL.

Заключение

Массовый переход к HTTP/2 и SSL в WordPress займет достаточно долгое время, однако вы можете уже сейчас сделать некоторые шаги, которые позволят подготовить ваш сайт к оптимальной работе в будущем.

1. Используйте CDN, предлагающие защиту от DDoS атак. Это поможет вам выявить и предотвратить эксплуатацию популярных уязвимостей в плагинах и темах WordPress, а также добиться хорошего выигрыша в производительности, особенно для тех посетителей, которые расположены далеко от ваших серверов в географическом плане.
2. Настройте свои сайты для использования DNS-серверов CDN-провайдера. Ваши посетители смогут воспользоваться быстрым временем поиска DNS. Кроме того, вы сможете сократить общее количество TCP-соединений при использовании HTTP/2. Также вы можете по-прежнему обращаться к шардингу для достижения оптимальной производительности по HTTP1.
3. Убедитесь в том, что ваш CDN-провайдер поддерживает HTTP/2. Поскольку HTTP/2 требует SSL, вы должны убедиться в том, что ваш CDN поддерживает SSL (цены и опции могут варьироваться, поэтому обязательно проведите свой анализ). Сегодня многие провайдеры предлагают SAN-сертификаты по выгодным ценам (т.е. один сертификат может использоваться для многочисленных доменов).
4. Подготовьте ваши темы и плагины к переходу на SSL. Как только вы убедитесь в том, что ваш сайт корректно функционирует по SSL (вам придется убрать некоторые прописанные в коде http-адреса), вы можете переключиться на передачу вашего сайта через HTTP/2.
5. Отключите шардинг для статичных ресурсов. Тут вам придется решить, что лучше: удалить все шардинговые поддомены и использовать CDN с отдельным доменом (прекрасно подходит для браузеров, поддерживающих HTTP/2) или по-прежнему обращаться к поддоменам, чтобы избежать низкой производительности в старых браузерах.

Источник: 10up.com