Gzip-сжатие данных на сервере

GZIP-сжатие с помощью плагина

Если вы боитесь вносить изменения в файлы сайта, то вам проще всего установить плагин, который это сделает за вас. У WordPress есть простой и легкий плагин Check and Enable GZIP compression.

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

Итак, устанавливаем плагин Check and Enable GZIP compression. Сделать это можно прямо из админки WordPress. Переходите на вкладку Плагины — Добавить новый. В строку поиска копируете название плагина Check and Enable GZIP compression и жмете Enter Устанавливаете и активируете открывшийся плагин.

В меню Инструменты у вас появится новая строчка — GZIP Compression. Нажимаем на нее. Если GZIP-сжатие у вас включено, то вы увидите такую картинку:

Можете плагин удалять, он вам больше не понадобится.

Если же сжатия на вашем сайте нет, то картинка будет такая:

Нажмите на кнопку Enable GZIP Compression. Вот и все!!! Сжатие включилось! Если же вы, немного подучившись делать сайты на WordPress, перестанете бояться редактировать файлы сайта, то отключите GZIP-сжатие, нажав на кнопку Disable GZIP Compression, удалите плагин и действуйте в соответствие со следующей инструкцией:

2: Проверка стандартного поведения Nginx

Давайте проверим как обрабатывается HTML-файл test.html – со сжатием или без. Команда запрашивает файл с сервера Nginx и через HTTP-заголовок (Accept-Encoding: gzip) указывает, что можно использовать сжатый с помощью gzip контент:

В ответ вы должны увидеть несколько заголовков HTTP-ответа:

В последней строке вы можете увидеть заголовок Content-Encoding: gzip. Это говорит нам о том, что для отправки этого файла использовалось сжатие. Произошло это потому, что в Nginx сжатие включено автоматически – то есть даже в новой установке Ubuntu.

Однако по умолчанию Nginx сжимает только файлы HTML. Все остальные файлы будут обслуживаться без сжатия, что не совсем хорошо. Чтобы убедиться в этом, вы можете запросить тестовый файл test.jpg:

Результат будет немного отличаться от предыдущего:

В выводе заголовок Content-Encoding: gzip отсутствует, а это означает, что файл был обработан без сжатия.

Вы можете повторить тест с таблицей стилей CSS:

И снова в выводе не будет упоминания о сжатии:

Давайте настроим Nginx так, чтобы он мог сжимать все типы файлов, для которых полезно использовать gzip.

Эффективность Brotli в реальном мире +36

27.04.20 11:50

•
ru_vds
•
#499278
•
Хабрахабр

•
Перевод

•

5000

Блог компании RUVDS.com, Разработка веб-сайтов

Одним из наиболее фундаментальных правил разработки быстрых веб-сайтов является оптимизация их ресурсов. Если речь идёт о текстовых ресурсах — о коде, написанном на HTML, CSS и JavaScript, это значит, что мы говорим о сжатии данных.
Стандартом де-факто в деле сжатия текстовых ресурсов в веб является метод Gzip. А именно, около 80% сжатых ресурсов, получаемых при загрузках сайтов, сжаты с использованием Gzip. Для сжатия оставшихся 20% ресурсов используется гораздо более новый алгоритм — Brotli.
Конечно, в эти 100% сжатых ресурсов, поступающих в браузеры при получении ответов на запросы к сайтам, не входят абсолютно все ресурсы. Всё ещё существует множество ресурсов, которые могли бы быть сжаты, или которые стоило бы сжать. Но эти ресурсы так и остаются несжатыми. Более детальные показатели, касающиеся сжатия, можно найти в разделе Compression ресурса Web Almanac.
Метод сжатия Gzip невероятно эффективен. Все работы Шекспира в виде обычного текста занимают 5.3 Мб. А после Gzip-сжатия (уровень сжатия 6) они занимают всего 1.9 Мб. Это значит, что размер файла, в котором хранятся эти данные, уменьшился в 2.8 раза. При этом данные при сжатии не теряются. Замечательно!
Ещё лучше то, что на степень Gzip-сжатия влияет наличие в файлах повторяющихся строк. Чем больше в тексте повторов — тем эффективнее и сжатие. Это очень хорошо для веба, так как код, написанный на HTML, CSS и JS, отличается единообразным синтаксисом и содержит много повторений.
Но, хотя Gzip — весьма эффективный метод сжатия, он ещё и довольно старый. Он появился в 1992 году (что, конечно, помогает объяснить его широчайшую распространённость). Через 21 год, в 2013 году, компания Google выпустила Brotli — новый алгоритм, который обещает даже более высокие уровни сжатия, чем те, на которые способен метод Gzip. Те же работы Шекспира размером 5.2 Мб сжимаются с помощью Brotli до размера 1.7 Мб (с уровнем сжатия 6). А это уже означает уменьшение размеров файла в 3.1 раза. Это — ещё лучше, чем при использовании Gzip.
Используя инструмент для оценки уровня сжатия данных с использованием Gzip и Brotli, вы, вполне вероятно, выясните, что при сжатии некоторых данных Brotli оказывается намного эффективнее Gzip. Например, ReactDOM-данные оказываются на 27% меньше при сжатии с использованием Brotli с максимальным уровнем сжатия (11), чем при использовании Gzip с максимальным уровнем сжатия (9).
Вот сравнение Brotli-сжатия с Gzip-сжатием при обработке ReactDOM.

Уровень сжатия	Размер (в бвайтах)	Эффективность сжатия (в сравнении с несжатыми данными)	Улучшение в % по сравнению с Gzip
1	43456	2.73	3%
2	39898	2.97	11%
3	39416	3.08	15%
4	38488	3.08	15%
5	36323	3.27	19%
6	36048	3.29	20%
7	35804	3.31	20%
8	35709	3.32	21%
9	35659	3.33	21%
10	33590	3.53	25%
11	33036	3.59	27%

Проблемы, препятствующие использованию HTTP-сжатия

В статье 2009 года инженеров Google Арвинда Джейна и Джейсона Глазго говорится, что более 99 человеко-лет ежедневно тратятся впустую из-за увеличения времени загрузки страницы, когда пользователи не получают сжатый контент. Это происходит, когда антивирусное программное обеспечение мешает соединениям, чтобы заставить их быть несжатыми, когда используются прокси (с чрезмерно осторожными веб-браузерами), когда серверы настроены неправильно и когда ошибки браузера не позволяют использовать сжатие. Internet Explorer 6, который переходит на HTTP 1.0 (без таких функций, как сжатие или конвейерная обработка) при использовании прокси-сервера — обычная конфигурация в корпоративных средах — был основным браузером, наиболее склонным к сбоям в использовании несжатого HTTP.

Другая проблема, обнаруженная при развертывании HTTP-сжатия в крупном масштабе, связана с определением кодировки deflate : в то время как HTTP 1.1 определяет кодировку deflate как данные, сжатые с помощью deflate (RFC 1951) внутри потока в формате zlib (RFC 1950), серверные и клиентские продукты Microsoft исторически реализовал его как «сырой» дефлированный поток, что сделало его развертывание ненадежным. По этой причине некоторые программы, включая HTTP-сервер Apache, реализуют только кодировку gzip .

Что вообще влияет на скорость сайта (исследование более 5 млн. страниц)

Авторы известного блога Backlinko с его главой — Дином Брайаном исследовали выдачу Google и определили способы, которые используют владельцы сайтов с наиболее быстро открывающимися страницами. Результат исследования получился весьма масштабным, так как было проанализировано более 5 000 000 страниц, но из него можно выделить 3 основных тезиса:

Среднее время, за которое полностью загружается страница составляет 10,3 секунд для десктопа и 27,3 секунды для мобильных устройств.
Как это ни странно, но самые работающие методы — или минимально сжимать файлы перед их отправкой со стороны сервера, или максимально. Средний уровень сжатия работает хуже всего.
На скорость загрузки сайта на десктопе больше всего влияет CDN. А в мобильной версии — число HTML-запросов.

Как использовать brotli

Для включения в nginx поддержки brotli необходимо собрать, как минимум, модуль brotli_static и включить его в конфигурации:

brotli_static on;

В таком режиме nginx будет при получении от браузера соответствующего заголовка (что brotli поддерживается) проверять, есть ли файл с расширением .br рядом с запрашиваемым — и отдавать его как сжатый brotli-архив.

Для создания самих brotli-архивов нужно будет либо установить из репозитория, либо отдельно собрать утилиты bro:

git clone https://github.com/badger/libbrotli
cd libbrotli
autoreconf -i
make install
git clone https://github.com/google/brotli
cd brotli
./configure
make
chmod +x bro
./bro —quality 11 —input  —output

Можно дополнительно включить brotli-сжатие «на лету», установив модуль nginx brotli, но это может привести к дополнительным издержкам CPU при отгрузке страниц пользователям и ботам.

Для подключения brotli для IIS необходимо установить отдельный модуль: IIS Brotli, а для Apache есть mod_brotli, который настраивается аналогичным образом:

LoadModule brotli_module modules/mod_brotli.so

AddOutputFilterByType BROTLI text/html text/plain text/css text/xml
BrotliCompressionLevel 10
BrotliWindowSize 22

SDCH

От «швейцарского ножа» сжатия в Сети (brotli) переходим к более узкому инструменту — VCDIFF, или более известному как SDCH-сжатие.

VCDIFF предполагает использование заранее определенного словаря (который должен быть передан пользователю) и реализуется в браузерах через протокол SDCH (который является просто «оберткой» поверх VCDIFF контейнеров с данными).

Плюсом SDCH является то, что это альтернативный вариант сжатия, который можно использовать в дополнение к gzip или brotli: запаковать страницу при помощи SDCH-словаря, а запакованную версию дополнительно сжать «на лету», браузеры так понимают.

Минусом является достаточно сложный подготовительный процесс: необходимо создать словарь на основе нескольких страниц сайта, который будет содержать наиболее часто используемые блоки (чтобы передать их один раз) и не будет слишком большим (иначе будет «дешевле» передать сами страницы без SDCH-сжатия). Ниже показан примерный выигрыш в размере при использовании SDCH.

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

Детально механизм подключения описан в блоге Айри, кратко алгоритм выглядит следующим образом:

Нужно установить пакет femtozip для сборки словаря из наиболее характерных страниц сайта.
Нужно установить VCDIFF библиотеки на сервер для использования словаря при кодировании «на лету».
Нужно установить модуль nginx sdch для кодирования «на лету».
Нужно собрать словарь при помощи femtozip и дополнительно сжать его zopfli или brotli.
Нужно включить sdch-сжатие «на лету» для сайта в конфигурации nginx на базе собранного словаря.

3: Настройка gzip в Nginx

Чтобы изменить стандартную конфигурацию gzip в Nginx, откройте главный конфигурационный файл Nginx в nano или в другом текстовом редакторе:

Найдите раздел настроек gzip, который выглядит так:

Как видите, сжатие gzip действительно включено (директива gzip on), но некоторые дополнительные параметры закомментированы знаком # и не используются. Давайте внесем в этот раздел несколько изменений:

Раскомментируйте все закомментированные строки (удалив # в начале строки), чтобы активировать их.
Добавьте gzip_min_length 256; эта директива указывает Nginx не сжимать файлы размером менее 256 байт. Сжимать очень маленькие файлы практически не имеет смысла.
Добавьте в директиву gzip_types другие типы файлов (веб-шрифты, иконки, XML-каналы, структурированные данные JSON и изображения SVG).

После внесения этих изменений раздел должен выглядеть так:

Сохраните и закройте файл.

Чтобы включить новую конфигурацию, перезапустите Nginx:

Затем давайте убедимся, что новая конфигурация работает.

Альтернативы сжатию GZIP

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

За последние несколько лет широкую популярность приобрёл новый алгоритм сжатия: Brotli. Сжатие веб-шрифтов WOFF2 изначально было основным направлением деятельности Brotli. Но с тех пор оно расширилось, чтобы поддерживать сжатие для любого типа данных.

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

Большинство браузеров сегодня поддерживают Brotli, но использовать его на сайтах WordPress всё ещё довольно сложно. Вы должны разместить свой сайт у поставщика услуг хостинга. Который поддерживает Brotli или позволяет установить библиотеку Brotli. Большинство управляемых хостов WordPress ещё не поддерживают его напрямую, но если вы используете CDN, например Cloudflare или KeyCDN, вы можете легко включить его.

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

Последствия для безопасности

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

В 2012 году общая атака на использование сжатия данных под названием ПРЕСТУПЛЕНИЕ, было объявлено. Хотя атака CRIME могла эффективно работать против большого количества протоколов, включая, помимо прочего, TLS, и протоколы прикладного уровня, такие как SPDY или HTTP, были продемонстрированы эксплойты только против TLS и SPDY, и в браузерах и серверах они в значительной степени смягчены. Эксплойт CRIME против HTTP-сжатия вообще не был устранен, хотя авторы CRIME предупредили, что эта уязвимость может быть даже более распространенной, чем сжатие SPDY и TLS вместе взятые.

В 2013 году был опубликован новый пример CRIME-атаки на HTTP-сжатие, получивший название BREACH. Атака BREACH может извлекать токены входа, адреса электронной почты или другую конфиденциальную информацию из зашифрованного TLS веб-трафика всего за 30 секунд (в зависимости от количества байтов, которые нужно извлечь), при условии, что злоумышленник обманом заставляет жертву перейти по вредоносной веб-ссылке. Все версии TLS и SSL подвержены риску BREACH независимо от используемого алгоритма шифрования или шифра. В отличие от предыдущих экземпляров ПРЕСТУПЛЕНИЕ, от которого можно успешно защититься, отключив сжатие TLS или сжатие заголовков SPDY, BREACH использует сжатие HTTP, которое невозможно отключить, поскольку практически все веб-серверы полагаются на него для повышения скорости передачи данных для пользователей.

По состоянию на 2016 год, атака TIME и атака HEIST стали достоянием общественности.

Использовать кэш браузера для ускорения

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

Google рекомендует настроить сервер так, чтобы он возвращал ответ с HTTP-заголовком Cache-Control, например:

Cache-Control: max-age=31536000

Директива «max-age» указывает, как долго браузер должен кэшировать ресурс в секундах. Значение 31536000 соответствует году: 60 секунд * 60 минут * 24 часа * 365 дней = 31536000 секунд.

Google советует применять «no-cache» для объектов, которые могут обновляться: тогда браузер по-прежнему будет кэшировать ресурс со значением «no-cache», но сначала проверит актуальность на сервере.

Кэширование для Nginx

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

location ~* .(js|css|png|jpg|jpeg|gif)$ { expires 86400s; log_not_found off; }

Время можно указать в любом формате: секунды — s, часы — h, дни — d и месяцы — m, обозначение «max» указывает на кэширование навсегда.

Вместо времени хранения файла можно указать дату следующего обновления файла в кэше:

expires Fri, 24 Nov 2017 01:01:01 GMT;

Строка log_not_found off нужна для снижения нагрузки на сервер, она отключает ведение лога сообщений с ошибкой 404 для перечисленных файлов.

Метод Cache-Control

Метод позволяет указать для кэширования файлы конкретных форматов. В файле .htaccess в конструкции FilesMatch нужно указать расширения файлов для кэширования и время сохранения файла в кэше в секундах:

# 1 Month for most static assets <filesmatch «.(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf)$»=»»> Header set Cache-Control «max-age=2592000» </filesmatch>

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

<filesmatch «.(pl|php|cgi|spl|scgi|fcgi)$»=»»> Header unset Cache-Control </filesmatch>

Кэширование по времени

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

## EXPIRES CACHING ## <ifmodule mod_expires.c=»»> ExpiresActive On ExpiresByType image/jpg «access 1 year» ExpiresByType image/jpeg «access 1 year» ExpiresByType image/gif «access 1 year» ExpiresByType image/png «access 1 year» ExpiresByType text/css «access 1 month» ExpiresByType text/html «access 1 month» ExpiresByType application/pdf «access 1 month» ExpiresByType text/x-javascript «access 1 month» ExpiresByType application/x-shockwave-flash «access 1 month» ExpiresByType image/x-icon «access 1 year» ExpiresDefault «access 1 month» </ifmodule> ## EXPIRES CACHING ##

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

После сохранения нужно обновить страницу.

Проверить кэширование в Google Chrome можно с помощью веб-инспектора Chrome DevTools. Столбец Size в Chrome DevTools поможет убедиться, что ресурс в кэше:

Столбец Size в Chrome DevTool. Источник — Google

Вкладка Headers покажет, как установлен Cache-Control:

Проверка заголовка Cache-Control. Источник — Google

Как уменьшить размер HTML

Для уменьшения размера HTML-страницы нужно сжать код и облегчить элементы:

Избавиться от переадресации с целевой страницы. Google пишет о том, что перенаправления типа example.com → www.example.com → m.example.com или example.com → m.example.com/home для мобильных пользователей замедляют загрузку страницы.
Оформить HTML-элементы с помощью CSS, это ускорит загрузку и упростит работу с повторяющимися на страницах элементами.
Сжать все текстовые файлы HTML, XML, CSS, Javascript, сжать HTML-код страниц.
Использовать минификацию — удалить ненужные данные, которые увеличивают объем кода.
Сжать все графические файлы, оптимизировать изображения — фотографии и графику.
Использовать кэш браузера — кэшировать данные в браузере пользователя.
Оптимизировать нефункциональные анимационные детали, отказаться от flash — такие элементы вредят безопасности сайта и могут не поддерживаться у пользователей.
Оптимизировать количество рекламных блоков на странице.

Как проверить включено ли gzip сжатие

Проверить, работает или нет на сайте gzip сжатие, достаточно просто. Используйте возможности ресурса PageSpeed Insights от Google.

Вводим в строку для анализа URL интересующего сайта, ждем несколько минут. И затем изучаем советы по оптимизации. Если есть пункт «Включить сжатие», вполне логично, что оно не применяется.

На моем сайте оно конечно же включено:

Более подробно про данный инструмент Google я писал в статье Оптимизация PageSpeed Insights до 100 очков.

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

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

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

Проверить возможность запуска gzip сжатия на том или ином хостинге можно посредством функционала сервиса HTTP Compression Test.

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

В том случае, когда сжатие не присутствует, отразится в первой строке No. При этом останется неизменным размер файлов.

Brotli vs GZIP: Pick the One That’s Right For You

Both GZIP and Brotli help you compress your WordPress website’s files. GZIP is the older and more popular of the two, while Brotli is newer but picking up steam.

While Brotli does seem to outperform GZIP in some benchmarks, especially when you play around with its configuration, GZIP is probably still a better starting point for most WordPress users because:

It’s much easier to use with WordPress because almost every host supports GZIP out of the box.
It’s still quite competitive in benchmarks and will have a positive effect on your site’s page load times.

If you have the ability to manually install Brotli on your server, or if you’re willing to use Cloudflare, Brotli is certainly still a good option. It’s just not as popular, and therefore not as easy to use with WordPress.

Either way, remember that text compression helps improve the Largest Contentful Paint and the First Input Delay metrics. And that’s also why you should take care of it.

HTTP-запросы и поиск DNSСкопировать ссылку

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

С этим, однако, есть и проблема — DNS-запросы. Каждый раз, когда делается запрос к новому домену (с холодного кэша), HTTP-запрос должен произвести довольно долгий DNS-запрос (между 20 и 120 мс). За это время исходящий запрос смотрит, где же, собственно, находится ресурс: интернет организован с помощью IP-адресов, на которые ссылаются доменные имена, которые, в свою очередь, управляются DNS.

В обращение к каждому новому домену, с которого вы запрашиваете ресурсы, включена стоимость DNS-запроса, и вам нужно быть уверенным, что оно того стоит. Если вас сайт небольшой (как, например, CSS Wizardry), тогда вам, скорее всего, не стоит раздавать ресурсы с поддомена: браузер, вероятно, сможет скачать несколько ресурсов с одного домена без параллелизации быстрее, чем сделать DNS-запросы на несколько доменов и распараллелить загрузку ресурсов с них.

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

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

Важно помнить, что, если HTML уже запрошен с домена, скажем, , DNS-запрос для этого хоста уже произошёл, так что дополнительные запросы к любому ресурсу на больше не проходят через DNS-запрос

Предзагрузка DNSСкопировать ссылку

Если вы, как и я, хотите, чтобы у вас на сайте был виджет Twitter, аналитика или какие-то веб-шрифты, то вам нужно будет ссылаться на внешние домены. Это означает, что вам нужно будет тратить время на DNS-запросы. Мой совет: не использовать какие попало виджеты, не обдумав заранее их влияние на быстродействие. Но если вы решили, что какой-то виджет вам необходим, полезно знать следующее.

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

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

Что делает предзагрузка DNS, понятно из названия; реализовать её очень просто. Если вам нужно запросить ресурсы, скажем, с , вы можете предзагрузить DNS для этого поддомена, просто добавив в начале страницы в секции :

Эта простая строчка объявит браузерам, которые поддерживают предзагрузку, что им стоит начать загружать DNS для этого домена за долю секунды до того, как это понадобится сделать для загрузки ресурса. Таким образом, когда браузер дойдёт до элемента , запрашивающего виджет, DNS-запрос уже будет запущен. Так браузер чуть-чуть опережает события.

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

Несколько слов об оптимизации картинок для ускорения загрузки сайта

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

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

Настроить отложенную загрузку можно несколькими способами:

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

Также вам обязательно стоит использовать webp для сайта — формат графики, который создали в Google в 2010 году. Это некая альтернатива jpg и png, которая отличается куда более меньшим размером. При этом, в таких картинках сохраняется прозрачный фон и анимация.