Быстрые способы повышения производительности и безопасности сайта

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

• Let’s Encrypt (SSL)

Бесплатный способ получить SSL-сертификат для повышения безопасности и увеличения производительности.

• HTTP / 2

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

• Brotli

Метод сжатия, который превосходит Gzip и предоставляет на выходе меньший размер файлов.

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

Формат изображений, который делает их меньшими по объему, по сравнению JPEG или PNG.

• Сеть доставки контента

Набор серверов, размещенных по всему миру, для кэширования и быстрой доставки ресурсов вашего сайта.

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

А если вы запустите интернет-магазин с формой захвата, то более быстрый сайт позволит увеличить конверсию.

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

Let’s Encrypt (SSL)

Google уже рассматривает HTTPS в качестве сигнала ранжирования. Как заявлено в Google’s Security blog, все незащищенные веб-страницы в скором времени будут отображаться в браузере Chrome как небезопасные.

Let's Encrypt - бесплатный способ получения SSL сертификата. Ранее, если вы хотели использовать HTTPS, необходимо было приобрести действительный SSL-сертификат. Из-за этого многие вебмастера продолжали использовать HTTP.

Но в конце 2015 года была представлена публичная бета-версия Let's Encrypt, с помощью которой выпустили миллионы бесплатных SSL-сертификатов. Let's Encrypt заявила, что на конец июня 2017 года было выдано более 100 миллионов сертификатов. До этого на HTTPS было переведено менее 40% веб-страниц. За полтора года после запуска Let's Encrypt это число возросло до 58%.

Вот несколько причин, почему переход на HTTPS действительно важен:

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

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

Сертификаты Let's Encrypt действительны в течение 90 дней. Вы должны обновить их вручную, прежде чем истечет срок их действия, или настроить процесс автоматического обновления.

Есть два метода получить SSL-сертификат Let's Encrypt:

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

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

Если есть доступ к оболочке и нужно настроить Let's Encrypt, то необходимо определить, какой веб-сервер и операционную систему вы используете. Затем перейдите в Certbot и выберите в раскрывающемся меню программное обеспечение и операционную систему, чтобы найти инструкции по установке.

Главная страница Certbot

HTTP / 2

Одним из наиболее полезных улучшений HTTP / 2 является то, что протокол позволяет браузерам распараллеливать несколько загрузок, используя только одно соединение. С HTTP 1.1 большинство браузеров могли обрабатывать в среднем только шесть одновременных загрузок. Появление HTTP / 2 привело к тому, что такие методы, как domain-sharding, становятся устаревшими.

Также HTTP / 2 предоставляет и другие преимущества:

• Server push. Введение дополнительных ресурсов, которые, по мнению сервера, потребуются клиенту в будущем.
• Сжатие заголовка. Уменьшает размер заголовков, используя сжатие HPACK.
• Двоичная природа. В отличие от HTTP 1.1, который был текстовым, двоичный код сокращает время, необходимое для перевода текста в двоичный файл и упрощает анализ на сервере.
• Приоритезация. Уровни приоритетов связаны с запросами. Это позволяет в первую очередь предоставлять ресурсы, имеющие более важное значение.

Включение HTTP / 2

Определить, поддерживает ли провайдер HTTP / 2, просто - перейдите на страницу описания функций хостинга и найдите данную информацию.

Если вы хотите проверить, использует ли ваш сайт HTTP / 2, нужно установить последнюю версию cURL и запустить следующую команду:

curl --http2 http://yourwebsite.com

Если вам неудобно использовать командную строку, откройте инструменты для разработчиков в Google Chrome и перейдите на вкладку «Сеть». В столбце «Протокол» вы должны увидеть значение h2.

h2 в инструментах для разработчиков от Google Chrome

Включение HTTP / 2 на NGINX

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

listen 443 ssl http2;

Включение HTTP / 2 на APACHE

Чтобы использовать HTTP / 2, пользователи Apache должны обновить систему до версии 2.4.17 или выше. Им также потребуется настроить HTTPS с модулем Apache mod_http2, загрузить модуль и определить корректную конфигурацию сервера. Краткое описание процедуры можно найти в руководстве Apache по HTTP / 2.

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

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

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

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

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

Первый тест показывает результаты для HTTP 1.1. На всю страницу в среднем приходилось 1,73 секунды до полной загрузки, и различное время блокировки (как видно по красным полоскам на рисунке ниже).

Время загрузки для HTTP 1.1 и потоки

При тестировании того же сайта на протоколе HTTP / 2 результаты были совершенно другими. Среднее время загрузки всей страницы составило 1,40 секунды, а время блокировки было незначительным.

Время загрузки для HTTP / 2 и потоки

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

Сжатие Brotli

Третья технология, которую мы рассмотрим - это алгоритм сжатия Brotli, разработанный Google еще в 2015 году. Brotli продолжает набирать популярность, и в настоящее время поддерживается всеми популярными браузерами (за исключением Internet Explorer).

Brotli показывает впечатляющие результаты сжатия по сравнению с другими алгоритмами. Например, согласно исследованию алгоритмов от Google, Brotli превзошел Zopfli (еще один современный метод сжатия) на 20-26%.

Включение Brotli

Если вы используете nginx, Apache или Microsoft IIS, для включения Brotli доступны следующие модули.

• ngx_brotli, модуль для nginx;
• mod_brotli, модуль для Apache;
• IIS Brotli, расширение, предоставляемое сообществом Microsoft IIS.

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

• Тип файла. Типы файлов, которые могут быть сжаты с помощью Brotli: CSS, JavaScript, XML и HTML.
• Качество сжатия. Чем выше уровень сжатия, тем больше времени и ресурсов потребуется, но тем больше будет экономия в размере файлов. Уровень сжатия Brotli может быть определен в диапазоне от 1 до 11.
• Статическое и динамическое сжатие. Этап, на котором вы хотите выполнить сжатие Brotli, определит, следует ли выполнять статическое или динамическое сжатие:

• Статическое сжимает ресурсы еще до того, как пользователь выполняет сам запрос. Следовательно, после того, как запрос инициирован, Brotli не нужно сжимать ресурс - он уже сжат и может быть доставлен немедленно. Эта функция встроена в модуль Brotli для nginx. А для реализации статического сжатия на Apache требуется дополнительная настройка.

• Динамическое сжатие происходит «на лету». Как только посетитель инициирует запрос, этот ресурс сжимается и затем доставляется. Это полезно для динамического контента, который нужно сжимать при каждом запросе. Недостатком является то, что пользователь должен ожидать сжатия объекта перед его доставкой.

Конфигурация Brotli для пользователей nginx может выглядеть примерно так, как показано ниже. Согласно данной конфигурации сжатие будет выполняться динамически («на лету»), уровень сжатия - 5, также заданы различные типы файлов.

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 включен на сервере, откройте инструменты для разработчиков в Google Chrome и перейдите на вкладку «Сеть». Затем выберите ресурс и проверьте заголовок Content-Encoding. Теперь он должен иметь значение br.

br в Инструментах для разработчиков, доступных в браузере Google Chrome

Также можно запустить простую команду cURL:

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

Она возвращает список заголовков ответов, в котором нужно проверить значение заголовка Content-Encoding.

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

Возьмем три сжатых веб-ресурса и сравним их по размеру и скорости загрузки. Для обоих методов были определены значения уровня сжатия - 5.

Результаты тестирования:

Общий размер ресурсов, сжатых с помощью Gzip, составил 77,2 КБ, а сжатых Brotli - 74,7 КБ. Общее снижение размера страницы всего на 3,3%, только благодаря использованию Brotli.

Ресурсы, сжатые Gzip, загружались за 761 миллисекунда, а с помощью Brotli - 676 ​​миллисекунд. Улучшение на 12,6%.

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

WebP был разработан Google с целью уменьшения размеров изображений. WebP - это формат изображений. Основное преимущество в обслуживании WebP-изображений заключается в том, что они меньше по размеру, чем JPEG и PNG. После преобразования JPEG или PNG в WebP может быть достигнута экономия до 80%.

Недостатком формата изображений WebP является то, что не все браузеры поддерживают его. На момент написания данной статьи - это только Google Chrome и Opera. Но при правильной настройке вы можете доставлять изображения WebP для поддерживающих его браузеров и резервный формат изображений (например, JPEG) для остальных.

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

Как преобразовать и предоставить WebP

Для WordPress, Joomla или Magento, доступны плагины, которые позволяют конвертировать изображения через панель управления CMS. Также можно использовать онлайн-конвертеры изображений в формат WebP.

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

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

1. Использовать элемент picture

Этот метод позволяет определить в HTML-документе путь к изображению в формате WebP и к исходному изображению JPEG. Поддерживающие браузеры будут отображать WebP, а остальные - изображение по умолчанию, определенное в последнем вложенном дочернем теге в блоке изображения. Рассмотрим следующий пример:

<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 в соответствии с вашим веб-сервером.

Для Apache:

RewriteEngine OnRewriteCond %{HTTP_ACCEPT} image/webpRewriteCond %{DOCUMENT_ROOT}/$1.webp -fRewriteRule ^(path/images.+).(jpe?g|png)$ $1.webp [T=image/webp,E=accept:1] Header append Vary Accept env=REDIRECT_acceptAddType image/webp .webp

Для nginx:

# http config blockmap $http_accept $webp_ext {    default "";    "~*webp" ".webp";} # server config blocklocation ~* ^(path/images.+).(png|jpg)$ {    add_header Vary Accept;    try_files $1$webp_ext $uri =404;}

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

3. WordPress-плагин кэширования

Если нужно решение совместимое с CDN, тогда вы можете использовать плагин кэширования, такой как Cache Enabler.

WebP в сравнении с JPEG: тест производительности

Возьмем три JPEG-изображения, преобразуем их в формат WebP и сравним результат. Три изображения, приведенные ниже, имеют размер 2,1 МБ, 4,3 МБ и 3,3 МБ, соответственно.

[https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/c9a8ca17-1d4a-468d-a04c-afa8739062f9/test-jpg-1-800w-opt.jpg]

Тестируемое JPEG-изображение 1

[https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/dd3da10e-f02e-4298-acdb-9521ea27d603/test-jpg-2-800w-opt.jpg]

Тестируемое JPEG-изображение 2

[https://cloud.netlifyusercontent.com/assets/344dbf88-fdf9-42bb-adb4-46f01eedd629/3e0024c8-62ae-421f-ae7f-b03eba42c25c/test-jpg-3-800w-opt.jpg]

Тестируемое JPEG-изображение 3

При преобразовании в формат WebP каждое изображение уменьшилось в размерах. В приведенной ниже таблице указаны размеры исходных изображений, размеры их WebP-версий и то, насколько WebP-изображение меньше JPEG. Изображения были преобразованы в WebP с использованием сжатия с потерей качества на уровне 80.

Потери качества обеспечивают меньший размер изображения. Если хотите реализовать сжатие с потерями для дополнительной экономии в размере с помощью формата WebP, вы получите тот же уровень качества, что и для JPEG, но при меньшем размере файла.

Сеть доставки контента

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

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

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

Настройка CDN

Специфика настройки CDN зависит от используемой CMS или фреймворка. При этом процесс настройки более или менее одинаков для всех платформ:

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

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

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

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

• Франкфурт, Германия;
• Нью-Йорк, США;
• Торонто, Канада.

Мы решили измерить время загрузки изображения, файла CSS и файла JavaScript. Результаты каждого теста, как с включенным CDN, так и без него, приведены в таблице:

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

Заключение

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