Современные тенденции развития интернет технологий постоянно диктуют WEB мастерам условия, при которых их сайты должны отображаться на экранах устройств максимально быстро, причем на любом качестве сетевого соединения и мощности оборудования. Предел терпимости пользователей сегодня меряется несколькими секундами, а потери прибыли у крупных торговых WEB площадок за их медленность - миллионами долларов.
 
 
Что даёт ускорение сайта?
 
Исследования торговых интернет гигантов показывают ошеломительные результаты прироста прибыли и трафика после ускорения сайтов на несколько секунд. Так компания Amazon экспериментально выяснила, что каждые потерянные 100 мс при загрузке приводят к снижению продаж на 1%. А компания Walmart, выиграв 4 сек после оптимизации своего сайта, увеличила конверсию на 20%. Но нужна ли молниеносная загрузка не торгующим сайтам?

Скорость загрузки влияет не только на конверсию и количество продаж, но и на более высокие позиции в выдаче и лояльность посетителей. Новатором в этой сфере является Google, а всем остальным просто приходиться подстраиваться под те тенденции, которые развивает эта компания. Так давайте вместе разберёмся как выжать оптимально возможную скорость загрузки сайта и как его разогнать до максимума. Но для начала нужно узнать, что и где оптимизировать.
 
 
Что, где и как измерять?

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

• Время ответа сервера.


• Время отрисовки страницы.


• Время полной загрузки страницы.

Каждая из этих метрик очень важна, поэтому подробнее рассмотрим, что тут и к чему.
 
 
Время ответа сервера

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

• www.host-tracker.com/ru/


• webopulsar.ru/test


• ping-admin.ru/free_test/

Но тут важно учитывать и географическое расположение, так как если ваш сайт находиться в России, а пользователь в Австралии, или ещё какой удалённой точке, то само собой время ожидания может быть завышенным из-за расстояния. Поэтому при выборе «дома» для вашего сайта, обязательно учитывайте близость аудитории вашего сайта к фактическому расположению WEB сервера. Тут чем ближе, тем лучше. Например, хостинг в Канаде или США не лучший вариант для сайта с основной аудиторией из России и соседних стран.
От себя хочу порекомендовать отличный VDS/VPS хостинг в России https://firstvds.ru, которым пользуюсь сам уже много лет. Компания активно снижает цены и наращивает мощности железа, при этом всегда используются самые передовые технологии. Можно купить самый дешёвый VDS по цене хостинга, либо сконфигурировать WEB сервер под свои нужды.
 
 
Время отрисовки страницы

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

• developers.google.com/speed/pagespeed/insights/


• www.webpagetest.org


• testmysite.withgoogle.com/intl/ru-ru

Кстати популярный инструмент от Google PageSpeed Insights недавно обновился и обзавёлся новым функционалом. Теперь он не только измеряет уровень оптимизации ускорения по шкале от 0 до 100 и даёт рекомендации, но и имитирует загрузку страницы по шагам при её отрисовки. Это очень удобно.
 

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

 

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

 

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

 

 
Время полной загрузки страницы

Время полной загрузки – это время, затраченное на загрузку полнофункциональной страницы, то есть окончательное время, по итогу которого загружены все внешние стили, скрипты и медиа контент для видимой части страницы, вмещаемой в экран. По сути это и есть та заветная метрика, которая в идеале должна составлять от 3 – 5 секунд.
 

 

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

• Оптимизация WEB сервера.


• Клиентское кеширование.


• Оптимизация статических ресурсов.

Оптимизация WEB сервера

Одним из важных моментов в скорости загрузки сайта является быстро работающий WEB сервер. Выше я уже говорил, как замерить скорость ответа и где оптимально содержать сайт в плане географии. Но, быстродействие сервера зависит не только от его геолокации, но и от его настроек, используемых модулей и свежести установленного ПО.

Далее речь в основном пойдёт для тех, кто как минимум для своих проектов имеет виртуальный сервер (VDS/VPS). Ну а для тех, кто «живёт» на обычном хостинге остаётся в этом вопросе уповать только на грамотность хостера, либо искать варианты. Итак, приступим:
 
 
Серверные ресурсы

Зачастую начинающие WEB мастера покупают самые дешёвые тарифы хостинга для своих ресурсов, и это оправдано. Но по мере роста их проектов могут возникать трудности из-за недостатка CPU, оперативной памяти или объёма и скорости дисков, так как они жестко лимитированы. Это касается и ресурсов виртуальных серверов. Выход здесь один, покупка более дорого тарифа или сервера, если это оправдано.

Но увеличение ресурсов не всегда есть правильный выход, да и до бесконечности это делать не получиться из-за высокой стоимости оных. Поэтому приступим к следующему шагу, и заодно рассмотрим, как самостоятельно произвести настройки, используя только панель ISP manager 5 и ОС Debian 9.
 
 
Nginx + Apache

Тут конечно можно развести споры, что эта связка не идеальна и можно сделать лучше или проще. Но мы это дело оставим для спецов, так как статья больше ориентирована на менее опытных мастеров. Связка WEB серверов Nginx + Apache разделяет выполняемые ими операции. Nginx отдаёт статические файлы (js, css, html), так как делает это лучше всех, и заодно умеет сжимать и кешировать файлы, но об этом чуть ниже. А Apache обрабатывает динамические файлы, то есть выполняет программный код CMS.

Использование такой схемы положительно скажется на производительности WEB сервера, и как следствие на скорости загрузки страниц сайта. Более детально по работе такого WEB сервера, либо его сборке через консоль я рекомендую изучить самостоятельно, найдя в поиске статьи на эту тему. А сейчас рассмотрим, как сделать связку Nginx + Apache в ISP manager на упомянутом мной выше FirstVDS.Ru
Заходим в панель под root пользователем и в боковом меню в блоке «Настройки» кликаем по ссылке «Возможности». Далее во вновь загрузившейся вкладке в списке «Наименование» выбираем «Веб-сервер (WWW)» и кликаем в верхнем меню по ссылке «Изменить». Дальше вам остается только поставить галочку напротив опции «Nginx» и нажать на кнопку «Применить изменения». Всё остальное будет сделано автоматически :)
 
 

 

 
 
HTTPS + HTTP/2
 
Относительно недавно поисковики и браузеры стали загонять WEB мастеров в колею безопасного соединения, то есть использовать SSL сертификаты. Google грозился даже выше ранжировать сайты работающие через HTTPS, но на практике оказалось всё не так гладко. В большей степени всё это дело носит коммерческий характер, но есть и бесплатные SSL сертификаты. Уже сегодня большинство успешно используют HTTPS на своих сайтах, и правильно делают. А вот почему.

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

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

Также в новый протокол заложено мультиплексирование (request multiplexing) для снижения сетевых задержек во время загрузки страницы. То есть HTTP/2 использует только один TCP канал, и через него загружает страницу со всеми её элементами полностью. Все файлы подгружаются параллельно. Ответы получаются по мере их готовности, и как следствие более тяжёлые запросы не препятствует более простым. Отпадает надобность в использовании CDN.

А вот HTTP/1.1 для загрузки WEB страницы открывает множество TCP каналов. Один для изображений, второй для стилей, третий для скриптов, и т. д. Причём количество таких каналов лимитировано. И это не решает проблему блокирования соединений тяжёлыми запросами. Возникает очередь загрузки элементов страницы. Заметно на медленном сетевом соединении.

 

 

Приоритизация
 
В HTTP/2 появилась приоритизация, где запросам можно указывать приоритет на основе важности и зависимости. Так при загрузке WEB страницы браузером, изначально будут получены приоритетные данные. Например, в первую очередь HTML, затем CSS. А всё остальное второстепенно. Но как это реализуется на практике я пока не разобрался, возможно приоритеты по умолчанию расставлены грамотно.
 
 

 

 
Сжатие заголовков

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

Для этого в HTTP/2 внедрили сжатие HTTP заголовков, что существенно сокращает объём передаваемых данных и увеличивает скорость обмена ими в отличии от HTTP/1.1. Таким вот не хитрым образом новая спецификация стала эффективнее.
 
 
Server Push

Когда браузер запрашивает WEB страницу с использованием протокола HTTP/1.1, в ответ сервер скидывает только HTML файл и далее ждёт пока браузер «переварит» содержимое и в ответ запросит всё подключенные к странице файлы (стили, картинки, скрипты, шрифты и т. д.).

При использовании HTTP/2 WEB-сервер поступает иначе. Он, используя внедрённую функцию Server Push, не дожидаясь ответа от браузера начинает складывать все необходимые файлы в его кэш. Таким образом происходит очень быстрая отдача файлов.
 

 

Шифрование

HTTP/2 задумывался как замена HTTPS, то есть для своей работы протокол не требует шифрования. Однако производители браузеров упёрлись рогом, заявив поддержку HTTP/2 только в совокупности с безопасным соединением. С одной стороны, это сложности, с другой делает интернет более безопасным для обывателей и способствует распространению шифрованного соединения. Вроде как бы тоже плюс.
 
 
Как видите новоиспечённый HTTP протокол второй версии содержит только плюсы, которые здесь перечислены не полностью, и действительно быстрее и производительнее чем его предшественник с двадцатилетним стажем. Поэтому, если ваш сайт уже использует HTTPS, то не поленитесь подключить и HTTP/2. А теперь давайте рассмотрим, как это можно сделать.
Для включения HTTP/2 в ISPManager 5 нужно соблюсти несколько условий:

• Версия панели не ниже 5.146


• Установлен WEB сервер Nginx


• ОС CentOS 7, либо Debian 9

Если условия выполнены, то в панели под root пользователем в боковом меню, в блоке «Настройки web-сервера» появиться ссылка «Глобальные настройки». Переходим по ней и в открывшейся вкладке напротив опции «Включить HTTP/2» нужно поставить галочку и нажать на кнопку «Оk».  Всё, теперь HTTP/2 включён для всего WEB-сервера, но для сайтов, которые не используют SSL сертификат по-прежнему будет работать HTTP/1.1.

 

 

 
Для всех остальных вариантов можно использовать ручные настройки, так как новые версии WEB серверов поддерживает HTTP/2 по умолчанию. Нужно лишь только добавить несколько правил в конфиги.
 
 
Nginx с версии 1.9.5 и выше

server {
    listen              443 ssl http2;
    server_name         example.com;
    ssl_certificate server.crt;
    ssl_certificate_key server.key;
}

 
Apache с версии 2.4.17 и выше
 

# for a https server
Protocols h2 http/1.1
# for a http server
Protocols h2c http/1.1

 
 
Серверное сжатие данных

Ещё одним отличным способом оптимизации работы WEB сервера является автоматическая компрессия текстовых данных (HTML, JS, CSS), перед их отправкой в браузер. Графические файлы тоже можно сжимать по этой технологии, но это не оправдывает ресурсозатраты, так как графика плохо сжимается. А вот на текстовых файлах можно с экономить до 70%. Графика тоже оптимизируется, но иначе и об этом чуть позже.

Самым популярным и простым способом сжатия данных является модуль Gzip, по умолчанию он есть, наверное, на каждом WEB сервере, но не всегда включён или настроен. А проверить работает ли компрессия под силу каждому, например, используя этот checkgzipcompression.com инструмент.
 
 

 

На скриншоте видно выигрыш в более чем 68%. От изначального веса в 18Kb осталось только 5.6Kb. Сжатый файл загрузиться браузером в разы быстрее, плюс экономия трафика.

А теперь давайте посмотрим, как настроить Gzip сжатие используя ISPManager 5 и Nginx в качестве проксирующего WEB-сервера. В боковом меню в блоке «WWW» переходим по ссылке «WWW-домены». В открывшейся вкладке, выбираем нужный домен и кликаем по кнопке «Изменить» в верхнем меню. Далее в самом низу ищем блок «Оптимизация WWW-домена» и там будут такие вот настройки:

 

 

Отмечаем галочкой «Настроить сжатие» и в появившейся опции «Уровень сжатия» указываем степень сжатия. Чем выше цифра, тем меньше файлы весят после сжатия. Но тут не стоит перегибать палку, так как компрессия даёт нагрузку на WEB-сервер. Поэтому оптимально выставить значение 5 – 6 единиц. Ну и не забываем сохранить изменения средствами кнопки «Ok».

В том случае, когда нужно активировать сжатие ручками и поправить конфиги, то следуйте этим инструкциям. Для WEB сервера Apache нужно внести следующий код в файл .htaccess:
 

php_value zlib.output_compression 4096
php_value zlib.output_compression_level 6

 
включаем Gzip сжатие и указываем уровень компрессии файлов.
 

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
  <IfModule mod_setenvif.c>
    BrowserMatch ^Mozilla/4 gzip-only-text/html
    BrowserMatch ^Mozilla/4.0[678] no-gzip
    BrowserMatch bMSIE !no-gzip !gzip-only-text/html
  </IfModule>
  <IfModule mod_gzip.c>
    mod_gzip_on Yes
    mod_gzip_item_include file \.js$
    mod_gzip_item_include file \.css$
  </IfModule >
</IfModule>
<IfModule mod_headers.c>
  <FilesMatch "\.(js|css|xml|gz)$">
    Header append Vary: Accept-Encoding
  </FilesMatch>
</IfModule>

 
Указываем типы файлов, которые следует сжимать, делаем некоторые исключения и выводим HTTP-заголовки. Инструкции весьма условны, используют разные методы активации сжатия, так что рекомендую изучить что за что отвечает более подробно.

Для WEB-сервера Nginx уже потребуется доступ к файлу конфигурации. Не доступно для shared-хостинга. Идём примерно по такому пути /etc/nginx/nginx.conf и вписываем туда следующие настройки:
 

http {
  gzip on;
  gzip_disable "msie6";
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 6;
  gzip_buffers 16 8k;
  gzip_types text/html text/plain text/css text/xml text/javascript application/json application/x-javascript application/xml application/xml+rss;
}

Вот и всё, ничего сложного в этом нет, а польза от сжатия в ускорении сайта просто огромная. Но хочу ещё отметить, что Gzip не единственный алгоритм сжатия данных. Существуют ещё более эффективные методы, такие как zopfli и brotli. Но эти алгоритмы ресурсозатратны при компрессии и использовать их нужно только в статическом варианте. То есть файлы предварительно сжимаются и в таком виде хранятся на диске, а WEB-сервер отдаёт уже их, без сжатия «на лету». Как это реализуется я разбираться не стал, мне хватает ламерского метода включения Gzip через ISP панель.
 
 
Оптимальное использование ресурсов

Обязательно хочу упомянуть о том, что все модули и прочие компоненты после установки WEB-сервера идут с настройками по умолчанию. А они, как правило, не рационально используют выделенные ресурсы, и поэтому, особенно для высоконагруженных проектов, стоит проводить тюнинг используемых модулей и до устанавливать необходимые. Каких-то конкретных инструкций дать не могу, так как тут всё индивидуально и зависит от железа сервера и выделенных ресурсов, плюс некоторые моменты зависят конкретно от нужд проекта.
Просто имейте ввиду, что тот же mysql сервер, который отлично работает из коробки на проектах с небольшим трафиком, плохо работает под нагрузкой. Nginx или Apache также по умолчанию работают не максимально эффективно. Ну и нужно использовать всякие штуки в виде php кеширования. Всё это может помочь в ускорении загрузки сайта при его росте.
 
 
 
Уменьшение количества запросов

Почти каждая WEB страница состоит из множества различных элементов: всевозможной графики, файлов стилей, java скриптов, шрифтов и т.д. Каждый элемент - это отдельный запрос к WEB серверу. Чем больше запросов, тем больше времени нужно на их обработку и отдачу в браузер. Плюс выше я говорил о недостатках HTTP/1.1, где избыточное количество TCP каналов замедляет загрузку WEB страницы, а при образовании очереди ещё может и блокировать отображение контента. Несмотря на то, что HTTP/2 решает часть проблем, все же стоит всегда контролировать количество запросов.
 
Чтобы уменьшить количество запросов к серверу, можно прибегнуть к следующим ухищрениям:
 
 
CSS спрайты

CSS спрайт – это своего рода графический архив, где в один, не больших размеров файл, собраны различного рода графические элементы дизайна (логотипы, иконки, градиенты…). Вместо кучи мелких файлов получается один, но тут не стоит всё, и вся собирать в одном месте, так как слишком большой файл — это тоже проблема. Лучше сделать 2 – 3 небольших спрайта. Всяко лучше два, три запроса, чем один громоздкий, либо пару десятков мелких. Выглядит спрайт примерно так:
 

 

На страницу такая графика выводиться не через привычный тег <img>, а через присвоение нужному селектору CSS свойств с координатами необходимого элемента. Так левый верхний угол по оси X и Y будет иметь координаты 0 0. Вычислять координаты удобно при помощи программы Photoshop и активированной координатной сетки.
 
CSS правила будут примерно такими:
 

.icon {
    background: url(images/sprite.png) 0 -35px repeat-x;
    width:32px;
    height:32px
}

 
А в HTML вывод будет осуществлён так:
 

<span class="icon"></span>

 
BASE64 кодирование

Иногда бывает не целесообразно, или не удобно изображение помещать в спрайт, а от лишнего запроса избавиться надо. Тут на помощь может прийти кодирование изображения в строку средствами алгоритма BASE64. Кодированные таким образом изображения можно выводить как через CSS, так и при помощи тега <img>:
 

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgA AAAoAAAAKCAYAAACNMs+9AAAABmJLR0QA/… CYII=">

 
Либо так:
 

.icon{
    background:url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAAeCAIAA…uQmCC)repeat-x;
    width:32px;
    height:32px
}

 
А кодировать можно через онлайн сервис www.base64-image.de, он выдаёт сразу готовые варианты для размещения на сайте:

 

 

 
Метод прост в использовании, но не стоит с ним перебарщивать, так как BASE64 хеш строки с кодированными изображениями очень длинные и будут утяжелять размер HTML документа, либо CSS файла. Но как я говорил выше, текстовый контент при помощи Gzip, сжимается намного эффективнее, чем графика.
 
 
Также сокращать запросы к серверу можно путём браузерного кеширования, которое реализуется набором определённых HTTP-заголовков. Вот об этом далее и поговорим.
 
 
 
Клиентское (браузерное) кеширование

Клиентское кеширование – это алгоритм сохранения в локальное хранилище (кэш) браузера различных не изменяемых, либо мало изменяемых файлов, с последующей отдачей, при их повторном запросе, прямо из кэша. Это графические элементы, файлы стилей и js скрипты, шрифты, HTML и прочие составляющие любой WEB страницы. Кешировать оптимально на долгий срок, например, на год.

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

Реализуется такое кеширование путём обмена HTTP-заголовками между браузером и WEB-сервером. В некоторых случаях похоже на диалог, состоящий из вопросов и ответов, на основании которых принимаются определённые решения. Давайте посмотрим, что это за заголовки, как они работают и как их реализовать.
 
 
Заголовки Last-Modified и If-Modified-Since

Механизм данных заголовков заключается в том, что WEB-сервер при отдаче файлов добавляет к ним HTTP-заголовок Last-Modified со значением даты и времени их последнего изменения. Выглядит так:
 

Last-Modified: Thu, 12 Jan 2017 14:40:21 GMT

 
После получения такого заголовка браузер знает точную дату и время создания или изменения файла. А при повторном обращении к WEB-серверу за файлами, браузер изначально будет отправлять запрос с HTTP-заголовком If-Modified-Since:
 

If-Modified-Since: Thu, 12 Jan 2017 14:40:21 GMT

 
В таком случае если файл не был изменён, WEB-сервер вместо файла ответит статусом 304 Not Modified, что укажет браузеру чтобы он взял ранее сохранённую копию файла из своего кэша.
 
 
Заголовки Etag и If-None-Match
 
Алгоритм Etag схож с работой заголовка Last-Modified, но отличается тем, что не привязан ко времени. При создании, либо изменении файла WEB-сервер помечает его меткой, именуемой Etag. В качестве значения использует кусочек хеша, формируемого на основании содержимого файла. Выглядит всё это дело примерно так:
 

ETag: "58779555-c1"

 
Браузер запоминает хеш-значения и в следующий раз, прежде чем запросить сам файл, он спросит WEB-сервер HTTP-заголовком:
 

If-None-Match: "58779555-c1"

 
Если переданное браузером значение совпадает со значение метки Etag у файла на сервере, то браузер получит ответ со статусом 304 Not Modified. И так же, как и с предыдущим заголовком, получит инструкции взять файл из своего кэша, а не загрузить его с сервера.
 
 
Заголовок Expires

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

Expires: Thu, 24 Jan 2019 18:22:44 GMT

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

Для WEB-сервера Apache можно настроить вывод данного заголовка средствами файла .htaccess:
 

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 days"
</IfModule>

 
Nginx как всегда требует особых условий. Редактируем конфиг и вносим примерно следующие настройки, где кешируем графику на одну неделю, а стили и скрипты на один день:
 

server {
    location ~* \.(gif|ico|jpe?g|png)(\?[0-9]+)?$ {
        expires 1w;
    }
    location ~* \.(css|js)$ {
        expires 1d;
    }
}

Либо такой пример, вечного кеширования для перечисленных расширений файлов.
 

server {
    location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tg
z|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ {
        expires max;
    }
}

 
 
Заголовок Cache-Control
 
Данный заголовок более функциональный аналог Expires, только тут срок годности задаётся не конкретной датой и временем, а количеством секунд, по истечении которых браузеру нужно будет обновить файл в кеше.
 

Cache-Control: public, max-age=31536000

 
Из примера видно, что в содержимом Cache-Control используется пара ключ=значение, а это значит данный заголовок может передавать ещё кое-какие инструкции. Рассмотрим возможные варианты:
 
public – директива разрешает кешировать файл не только в браузере, но и различным посредникам между браузером и WEB-сервером. Это различные прокси сервера или CDN-сети.
 
private – антипод предыдущей директивы, запрещает кешировать везде в промежуточных звеньях, кроме браузера. Например, подходит для контента, который скрыт авторизацией.
 
max-age – директива указывающая в секундах срок хранения файла в кэше браузера, до его следующей ревалидации.

no-cache – запрещает кешировать файлы, тем самым указывает браузеру, что он должен скачивать их каждый раз.

no-store – категорически запрещает что-либо кешировать, даже частями. Предназначен для конфиденциальной информации.

no-transform – директива, запрещающая прокси серверам или CDN-сетям сжимать, либо как-то конвертировать контент для ускорения его загрузки.

must-revalidate – даже несмотря на то, что задан срок годности файла, данная директива обязывает браузер, чтобы он проверил актуальность файла на WEB-сервере. Например, через заголовок Etag.

proxy-revalidate – аналог предыдущей директивы, но предназначен для кеширующих прокси серверов.
 
s-maxage – тоже самое, что и max-age, только ориентирован на CDN-сети. Для них по приоритету выше чем max-age и Expires.
 
Пример конфигурации для Apache. Код также вносим в файл .htaccess:
 

<ifModule mod_headers.c>
    <FilesMatch "\.(gif|ico)$">
        Header set Cache-Control "max-age=2592000, public"
    </FilesMatch>
    <FilesMatch "\.(js)$">
        Header set Cache-Control "max-age=88000, private, must-revalidate" </FilesMatch>
    <FilesMatch "\.(php)$">
        Header set Cache-Control "private, no-store, no-cache, must-revalidate, no-transform, max-age=0"
        Header set Pragma "no-cache"
    </FilesMatch>
</ifModule>

 
А для конфигурации Nginx такой код:
 

server {
    location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
        add_header Cache-Control "max-age=86400, public";
    }
}

 
 
Заголовок Vary
 
Заголовок Vary предназначен для кеширующих систем, где значения данного заголовка указывают на «правильность» лежащего в кэше контента. Может принимать несколько значений одновременно, перечисленных через запятую. Зачастую выглядит так:
 

Vary: Accept-Encoding

 
Данный пример, WEB-сервер удостоверяется у браузера сможет ли он принять сжатый контент, например, Gzip-ом. А такой вариант:
 

Vary: User-Agent

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

<IfModule mod_headers.c>
    <FilesMatch "\.(js|css|xml|gz)$">
        Header append Vary: User-Agent
    </FilesMatch>
</IfModule>

 
Итак, мы рассмотрели группу заголовков, алгоритмы которых призваны улучшить жизнь и пользователя, и WEB-сервера. По сути разные механизмы кеширования делают одну и туже работу, и вроде по факту дублируются операции. Почему так мне не попадалась информация на глаза, но логически алгоритмы кеширования, которые ведут диалог более медленные. И на просторах интернета я находил мнения о том, что такие диалоги нужно отключать, потому как для полноценного кеширования вполне хватает заголовков Expires и Cache-Control. А на примере Apache, убрать не нужное можно таким способом:
 

<ifModule mod_headers.c>
    <filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
        Header unset ETag
        FileETag None
    </filesMatch>
</ifModule>
<ifModule mod_headers.c>
    <FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css)$">
        Header unset Last-Modified
    </FilesMatch>
</ifModule>

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

В самом начале рекомендовал всю статику кешировать на 1 год, так как по сути большинство файлов никогда не изменяться и перезагружать их в кэш особого смысла нет. Но бывают случаи, когда файлы были отредактированы, но они жёстко сидят в кэше. Обычно это файлы стилей и скриптов. Но так как в кэше браузера все файлы привязаны к URL адресам, то обновить файлы у всех пользователей не составит труда.
 
Если добавить в URL адрес дополнительный GET параметр, то такой файл будет загружен заново. Итак, при каждом обновлении таких файлов, нужно менять значение GET параметра. В качестве значений оптимально использовать цифры, будет что-то наподобие версий файлов. Выглядит примерно так:
 

<link rel="stylesheet" media="all" type="text/css" href="/style.css?v=1">

 
Ну и куда же без ISPManager, который может сделать половину работы за вас через свой интерфейс. Включаем кеширование при наличии Nginx на WEB-сервере следующим путём: в боковом меню в блоке «WWW» переходим по ссылке «WWW-домены». Выбираем нужный домен и жмём по ссылке «Изменить» в верхнем меню. В открывшейся вкладке в самом низу блок «Оптимизация WWW-домена» устанавливаем галочку напротив опции «Настроить кэширование», и в появившихся полях выбираем период и указываем значение.

 

 

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

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

Сжатие
 
Выше я уже говорил про серверное сжатие «на лету», но оно хорошо для текстовых ресурсов. Для изображений используется другой алгоритм уменьшения веса. Его тоже можно автоматизировать, но мы рассмотрим ручной вариант сжатия. Не вижу никаких проблем уделить пару минут на сжатие картинок перед их заливкой на сервер. Ускорите не только сайт, но и сэкономите и диск и трафик.
 
Для оптимизации изображений существует множество десктопного ПО и онлайн инструментов. Мне очень понравился конкретно один, и для ручного сжатия я использую именно его - imagecompressor.com/ru/. Он отлично сжимает изображения png и jpg форматов. Прост и удобен в использовании.
 

 

 
После сжатия почти на 70% уменьшен вес с настройками по умолчанию. И качество на глаз ничуть не хуже. Можно погонять ползунок и сэкономить ещё больше. Благо превью интерактивное и перед сохранением показывает результат до и после компрессии. Очень удобно. Можно заливать изображения пачками и скачивать одним архивом.
 
Ну а для лентяев в наличии куча плагинов под все возможные CMS, которые сжимают изображения в момент их загрузки. Либо можно использовать самописные решения с использованием API таких сервисов, как tinypng.com. Ничего там сложного нет.
 

Форматы
 
Перед написанием статьи актуализировал свои знания в этой области и наткнулся на интересное решение по использованию графического формата webp, который был разработан Google. Я уже ранее сталкивался с ним, но что за зверь не знал. По заявлениям разработчиков данный формат графики легче на 26% чем png-формат, и на 25-34% чем jpeg. Данный формат также поддерживает сжатие с потерей и без потери качества, прозрачность и анимацию. Но есть, но.
 
Поддерживается не всеми современными браузерами, а только Google Chrome и Opera. Как решение проблемы предлагается создать копии картинок в формате webp и отдавать их только тем браузерам, которые способны его распознать. Не очень удобно, да и не каждый осилит. Но нашёл ещё такой вот код для Apache:
 

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

 
Вроде как активирует автоматическую конвертацию, но сам ещё не разбирался. Так что если кто-то захочет поковырять, то буду рад если поделитесь своим опытом.
 
 
Миниатюры
 
Очень часто на WEB страницах используются различного рода миниатюры изображений -  уменьшенного размера картинки. Это могут быть фото галереи, контент статей, картинки с изображением товара и т.д. На самом деле вариантов может быть просто уйма, где используются маленькие картинки при клике, по которым открывается большое изображение для более удобного просмотра.
 

 

 
Как бы получается два размера изображений – маленькое для превью и полноценное большое. Но часто бывает так, что большое изображение уменьшено лишь визуально, например, при помощи CSS, а фактически размер и вес прежний. И если страница изобилует такими визуально cжатыми изображениями, то представьте сколько нужно времени и трафика лишь только на загрузку всех картинок. Причём пользователь возможно и не будет открывать картинки для просмотра, ему хватит миниатюр. А смысл тогда грузить сразу большие изображения?
 
Выход здесь только один, делать миниатюры отдельно под нужный размер и выводить на страницу именно их. Причём сжимать превьюшки можно, или даже нужно с потерей качества для достижения максимально меньшего веса. А на оригинальном изображении не экономить, так как его загружать нужно только при клике по его миниатюре, то есть по фактической востребованности пользователем.
 
Таким образом вы не только ускорите страницу, но и сэкономите трафик и «нервы» WEB-сервера, и пользователя не обидите.
 
 
«Ленивая загрузка»
 
Технология AJAX мощная штука и позволяет обновлять контент или дозагружать его по мере необходимости и без перезагрузки страницы. Это может быть полезным для длинных страниц, где очень много контента. Когда пользователь загружает такую страницу он видит только ту её часть, которая помещается в размеры экрана его устройства. Всё что за пределами можно дозагружать по мере необходимости, то есть тогда, когда пользователь начнёт скролить страницу.
 
Например, это длинная статья, изобилующая картинками и прочими медиа элементами. Грузить все изображения, даже если это сильно сжатые миниатюры, смысла нет. Возможно пользователю не понравиться контент и скролить дальше начального экрана он не будет. Таким образом вы сократите изначальное количество обращений к серверу и ускорите страницу, сэкономите трафик.
 
Для популярных CMS также есть решения в виде плагинов. А для тех, кто любит сварганить своё – JavaScript, jQuery или другие аналоги в помощь.
 
 
Минимизация
 
Мы уже научились сжимать файлы и кешировать их, а сейчас рассмотрим, как ещё убрать лишний вес у текстовых файлов путём их минимизации.  Весь принцип минимизации сводиться к одному – убрать всевозможные лишние символы (пробелы, точки с запятой, табуляции, переносы, комментарии и т. д.) и выровнять содержимое внутри файла в одну строку. Да содержимое минимизированных файлов становиться трудно читаемым, но этот процесс легко обратим.
 
Наверняка вы уже встречались с такими файлами, так как большинство различных библиотек и фреймворков обычно поставляются в двух вариантах: с читабельным кодом и минимизированным. Как правило вторые имеют в своём названии ключевое слово min, либо лежат отдельно в одноимённой папке.
 

<scipt src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>

 
Применим данный метод уменьшения веса файлов обычно к CSS и JS файлам. Но также чистить можно и HTML документы. Первые два можно сжать ручками при помощи онлайн сервисов, например, jscompress.com.

 

 

 
Скриншот показывает сжатие библиотеки jQuery версии 3.3.1, где после минимизации JS файл уменьшил вес на более чем 68%. Сэкономлено 181 Kb веса, это весьма ощутимо.
 
С HTML файлами дела обстоят иначе, так как странички обычно генерируются автоматически средствами php-скриптов. И тут вроде только несколько решений оптимизации: средствами различных плагинов под CMS, серверные модули и иногда это умеют делать шаблонизаторы. Ещё сюда можно добавить CDN сети, но у нас они не распространены, по крайней мере я знаю только одну, и она не бесплатна.
 
Вот так вот мы можем ещё сэкономить несколько килобайтов убрав лишнее из содержимого.
 
 
WEB шрифты
 
С появлением возможности внедрять внешние шрифты в WEB-дизайны, появилась и необходимость оптимизировать их, так как существует ряд проблем при их загрузке влияющих на скорость отрисовки страницы.
 
Во-первых, шрифты - это дополнительные ресурсы, которые нужны до начала отрисовки страницы.

Во-вторых, зачастую шрифты подключается в других внешних файлах: CSS, JS. А они тоже загружаются не мгновенно. Плюс ко всему браузеру нужно разобраться нужны ли указанные шрифты конкретно на этой странице, а для этого ему нужно распарсить не только CSS файл, но и HTML.

В-третьих, с учётом плохого коннекта, нужно дополнительное время на загрузку, порой не маленького веса, шрифтов.

В-четвёртых, сегодня браузеры скрывают текст до полной загрузки кастомного WEB-шрифта, что приводит к эффекту мигания.
 
Всё это тормозит отрисовку страницы и естественно нервирует пользователя. Но и тут есть методы сокращения временных задержек для ускорения рендеринга страницы. Это CSS свойство font-display и атрибут rel="preload". Давайте разберёмся как ими пользоваться и что они из себя представляют.
 
 
CSS: font-display
 
font-display – это CSS свойство которое определяет способ загрузки и отображения шрифтов браузером. Применяется к правилу @font-face, с помощью которого задаются кастомные WEB-шрифты.
 

@font-face {
    font-family: customFont;
    src:  url(customFont.woff2') format('woff2'),
    url(customFont.woff') format('woff');
    font-display: fallback;
}

 
Может принимать следующие значения:
 
auto – браузер использует стандартный способ загрузки, схож со значение block;
 
block – браузер отрисовывает текст прозрачным цветом, а после загрузки шрифта отображает его. Происходит мигание невидимого текста.
 
fallback – браузер скрывает текст около 100 мл и если шрифт не успел загрузиться, то отображается стандартный шрифт до момента загрузки кастомного;
 
optional – идентичен значению fallback, за исключением того, что браузер определяет скорость сетевого соединения и на этом основании принимает решение о целесообразности загрузки кастомного шрифта;
 
swap – браузер отображает стандартный шрифт до момента загрузки кастомного. Также происходит мигание во время замены шрифта;
 
 
Предварительная загрузка

Для того, чтобы объяснить, что такое предварительная загрузка, для начала нужно немного рассказать, как работает браузер во время запроса URL адреса и до полной загрузки страницы. Конечно нужно было бы это сделать в самом начале, но не хотелось усложнять и так сложный материал. Но всё же приходиться это делать, итак, кратенько и, по существу.
 
После того, как браузер получил HTML, он начинает первоначальный разбор содержимого и первым делом загружает те ресурсы, которые встроенные в сам документ. Это <link rel=stylesheet>, <script>, <img>. Далее браузер начинает отрисовку и анализирует содержимое файлов, встроенных в HTML. В этот момент для дальнейшего рендеринга может возникнуть необходимость в загрузки критических ресурсов, найденных, например, в CSS или JS. Происходит остановка отрисовки до момента полной загрузки необходимых файлов.
 

 

Кастомные WEB-шрифты являются поздно обнаруживаемыми критическими ресурсами важными для рендеринга страницы, так как запрятаны в недрах CSS файла. И даже если предзагрузчик распарсил CSS, он не может быть уверен в необходимости шрифтов до тех пор, пока не разберётся с привязкой вызывающих их селекторов к конкретным узлам DOM дерева HTML документа. В противном случае происходила бы ложная загрузка не нужных ресурсов на странице.
 
Для того чтобы критически важные файлы загружались ранее чем браузер сможет определить их надобность, был разработан WEB стандарт предварительной загрузки, реализуемый путем HTTP-заголовков, либо путём тега link и параметра rel="preload", размещаемого в шапке HTML документа. Таким образом картина загрузки меняется следующим образом:
 

 

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

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

 
Атрибут rel указывает что этот файл нужно скачать заранее.
 
Атрибут as указывает тип скачиваемого ресурса, в нашем случае это font (шрифт). Обязательный атрибут, в противном случае браузер не будет знать какой тип файла он скачивает и делать это он будет с низким приоритетом.

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

Атрибут crossorigin обазятелен для предзагрузки шрифтов, так как она производится в анонимном режиме CORS. Более подробно про режим и атрибут предлагаю изучить самостоятельно.
 
 
Про предзагрузку здесь сказано очень мало, а она имеет очень большие возможности для ускорения отрисовки и выполнения различных скриптов. Упомянул лишь как вариант оптимизации внешних WEB-шрифтов, так что изучайте сей стандарт отдельно и более подробно. И ещё пару советов по оптимизации шрифтов:

• Используйте современные типы шрифтов WOFF2 и WOFF для поддержки старых браузеров.


• В наборе используйте только те символы, которые применяются на сайте, например, кириллица и латиница.


• Ну и выше сказанное o font-display и rel=preload ;)

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


Сообщение отредактировал Ixman - 23.1.2019, 14:44