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

Вольный перевод статьи

Так что мы создали список из пяти технологий, на применение которых стоит обратить внимание, чтобы улучшить и производительность, и безопасность сайта. Итак, быстрый взгляд на темы, которые мы рассмотрим:

• Let’s Encrypt (SSL)
  Бесплатный способ получить SSL-сертификат для улучшенной безопасности и производительности.
• HTTP/2
  Потомок протокола HTTP 1.1, который предлагает множество улучшений в производительности.
• Brotli сжатие
  Метод сжатия, который превосходит Gzip, выдавая меньшие размеры файлов.
• Изображения WebP
  Формат, который рендерит изображения меньше по размеру, чем классические jpeg или PNG, ускоряя загрузку.
• CDN (Content Delivery Network)
  Совокупность серверов по всему миру, которые кэшируют и доставляют ассеты сайтов быстрее.

Если вы еще не знакомы с преимуществами улучшения производительности и безопасности сайта, вспомните, что Google любит скорость и (еще с 2010 года) использует скорость загрузки сайта в качестве фактора ранжирования в поисковой выдаче. Более того, если у вас онлайн-магазин или простой блог с формой подписки на e-mail рассылку, ускорение загрузки увеличит конверсию. Согласно исследованию от Mobify, на каждые 100 мс уменьшения времени загрузки домашней страницы приходится 1.11% увеличения конверсии по клиентской базе (а теперь представим, как это скажется на выручке).

Интернет всё больше и больше склоняется в сторону SSL, чтобы обеспечить пользователей новым уровнем безопасности. Фактически, для нескольких упомянутых в этой статье технологий наличие SSL-сертификата у сайта является обязательным.

Перед тем, как начать, запомните, что даже если вы не можете (или просто не хотите) пользоваться всеми советами, представленными здесь, ваш сайт всё ещё может выиграть от реализации любого из них. Так что попытайтесь определить, что именно в вашем сайте требует улучшений, ну а дальше уже думайте, чем стоит воспользоваться.

Let’s Encrypt (SSL)

Если ваш сайт всё ещё сидит на HTTP, самое время исправить это. Google уже давно берет HTTPS во внимание при ранжировании результатов поиска; если верить блогу Google Security, все незащищенные веб-страницы в Chrome будут отображаться с плашкой “это соединение не защищено”.

Рассмотрим, как можно получить SSL-сертификат через Let’s Encrypt. Это бесплатный и автоматизированный способ получить SSL сертификат. До этого надо было оплачивать валидный сертификат от сертификационного центра, поэтому многие веб-разработчики решили не тратить дополнительные деньги и продолжили вести сайты под HTTP.

Тем не менее, со времен запуска бета-версии Let’s Encrypt (конец 2015го), были выданы миллионы бесплатных SSL-сертификатов (по утверждениям сервиса, более 100 миллионов к концу июня 2017 года). До этого через HTTPS проходили менее чем 40% веб-страниц. Спустя чуть более полтора года после запуска Let’s Encrypt это число выросло до 58%.

Если вы еще не перешли на HTTPS, сделайте это как можно быстрее. Держите несколько причин, почему этот переход выгоден:

• повышенная безопасность (потому что всё теперь шифруется);
• HTTPS необходим для работы HTTP/2 и Brotli;
• HTTPS учитывается при ранжировании поисковиком;
• SSL-защищенные сайты вызывают доверие у клиентов.

Как получить сертификат через Let’s Encrypt

Вообще, есть несколько способов. Несмотря на то, что эти сертификаты прекрасно подходят под большинство нужд, о некоторых вещах стоит знать заранее:

• Пока что wildcard сертификаты недоступны, но их поддержка планируется с января 2018 года;
• Эти сертификаты действуют в течение 90 дней, после чего их придется либо обновлять вручную, либо настроить автоматическое обновление.

Конечно, если один или оба пункта для вас — стопроцентные камни преткновения, то лучше всего будет всё же заказать SSL-сертификат от центра сертификации. Вне зависимости от выбранного провайдера, наличие HTTPS у сайта должно быть приоритетом №1.

Вернемся к Let’s Encrypt. Чтобы получить их сертификат, есть два метода на выбор:

• С доступом к SSH: запустить установку и получить сертификат самостоятельно;
• Без доступа к SSH: получить сертификат через хостинг или провайдера CDN.

Вторая опция очевидна: если ваш хостинг или CDN провайдер поддерживает Let’s Encrypt, остается лишь включить эту функцию, чтобы передавать пакеты через HTTPS.

Если у вас есть доступ к SSH и желание или необходимость настроить Let’s Encrypt самостоятельно, надо определить, каким сервером и ОС вы пользуетесь. После этого обратитесь к CertBot, выберите ваше ПО и систему из выпадающего списка, чтобы найти точную инструкцию. Хоть они для каждой комбинации ПО+ОС и разные, CertBot предоставляет простые инструкции по установке для целого спектра систем.

HTTP/2

Благодаря Let’s Encrypt (или другому центру SSL сертификации) ваш сайт уже, по идее, должен работать на HTTPS. Это значит, что теперь можно оценить на полную возможности двух оставшихся нам на разбор технологий, которые были бы недоступны для незащищенных сайтов.

Вторая технология, о которой пойдет речь — HTTP/2. HTTP 1.1 вышел более чем 15 лет назад, а с тех пор появилось много важных обновлений в сфере. Одно из самых приятных улучшений — HTTP/2 — позволяет браузерам проводить параллельно несколько загрузок через одно соединение. С HTTP 1.1 большинство ограничивалось только шестью одновременными загрузками. Помимо необходимости только в одном соединении на источник и разрешении нескольких запросов одновременно, HTTP/2 предлагает и другие преимущества:

• Push-технология
  Продвигает дополнительные ресурсы, которые, скорее всего, пригодятся клиенту в будущем;
• Сжатие заголовка
  Уменьшает размеры заголовков с использованием hpack компрессии;
• Бинарность
  В отличии от HTTP 1.1, который был текстовым, двоичность HTTP/2 экономит время перевода текста в двоичный код, что облегчает проход через сервер;
• Приоритетность
  Уровни приоритета привязаны к запросам, позволяя более важным ресурсам поступить быстрее.

Включаем HTTP/2

Вне зависимости от того, как вы подаете большую часть своего контента, будь то с сервера-источника или с CDN, большинство провайдеров сейчас поддерживают HTTP/2. Определить это можно довольно легко, зайдя на страницу с описанием и хорошо поискав там. Что касается провайдеров CDN, Is TLS Fast Yet? предлагает внушительный список CDN сервисов с указанием возможности поддержки HTTP/2.

Если вы хотите самостоятельно проверить, работает ли в данный момент ваш сайт через HTTP/2, вам понадобится только наличие последней версии cURL и введение простой команды:

curl —http2 http://вашсайт.com

На случай, если работа с командной строкой не очень комфортна, можете открыть “Инструменты разработчика” в Chrome и перейти к вкладке “Сеть”. Под строкой “Протокол” вы должны, по идее, увидеть значение “h2”.

Включаем HTTP/2 на nginx

Если вы счастливый обладатель собственного сервера, но используете при этом старую версию ПО, придется обновить его до поддерживающей HTTP/2 версии. Для пользователей nginx этот процесс очень прост. Сначала убедитесь, что вы используете nginx версии 1.9.5 и позже, и добавьте следующую директиву внутри серверного блока файла конфигурации:

listen 443 ssl http2;

Включаем HTTP/2 на Apache

Для пользователей Apache этот процесс проходит более многоступенчато. Необходимо обновить систему до версии 2.4.17 и выше, чтобы была поддержка HTTP/2. Также необходимо поставить HTTPS с модулем mod_http2, загрузить этот модуль, а потом уже определить подходящую конфигурацию сервера. Мануал по включению hhtp/2 на Apache

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

HTTP/2 vs HTTP 1.1: Тест на производительность

Можно запустить тест на производительность самостоятельно, используя онлайн тест скорости до и после включения HTTP/2 или просто проверив консоль разработчика в браузере.

Основываясь на структуре и количестве пакетов, которые прогружает ваш сайт, вы можете оценить улучшения разного уровня. Например, сайт с большим количеством ресурсов потребует несколько подключений через HTTP 1.1, тогда как через HTTP/2 требует только одно.

Результаты, приведенные ниже, получены от стандартного ресурса на WordPress с темой “2017” и 18-ю изображениями. Каждый набор настроек тестировался трижды на скорости 100 Мб/с, и окончательным результатом было взято общее среднее время загрузки. Для проверки каскадной модели этих тестов был использован Firefox.

Первый тест ниже показывает результаты для HTTP 1.1. В среднем всей странице понадобилось 1.73 секунды для полной загрузки при том, что присутствовало заблокированное время различной продолжительности.

А вот тот же сайт, но загруженный через HTTP/2 показал совсем другие результаты. На сей раз среднее время загрузки всей страницы составило 1.4 секунды, а сумма заблокированного времени была незначительной.

Простым переключением на HTTP/2 удалось в среднем сохранить до 330 мс загрузочного времени. Это говорит о том, что чем больше ресурсов ваш сайт загружает, тем больше подключений он требует. Если это ваш случай, то без HTTP/2 совсем никак.

Brotli сжатие

Третья технология, о которой сегодня пойдет речь, это Brotli — алгоритм сжатия данных, разработанный Google еще в 2015 году. Популярность Brotli продолжает расти, сейчас почти все известные браузеры поддерживают этот алгоритм (кроме IE). По сравнению с Gzip, Brotli всё же недостаточно развит в контексте глобальной доступности (CMS плагины, серверная поддержка, CDN поддержка и т.д.).

Так или иначе, Brotli показал впечатляющие результаты в компрессии по сравнению с другими методами. К примеру, согласно работам Google по изучению алгоритмов, Brotli обогнал Zopfli на 20-26% процентов по показателю сжатия.

Включаем Brotli

В зависимости от используемого вами сервера, применение будет различным; придется использовать только подходящий вашим параметрам метод. Если вы используете nginx, Apache или Microsoft IIS, следующие модули помогут включить Brotli.

• ngx_brotli (для nginx)
• mod_brotli (для Apache)
• IIS Brotli (расширение Microsoft IIS)

После того, как вы загрузите и установите один из модулей выше, вам понадобится настроить директивы на своё усмотрение. По завершению уделите внимание трем вещам:

1. Тип файла;
   Типы файлов, которые Brotli может сжать, включая CSS, JS, XML и HTML.
2. Качество сжатия;
   Качество компрессии будет зависеть от желаемых объемов сжатия в обмен на время. Чем больше уровень компрессии, тем больше времени и ресурсов понадобится, но и экономия в размере будет заметнее. Значение компрессии в Brotli определяется числом от 1 до 11.
3. Статическое или динамическое сжатие?
   Этап, на котором вы хотите применить компрессию, определяет, какому сжатию стоит отдать предпочтение:
   1. Статическое: предварительно сжимает ассеты, еще до того, как пользователь сделает запрос. Таким образом, сразу после отправки запроса Brotli не нужно сжимать ассет, ведь он уже готов. Эта опция по умолчанию встроена в модуль Brotli для nginx, а вот для Apache её нужно настроить.
   2. Динамическое: динамическое сжатие происходит “на лету”. Другими словами, как только посетитель подает запрос на доступный для Brotli-сжатия актив, этот актив сжимается на месте и сразу доставляется. Это полезно для динамического контента, которому нужна компрессия после каждого запроса, но есть и недостаток: пользователю нужно какое-то время подождать, пока пакет сжимается.

Конфигурация Brotli для nginx похожа на отрывок ниже. Этот пример задаёт динамическую компрессию, определяет качество и уточняет типы файлов.

brotli on;
brotli_comp_level 5;
brotli_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;

Чтобы проверить, работает ли Brotli в данный момент на вашем сервере, откройте консоль разработчика в Chrome, перейдите на вкладку Network, выберите актив и проверьте заголовок Content-Encoding. Там должно быть значение br. Обратите внимание, Brotli требует HTTPS, так что если вы всё правильно установили и настроили, но значение отличается от указанного выше, вам стоит перейти на HTTPS.

В другом случае, можете запустить простую cURL команду:

curl -I https://yourwebsite.com/path/to/your/asset.js

Она выведет список заголовков, там тоже можно поискать это значение. Для WordPress есть гайд.

Brotli vs Gzip: тест на производительность

Чтобы сравнить Brotli и Gzip, мы возьмем три сжимаемых ассета и сравним их по размеру и скорости загрузки. Для обоих методов сжатия установлен пятый уровень качества.

Вот результаты:

Файл	Размер gzip	Скорость загрузки gzip	Размер BROTLI	Скорость загрузки gzip
jquery.js	33.4 Кб	308 мс	32.3 KB	273 мс
dashicons.min.css	28.1 Кб	148 мс	27.9 KB	132 мс
style.css	15.7 Кб	305 мс	14.5 KB	271 мс

В целом, обработанные Gzip активы составили 77.2 Кб в размере, после Brotli — 74.7 Кб (ушли 3.3% от первоначального размера страницы). Касаемо времени загрузки, разница между двумя алгоритмами, как видно по таблице, составила 12.6%.

Изображения WebP

Наш пятый совет — использовать изображения именно такого формата. Он тоже был придумал в Google для уменьшения размера изображений. Действительно, в размерах этот формат порядком меньше чем jpeg и PNG: можно сэкономить до 80% после конвертации из этих форматов в WebP.

Недостаток один: не все браузеры еще научились поддерживать этот формат. На момент написания статьи поддерживаемых браузеров только два — Chrome и Opera. Хотя, есть возможность настроить выдачу изображений для этих двух в WebP, а для тех, у кого функция пока не предусмотрена — в первичном формате.

У WebP впереди долгий путь обретения такой же популярности, как у тех же jpeg и PNG. Так или иначе, благодаря значительной экономии места, есть хорошее пространство для роста. Подводим итог: WebP уменьшает общий вес страницы, ускоряет загрузку сайта и сохраняет пропускную способность.

Как конвертировать в WebP и вставить изображение

Есть несколько вариантов перевести изображение в WebP. Если вы сидите на CMS вроде WP, Joomla или Magento, достаточно будет дефолтных плагинов для конвертации, которые уже есть в админке.

С другой стороны, если есть желание самостоятельно этим заняться, существуют онлайн-конвертеры в WebP, даже в некоторых редакторах есть возможность сохранить файл в этом формате.

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

Как уже упоминалось, не все браузеры пока поддерживают WebP. Логично, что если вы просто вставите изображение в таком формате, в неподдерживаемых браузерах будет ошибка отображения. Вот здесь и приходит время запасного формата. Рассмотрим три способа разобраться с проблемой.

1. Используйте дескриптор “Picture”

Таким образом в HTML-коде можно указать ссылку на изображение и в WebP, и в, скажем, jpeg. Chrome и Firefox выведут WebP, остальные — дефолтное изображение по последнему привязанному дочернему тегу внутри блока <picture>. Например:

<picture>
<source srcset=”images/my-webp-image.webp” type=”image/webp”>
<img src=”images/my-jpg-image.jpg” alt=”My image”>
</picture>

Такой подход по максимуму раскрывает функциональность WebP, а заодно и обеспечивает корректное отображение в браузерах, которые не поддерживают этот формат.

2. Измените серверный файл с настройками

Этот метод позволяет переписать правила, прописанные в конфигурационном файле так, чтобы при использовании не адаптированного под WebP браузера отображался другой, поддерживаемый формат. Воспользуйтесь подходящим блоком кода для Apache или nginx и соответствующе настройте локацию path/images.

Для Apache:

RewriteEngine On
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{DOCUMENT_ROOT}/$1.webp -f
RewriteRule ^(path/images.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=accept:1]
Header append Vary Accept env=REDIRECT_accept
AddType image/webp .webp

Для nginx:

# http config block
map $http_accept $webp_ext {
default “”;
“~*webp” “.webp”;
}
# server config block
location ~* ^(path/images.+)\.(png|jpg)$ {
add_header Vary Accept;
try_files $1$webp_ext $uri =404;
}

Свой недостаток, конечно, есть — не стоит использовать WebP формат в одной упряжке с CDN. Всё это из-за того, что CDN кэширует WebP-изображение, если поддерживаемый браузер запросит его первым. Таким образом, все последующие запросы будут выдавать WebP вне зависимости от того, поддерживается этот формат браузером, или нет.

3. Используйте кэш-плагин на WordPress

Если вы пользуетесь WP, и при этом хотите, чтобы была совместимость с CDN, тогда вам пригодится плагин Cache Enabler. Если внутри плагина вы пропишете, что вам нужно создать дополнительную кэшированную версию для WebP, то плагин доставит WebP-кэшированную версию для WebP-поддерживающих браузеров, а всем остальным оставит HTML или HTML Gzip.

WebP против jpeg: кто производительнее?

Чтобы продемонстрировать разницу в размерах между WebP и jpeg изображениях, мы возьмем три фото в jpeg, переведем их в WebP и сравним с исходниками (2.1 Мб, 4.3 Мб и 3.3 Мб соответственно):

Тестовая картинка jpg 1 Тестовая картинка jpg 2 Тестовая картинка jpg 3

В WebP каждое из изображений заметно уменьшилось в весе, что мы указали в таблице ниже. Для конвертации в WebP было использовано сжатие с потерями, уровень качества 80:

Файл	Размер JPEG	Размер WEBP	Экономия
test-jpg-1	2.1 Мб	1.1 Мб	48%
test-jpg-2	4.3 Мб	1 Мб	77%
test-jpg-3	3.3 Мб	447 Кб	85.9%

Сжать WebP можно как с потерями, так и без. Компромисс для качества — меньший размер. Если вам хочется применить сжатие с потерями для дополнительной экономии веса, в WebP это произойдет с лучшим качеством и меньшем размере (в противовес jpeg, который к потерям добавляет артефакты).

CDN (Content Delivery Network)

Ну и напоследок посоветуем подключиться к CDN. Это такая технология, которая распределяет активы по нескольким серверам, чтобы они быстрее загружались (происходит некая разгрузка трафика).

CDNы используют кэширование, чтобы какое-то время хранить ресурсы сайта. Происходит это так: CDN копирует активы оригинального сервера и равномерно распределяет их по своим серверам, что значительно упрощает доступ к сайту для пользователей по всему миру.

Если CDN не настроен, тогда все запросы от пользователей будут поступать на оригинальный сервер, где бы он ни находился. Это создает неудобную нагрузку, особенно если локация пользователя очень далека от сервера.

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

Настраиваем CDN

Этот процесс будет отличаться в зависимости от того, какую CMS вы используете. Впрочем, поверхностно всё выглядит довольно похоже:

1. Создайте CDN-зону, указывающую на ваш изначальный адрес (https://вашсайт.com);
2. Создайте CNAME-запись, чтобы указать новый CDN адрес (cdn.вашсайт.com) для выбранного вами сервиса;
3. Используйте этот новый адрес, чтобы связать его с вашим сайтом (для этого сверьтесь с гайдом, подходящим для параметров вашего ресурса);
4. Проверьте разметку своего вебсайта, чтобы убедиться в том, что пакеты передаются через ваш кастомный адрес;

Как только это будет сделано, статические активы будут передаваться уже через серверы CDN. Это, к слову говоря, не только увеличит скорость загрузки, но и улучшит безопасность.

До и после CDN: тест на производительность

Поскольку уж так сложилось, что CDN пользуется серверами с разных локаций, эти тесты будут отличаться в зависимости от того, откуда идет запрос, и где ближайший сервер. Так что простоты ради мы остановились на трёх локациях для теста: Франкфурт, Нью-Йорк и Торонто. В качестве тестируемого параметра возьмем скорость загрузки изображения, скрипта и файла CSS. Оба результата (с использованием CDN и без него) представлены ниже:

Как мы можем видеть, время загрузки ассетов через CDN порядком меньше, чем без него. Конечно, результаты будут разниться в зависимости от взаимного расположения серверов и пользователей, но в целом производительность всё равно лучше.

Заключение

Если вы ищете способы вывести безопасность и производительность сайта на новый уровень, эти пять методов — самое то. Они не только легки в применении, но и в целом модернизируют весь ресурс, повышая вас в глазах других разработчиков и клиентов.

Некоторые из этих технологий всё ещё в процессе глобальной адаптации в виду неполной поддержки браузерами, проблем с плагинами и т.д.; но мы верим, что с ростом спроса вырастет и совместимость.

И ещё раз, уже напоследок. Если вы до сих пор не перевели сайт на HTTPS, сделайте это в ближайшее время. Сейчас это стандарт, который как минимум необходим для применения других технологий, того же Brotli или WebP. Тем более, ваш сайт так станет в целом безопаснее и производительнее, а также будет выглядеть надежнее в глазах Google.