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

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

  • 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 Время загрузки Gzip Размер Brotli Время загрузки Brotli
jquery.js 33.4 КБ 308 мс 32.3 КБ 273 мс
dashicons.min.css 28.1 КБ 148 мс 27.9 КБ 132 мс
style.css 15.7 КБ 305 мс 14.5 КБ 271 мс

Общий размер ресурсов, сжатых при помощи 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.

Название картинки Размер 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 , вы получите тот же уровень качества, что и для 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 222 мс 757 мс 764 мс
Изображение, с CDN 32 мс 81 мс 236 мс
Файл JavaScript, без CDN 90 мс 441 мс 560 мс
Файл JavaScript, с CDN 30 мс 68 мс 171 мс
Файл CSS, без CDN 96 мс 481 мс 553 мс
Файл CSS, с CDN 31 мс 77 мс 148 мс

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

Заключение

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *