Сжатие страниц gzip и brotli: минус 70 % веса, который вы теряете бесплатно

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

С 2005 года я разбираю технические причины медленных сайтов, и несжатый текстовый контент до сих пор попадается на каждом пятом проекте, который приносят на диагностику. Причём чаще не на самописных сайтах, а на обычном WordPress у обычного хостера — потому что «оно же само должно работать». Не само. Ниже — механика целиком: как браузер и сервер договариваются, чем brotli лучше gzip, что сжимать нельзя, как проверить свой сайт тремя способами и как включить сжатие на Apache, nginx, shared-хостинге и в WordPress. Если разбираться самому некогда, я делаю это внутри SEO-продвижения сайта под ключ вместе с остальной технической частью.

Что вообще происходит, когда сервер отдаёт страницу несжатой

HTML, CSS и JavaScript — это текст. Текст крайне избыточен: в разметке сотни раз повторяются <div class=", в стилях — margin, padding, color, в скриптах — имена функций и переменных. Алгоритмы сжатия ровно на этом и живут: они находят повторяющиеся куски и заменяют их короткими ссылками на первое вхождение. Поэтому текстовый файл ужимается в 3–5 раз, а иногда и сильнее.

Когда сжатие выключено, сервер берёт файл с диска (или результат работы PHP) и отправляет байт в байт. Страница на 320 КБ так и уезжает в канал как 320 КБ. Когда сжатие включено, тот же ответ уходит как 60–70 КБ, а браузер разворачивает его обратно за единицы миллисекунд — распаковка на порядки дешевле сжатия и на любом смартфоне незаметна.

Что это даёт по существу:

• Быстрее приходит HTML — а значит раньше стартует парсинг и раньше находятся ссылки на CSS и шрифты. Это напрямую двигает первую отрисовку и LCP.
• Меньше пакетов в медленной сети. На мобильном интернете вне города разница между 300 КБ и 70 КБ — это разница между «открылось» и «закрыл вкладку».
• Дешевле трафик на тарифах с лимитом и меньше нагрузка на канал сервера в часы пик.
• Роботу проще обходить сайт. Чем быстрее отдаётся документ, тем больше страниц робот успевает скачать за сеанс — это прямо связано с тем, как расходуется краулинговый бюджет сайта.

Важно сразу развести два понятия, которые постоянно путают. Минификация — это удаление пробелов и переносов из CSS и JS, работа с самим файлом. Сжатие — это упаковка ответа на лету при передаче, файл на диске не меняется. Они не заменяют, а дополняют друг друга: минифицированный CSS всё равно сжимается ещё в 3–4 раза, потому что повторов в нём остаётся полно.

Как браузер и сервер договариваются: Accept-Encoding и Content-Encoding

Механизм называется согласованием содержимого и описан в стандарте HTTP. Он предельно простой и занимает ровно две строки заголовков.

Шаг первый. Браузер в каждом запросе сообщает, какие алгоритмы он умеет разворачивать:

GET / HTTP/1.1
Host: example.ru
Accept-Encoding: gzip, deflate, br, zstd

Здесь gzip — древний и универсальный, deflate — его же ядро без обёртки (на практике почти не используется), br — brotli, zstd — Zstandard, самый молодой из массовых.

Шаг второй. Сервер выбирает то, что умеет сам, сжимает ответ и честно об этом пишет:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Encoding: br
Vary: Accept-Encoding

Если строки Content-Encoding в ответе нет — сжатия нет. Это единственный надёжный признак, всё остальное домыслы.

Третья строка не менее важна. Vary: Accept-Encoding говорит всем промежуточным кэшам — прокси провайдера, CDN, кэшу самого сервера, — что ответ зависит от заголовка запроса и для разных браузеров варианты разные. Без неё кэш способен положить сжатый brotli-ответ и отдать его клиенту, который brotli не понимает: пользователь увидит кракозябры или пустую страницу. На nginx за это отвечает gzip_vary on;, Apache добавляет заголовок сам. Отдельно проверяйте это, если перед сайтом стоит CDN или кэширующий плагин — именно здесь чаще всего ломается связка и рождаются жалобы вида «у всех работает, а у одного клиента белый экран». Смежная история про рассинхрон версий страницы разобрана в материале о том, почему после правок вы видите старую страницу, а робот — новую.

Отдельно отмечу: сжатие не влияет на содержимое документа. Робот Яндекса и Google получают ровно тот же HTML, что и человек, просто быстрее. Никакой «маскировки» здесь нет и быть не может — это транспортный уровень.

gzip против brotli: чем они отличаются и при чём тут HTTPS

gzip появился в девяностых, реализован буквально везде и понимается любым клиентом, включая древние библиотеки и парсеры. brotli — алгоритм от Google, опубликованный как открытый стандарт в 2016 году, и он изначально проектировался под веб. Его главное отличие — встроенный словарь на 13 тысяч частых фрагментов из реальных веб-документов: </div>, http://, function, charset=utf-8. Эти куски не нужно описывать в теле файла, на них достаточно сослаться. Именно поэтому на маленьких HTML-документах brotli выигрывает у gzip заметнее всего.

Параметр	gzip	brotli	zstd
Значение в Content-Encoding	gzip	br	zstd
Поддержка браузерами	Полная, включая старьё	Все актуальные браузеры	Chrome, Edge, Firefox новых версий
Уровни сжатия	1–9	0–11	1–19 (и выше)
Выигрыш к gzip на HTML	—	примерно 15–20 %	сопоставимо с brotli
Скорость сжатия на лету	Высокая	Высокая на уровнях 4–5	Очень высокая
Скорость распаковки	Высокая	Сопоставима с gzip	Выше gzip
Работает по HTTP без шифрования	Да	Браузеры не запрашивают	Браузеры не запрашивают
Роль на практике	Базовый, обязателен	Основной для современных клиентов	Опционально, если модуль собран

Теперь про HTTPS, вокруг которого много путаницы. Сам алгоритм brotli к шифрованию отношения не имеет и прекрасно работает по обычному HTTP. Ограничение введено на стороне браузеров: Chrome и Firefox добавляют br в Accept-Encoding только на защищённых соединениях. Причина техническая — на открытом HTTP промежуточные узлы (прокси провайдеров, корпоративные фильтры, «оптимизаторы трафика» мобильных операторов) любят вмешиваться в тело ответа и ломают нестандартные для них кодировки.

Практический вывод простой: сервер может быть настроен идеально, но если сайт открывается по http://, браузер не попросит brotli и получит gzip. Так что порядок работ такой — сначала рабочий сертификат и корректный переезд на HTTPS, потом brotli. И оставлять gzip включённым обязательно: он остаётся запасным вариантом для всех, кто brotli не поддерживает.

Что сжимать, а что трогать нельзя

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

Тип содержимого	MIME-тип	Типичное сокращение	Сжимать?
HTML-документ	text/html	70–85 %	Да, обязательно
CSS	text/css	75–85 %	Да
JavaScript	application/javascript	65–80 %	Да
JSON, ответы API	application/json	80–92 %	Да
XML, RSS, sitemap.xml	application/xml, text/xml	75–90 %	Да
SVG-иконки и логотипы	image/svg+xml	60–80 %	Да
Шрифты TTF, OTF, EOT	font/ttf, font/otf	40–60 %	Да
Шрифты WOFF	font/woff	0–3 %	Нет, внутри уже zlib
Шрифты WOFF2	font/woff2	0 %	Нет, внутри уже brotli
Простой текст, robots.txt	text/plain	60–80 %	Да
JPEG	image/jpeg	0–2 %	Нет
PNG	image/png	0–2 %	Нет, внутри deflate
WebP, AVIF	image/webp, image/avif	0 %	Нет
Видео и аудио	video/mp4, audio/mpeg	0 %	Нет, категорически
Архивы	application/zip, application/gzip	0 %	Нет
PDF	application/pdf	0–10 %	Обычно нет

Два уточнения из практики. Первое: WOFF2 сжимать не просто бесполезно, а вредно — формат уже использует brotli внутри себя, и повторный проход добавит несколько байт и десятки миллисекунд процессорного времени. Второе: SVG постоянно забывают, потому что он лежит в голове как «картинка». А это XML-текст, и на наборе иконок сжатие даёт очень много — включайте image/svg+xml в список обязательно.

И третье, менее очевидное: очень маленькие файлы сжимать не нужно. У gzip и brotli есть служебные заголовки, и файл на 150 байт после «сжатия» может стать больше исходного. Поэтому в конфигах задают минимальный порог — обычно 256 или 1024 байта.

Как за пять минут проверить, сжимается ли ваш сайт

Проверять надо не «сайт», а конкретные ответы: HTML главной, HTML внутренней страницы, файл стилей, файл скриптов. Сплошь и рядом бывает, что HTML сжимается, а статику отдаёт другой обработчик со своими настройками — и там пусто.

Способ первый: инструменты разработчика в браузере

Откройте сайт, нажмите F12, перейдите на вкладку Network и перезагрузите страницу с очисткой кэша. Дальше:

1. Найдите в списке самую первую строку — сам документ.
2. Смотрите колонку Size. В ней два значения: сверху — сколько реально передано по сети, снизу серым — исходный размер ресурса. Если числа совпадают, сжатия нет.
3. Кликните по строке, откройте вкладку Headers и в блоке ответа найдите content-encoding. Там должно быть br или gzip.
4. Правым кликом по шапке таблицы можно добавить постоянную колонку Content-Encoding — тогда сразу видно всю картину по всем файлам страницы.

Обратите внимание на строки, где передано столько же, сколько весит файл, и при этом расширение .css или .js. Это ваши потери.

Способ второй: curl из терминала

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

curl -I -H "Accept-Encoding: gzip, br" https://example.ru/

В ответе ищем content-encoding. Чтобы увидеть выигрыш в байтах, делаем два запроса и сравниваем размер:

curl -s -o /dev/null -w "без сжатия: %{size_download} байт\n" \
     -H "Accept-Encoding: identity" https://example.ru/

curl -s -o /dev/null -w "brotli:     %{size_download} байт\n" \
     -H "Accept-Encoding: br" https://example.ru/

Если оба числа одинаковые — сервер игнорирует запрос и отдаёт сырьё. Тем же способом проверяйте отдельные файлы: подставьте вместо адреса главной прямую ссылку на style.css и на главный скрипт темы.

Способ третий: внешние проверки

PageSpeed Insights и любой аудит на движке Lighthouse выдают отдельный пункт «Включите сжатие текста» с перечнем файлов и потенциальной экономией в килобайтах — удобно, чтобы показать подрядчику или хостеру конкретный список. В Яндекс.Вебмастере скорость видна агрегированно, по конкретным заголовкам он не отчитывается. Есть и узкоспециальные онлайн-проверки сжатия, где достаточно вбить URL, но я предпочитаю curl: он показывает сырой ответ без интерпретаций.

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

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

Apache: .htaccess, mod_deflate и mod_brotli

На Apache сжатие включает модуль mod_deflate (несмотря на название, он выдаёт именно gzip). Он есть практически у всех хостеров и в подавляющем большинстве случаев разрешён к использованию из .htaccess. Рабочий блок:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
  AddOutputFilterByType DEFLATE application/javascript application/x-javascript
  AddOutputFilterByType DEFLATE application/json application/xml
  AddOutputFilterByType DEFLATE application/rss+xml image/svg+xml
  AddOutputFilterByType DEFLATE font/ttf font/otf application/vnd.ms-fontobject
  DeflateCompressionLevel 6
  <IfModule mod_headers.c>
    Header append Vary Accept-Encoding
  </IfModule>
</IfModule>

Если на сервере собран mod_brotli, добавляем его отдельным блоком — он имеет приоритет, когда браузер прислал br:

<IfModule mod_brotli.c>
  AddOutputFilterByType BROTLI_COMPRESS text/html text/css text/plain
  AddOutputFilterByType BROTLI_COMPRESS application/javascript application/json
  AddOutputFilterByType BROTLI_COMPRESS application/xml image/svg+xml
  BrotliCompressionQuality 5
</IfModule>

Конструкция <IfModule> здесь не украшение, а страховка: если модуля нет, блок просто игнорируется и сайт не падает с ошибкой 500. Это важно на shared-хостинге, где вы не знаете точный набор модулей. Кстати, если после правки .htaccess сайт всё же отдал пятисотую, причина почти всегда в директиве, которую сервер не понимает: уберите последний добавленный блок и проверьте снова.

Ещё одна ловушка Apache: правило работает по Content-Type, который сервер сам проставляет по расширению. Если ваш сервер отдаёт скрипты как text/javascript, а в списке у вас только application/javascript, файл не попадёт под сжатие. Перечисляйте оба варианта.

nginx: gzip_types, gzip_min_length и статические копии

У nginx нет и не будет аналога .htaccess: настройки правятся в конфиге и применяются перезагрузкой сервиса. Базовый блок в http {} или в конкретном server {}:

gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_vary on;
gzip_proxied any;
gzip_types
  text/plain text/css text/xml
  application/javascript application/json application/xml
  application/rss+xml image/svg+xml
  font/ttf font/otf;

Здесь два места, на которых спотыкаются чаще всего.

Первое. Тип text/html в gzip_types писать не нужно — nginx сжимает HTML всегда, как только включён gzip on. Дублирование ничего не сломает, но и смысла не имеет.

Второе. Значение gzip_comp_level по умолчанию равно единице — то есть формально сжатие включено, а выигрыш минимальный. Ставьте 5 или 6.

Дальше — приём, который экономит процессор радикально. Статику (CSS, JS, шрифты, SVG) можно сжать заранее, один раз, на максимальном уровне и положить рядом с оригиналом файлы style.css.gz и style.css.br. Тогда сервер не тратит время на каждый запрос, а просто отдаёт готовую копию:

gzip_static on;
brotli_static on;

brotli on;
brotli_comp_level 5;
brotli_types text/css application/javascript application/json image/svg+xml;

Директивы brotli* требуют собранного модуля ngx_brotli — на VPS он ставится, на большинстве панелей управления присутствует, а вот на простом виртуальном хостинге его может не быть. Проверить наличие можно по ответу сервера: если Content-Encoding: br не появляется даже при явном запросе, модуля нет.

И отдельно про связку nginx + Apache, распространённую на панелях управления. Там nginx обычно отдаёт статику напрямую, минуя Apache, а динамику проксирует. Из этого следует неприятное: правила сжатия из .htaccess на CSS и JS не подействуют вообще, потому что Apache этих файлов не видит. Проверяйте оба слоя отдельно — HTML и статику.

Уровни сжатия и их цена: почему максимум не лучший выбор

У каждого алгоритма есть шкала «сильнее сжимаем — больше тратим процессора». И зависимость там нелинейная: последние проценты объёма стоят кратно дороже первых.

Уровень	Алгоритм	Объём относительно уровня 1	Нагрузка на CPU	Где применять
1	gzip	базовый	Минимальная	Очень нагруженные API
5–6	gzip	меньше на 8–12 %	Умеренная	Оптимум для HTML на лету
9	gzip	меньше на 10–14 %	Высокая, растёт в разы	Только для статики заранее
4–5	brotli	примерно как gzip 9	Умеренная	Оптимум для HTML на лету
11	brotli	меньше ещё на 10–15 %	Очень высокая	Только предварительное сжатие файлов

Логика выбора укладывается в одно правило. Динамика — средние уровни, статика — максимум заранее. HTML генерируется на каждый запрос, и если вы поставите brotli 11 на выдачу страниц, сервер будет тратить заметное время процессора на каждого посетителя — время до первого байта вырастет, и вы проиграете больше, чем выиграете на объёме. А CSS и JS меняются раз в месяц: их не жалко один раз пережать на одиннадцатом уровне при деплое.

Здесь же кроется частая диагностическая ошибка. Если после включения агрессивного сжатия страница стала «медленнее ощущаться», смотрите не на вес, а на TTFB — он мог вырасти. Как отделить задержку сервера от задержки сети, я подробно разбирал в статье про то, куда исчезает секунда до первого байта.

Shared-хостинг и WordPress: что делать без доступа к конфигу

Если сайт лежит на виртуальном хостинге, конфига nginx у вас нет. Порядок действий такой.

Сначала — панель управления. В ISPmanager, cPanel и большинстве панелей хостеров есть переключатель сжатия. В cPanel это раздел Optimize Website, где можно включить сжатие всего содержимого или только выбранных MIME-типов. Часто вопрос решается одной галочкой.

Потом — .htaccess. Блоки из раздела про Apache безопасны и работают на большинстве тарифов. Обёртка <IfModule> защищает от падения.

Потом — письмо в поддержку. Формулировка, которая работает: «На моём тарифе для домена example.ru ответы отдаются без Content-Encoding. Прошу включить gzip для text/html, text/css и application/javascript, а если собран модуль brotli — то и его». Приложите вывод curl -I с явным Accept-Encoding. С конкретикой отвечают быстрее и по делу.

Крайний вариант. Если ничего не вышло, сжатие можно поднять на уровне PHP через zlib.output_compression. Работает, но это худший из способов: PHP жмёт медленнее сервера и часто конфликтует с кэширующими плагинами, которые пишут на диск уже сжатый буфер. Если хостер не умеет включить gzip на своём сервере в 2026 году — это, честно говоря, сигнал о качестве площадки в целом, и вопрос переезда стоит рассмотреть всерьёз.

Теперь про WordPress. Собственной настройки сжатия в ядре нет, задача решается кэширующим плагином. Логика у всех похожая: плагин собирает готовый HTML страницы, кладёт его на диск и параллельно сохраняет .gz-версию, которую сервер отдаёт напрямую, не запуская PHP вообще. В WP Super Cache это отдельная опция сжатия страниц, в W3 Total Cache — раздел Browser Cache с чекбоксом gzip, в LiteSpeed Cache сжатие работает связкой с сервером LiteSpeed и включает brotli.

Два предупреждения. Не включайте сжатие одновременно в плагине и на сервере — двойная упаковка приводит к битым ответам, и симптом бывает пугающий: у части посетителей вместо страницы набор символов. Выбирайте один слой. И не ставьте второй кэширующий плагин к уже работающему: конфликт обработчиков буфера — классическая причина белого экрана. Что вообще тормозит WordPress помимо очевидного, я разбирал в материале WordPress тормозит не из-за плагинов.

Когда сжатие не поможет

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

Страница весит мегабайты из-за фотографий. Это самый частый случай. Если документ на 6 МБ состоит из 5,7 МБ картинок в JPEG прямо из фотоаппарата, сжатие текста уберёт 200 КБ из оставшихся 300 КБ. Пользователь разницы не почувствует. Сначала картинки: правильные размеры, современные форматы, отложенная загрузка — про это есть отдельный разбор, как картинки съедают скорость WordPress.

Сервер долго думает перед ответом. Если PHP формирует страницу две секунды, а браузер получает первый байт через 2,1 секунды, экономия 180 КБ ничего не изменит — узкое место в базе данных, запросах или тарифе. Сжатие уменьшает время передачи, а не время генерации.

Сайт грузит 40 сторонних скриптов. Виджеты чатов, счётчики, пиксели, карты — они приходят с чужих доменов, и их сжатие вы не контролируете. Ваш HTML станет легче, а общее время загрузки останется прежним. Ситуация особенно типична для сайтов на визуальных конструкторах — механику я описывал в статье про Elementor и шесть секунд загрузки.

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

У страницы нет проблем со скоростью. Если документ весит 40 КБ и уже открывается мгновенно, экономия 25 КБ на позиции не повлияет. Скорость — фактор порогового типа: она наказывает за плохо, но не награждает бесконечно за «ещё лучше». Об этом я писал в разборе про Core Web Vitals и рост позиций.

И ещё один сюжет: сжатие не чинит проблемы индексации. Если страницы не попадают в поиск, причина в robots.txt, канониклах, редиректах или ответах сервера, а не в весе документа.

Коротко

• Браузер сам просит сжатие заголовком Accept-Encoding. Если сервер не отвечает заголовком Content-Encoding, вы отдаёте текст в исходном виде и теряете 60–85 % веса впустую.
• gzip — обязательный минимум и совместим со всем. brotli даёт ещё 15–20 % сверху, но браузеры запрашивают его только по HTTPS.
• Сжимать нужно HTML, CSS, JS, JSON, XML, SVG, шрифты TTF и OTF. Не нужно — JPEG, PNG, WebP, AVIF, видео, архивы, WOFF и WOFF2: они уже упакованы.
• Проверка занимает пять минут: вкладка Network и колонка Size, либо curl -I -H "Accept-Encoding: gzip, br".
• Уровень сжатия на лету — средний (gzip 5–6, brotli 4–5). Максимум применяют только к заранее сжатым статическим копиям файлов.
• Обязательно отдавайте Vary: Accept-Encoding, иначе кэши и CDN перепутают варианты ответа.
• Не включайте сжатие в двух местах сразу — на сервере и в плагине. Двойная упаковка ломает страницу.
• Если страница тяжёлая из-за фотографий или сервер долго думает, сжатие текста проблему не решит. Сначала лечите главную причину.

Чеклист: проверить и внедрить

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

Шаг	Что делаю	Чем проверяю результат
1	Проверяю HTML главной на наличие Content-Encoding	curl -I с заголовком Accept-Encoding
2	Проверяю отдельно CSS, JS и SVG — статику часто отдаёт другой обработчик	Вкладка Network, колонка Content-Encoding
3	Смотрю, открывается ли сайт по HTTPS без ошибок сертификата	Адресная строка, отсутствие смешанного содержимого
4	Включаю gzip: галочка в панели хостинга, .htaccess или конфиг nginx	Повторный curl, ответ содержит gzip
5	Добавляю brotli, если модуль доступен	Ответ содержит br при запросе с Accept-Encoding: br
6	Проверяю список типов: HTML, CSS, JS, JSON, XML, SVG, TTF	Точечный запрос к файлу каждого типа
7	Убеждаюсь, что медиа и WOFF2 из списка исключены	У картинок и woff2 нет Content-Encoding
8	Ставлю уровень сжатия 5–6 для gzip и 4–5 для brotli на динамике	Конфиг сервера, замер TTFB до и после
9	Задаю минимальный размер ответа 256 байт	gzip_min_length в конфиге
10	Проверяю наличие Vary: Accept-Encoding	Заголовки ответа, особенно за CDN
11	Убеждаюсь, что сжатие включено только в одном слое	Настройки кэш-плагина и сервера не дублируют друг друга
12	Открываю сайт в двух браузерах и на телефоне	Нет искажённого текста и белых экранов
13	Прогоняю страницу через аудит скорости	Пункт «Включите сжатие текста» исчез из списка
14	Через сутки повторяю проверку	Настройки не сброшены панелью управления

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

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