Как ускорить сайт: что реально влияет на скорость загрузки
Чтобы ускорить сайт, в первую очередь работают с четырьмя вещами: временем ответа сервера, весом и форматом изображений, объёмом JavaScript (особенно сторонних виджетов) и подключением шрифтов и стилей. На большинстве медленных сайтов 80 % проблемы сидит в одной-двух из этих зон, и исправить их можно без переделки сайта целиком. Минификация HTML, перестановка тегов и погоня за 100 баллами в PageSpeed дают намного меньше, чем кажется. Ниже по порядку: как измерить скорость загрузки, что на неё реально влияет и с чего начинать.
Сначала измерьте: инструменты и метрики
Начинать с исправлений, не измерив, бессмысленно: вы не узнаете, что помогло. Для замеров хватит бесплатных инструментов.
| Инструмент | Что показывает |
|---|---|
| PageSpeed Insights | лабораторный замер и полевые данные реальных посетителей Chrome |
| Lighthouse в DevTools | тот же лабораторный замер локально, удобно для проверки правок |
| Вкладка Network в DevTools | что грузится, сколько весит, в каком порядке |
| Метрика, отчёт «Время загрузки страниц» | скорость у ваших реальных посетителей, включая Яндекс Браузер |
| WebPageTest | подробная водопадная диаграмма загрузки, замеры из разных точек |
Главные метрики Core Web Vitals и их пороги:
| Метрика | Что измеряет | Хорошо | Плохо |
|---|---|---|---|
| LCP | когда отрисовался самый крупный элемент первого экрана | до 2,5 с | больше 4 с |
| INP | как быстро страница реагирует на клик или ввод | до 200 мс | больше 500 мс |
| CLS | насколько прыгает вёрстка при загрузке | до 0,1 | больше 0,25 |
| TTFB | через сколько сервер начал отдавать страницу | до 0,8 с | больше 1,8 с |
Замеряйте не только главную. Возьмите три-четыре шаблона: главную, раздел каталога или список услуг, карточку товара, статью. Медленным часто оказывается шаблон, который никто не проверял. И смотрите мобильный результат: PageSpeed эмулирует средний смартфон на медленной сети, именно там проблемы видны лучше всего.
Сервер и время ответа
Если TTFB больше секунды, всё остальное вторично: браузер ждёт, пока сервер соберёт страницу, и только потом начинает загружать картинки и скрипты.
Почему сервер отвечает медленно:
- Дешёвый виртуальный хостинг с сотнями соседей на одном сервере. В часы пик ваш сайт ждёт очереди.
- Старая версия PHP. Переход с PHP 7.x на 8.x часто даёт заметный прирост без единой правки кода. Проверьте, что включён OPcache.
- Нет кеширования страниц. CMS собирает каждую страницу заново: десятки запросов к базе, обработка шаблонов. Для WordPress есть плагины полностраничного кеша, в Webasyst кеширование включается в настройках, на уровне сервера можно настроить кеш в nginx.
- Тяжёлые запросы к базе. Каталог на десятки тысяч товаров без индексов в таблицах, фильтры, которые пересчитывают всё на лету. Тут нужен разработчик и профилировщик.
- Сервер далеко от аудитории. Хостинг в Европе для посетителей из Новосибирска добавляет задержку на каждое соединение.
Самый радикальный способ убрать проблему с сервером: не собирать страницы на лету вообще. При статической генерации (Astro, Hugo, Eleventy) все страницы заранее собираются в готовые HTML-файлы, и сервер просто отдаёт файл. TTFB у таких сайтов измеряется десятками миллисекунд.
Изображения
На большинстве сайтов картинки составляют больше половины веса страницы. Типичная история: на главную загрузили фото с фотоаппарата на 5 МБ, а показывается оно в блоке шириной 600 пикселей.
Что делать:
- Сжимать и уменьшать. Картинка не должна быть больше, чем её максимальный размер на экране с учётом плотности пикселей. Для блока шириной 600 пикселей хватит файла шириной 1200.
- Использовать современные форматы. WebP легче JPEG на 25-35 % при том же качестве, AVIF ещё легче. Все актуальные браузеры их поддерживают.
- Отдавать разные размеры под разные экраны через
srcset, чтобы смартфон не качал картинку для широкого монитора. - Указывать ширину и высоту. Без
widthиheightбраузер не знает, сколько места оставить, и вёрстка прыгает, когда картинка загрузилась. Это прямой путь к плохому CLS. - Откладывать загрузку картинок ниже первого экрана через
loading="lazy". Но главное изображение первого экрана откладывать нельзя: наоборот, его стоит загружать с повышенным приоритетом.
Как это выглядит в коде:
<!-- главное фото первого экрана -->
<img src="/img/hero-1200.webp"
srcset="/img/hero-600.webp 600w, /img/hero-1200.webp 1200w"
sizes="(max-width: 640px) 100vw, 600px"
width="1200" height="800"
fetchpriority="high" alt="Монтаж кондиционера в квартире">
<!-- картинки ниже по странице -->
<img src="/img/work-1.webp" width="800" height="600"
loading="lazy" alt="Пример работы">На сайтах с большим каталогом конвертировать картинки вручную нереально. Здесь помогает автоматическая обработка при загрузке: CMS или скрипт на сервере сами делают WebP нужных размеров.
JavaScript и сторонние виджеты
Второй по частоте виновник медленного сайта. Причём проблема обычно не в коде самого сайта, а в том, что подключено поверх него: онлайн-чат, виджет обратного звонка, коллтрекинг, квиз, всплывающие окна, пиксели соцсетей, карта, видео с внешнего сервиса. Каждый такой виджет тянет свои скрипты, а в сумме набирается 1-2 МБ JavaScript, который браузер должен скачать и выполнить.
Именно сторонние скрипты чаще всего портят INP: страница загрузилась, а на клик реагирует с задержкой, потому что основной поток занят чужим кодом.
Что делать:
- Провести инвентаризацию. Откройте DevTools, вкладку Network, отфильтруйте по JS и отсортируйте по размеру. Часто находятся виджеты, от которых давно отказались, а код остался.
- Убрать лишнее. Два чата и три виджета обратного звонка на одной странице не нужны никому.
- Отложить загрузку. Виджет чата не нужен в первую секунду. Его можно загрузить через несколько секунд после загрузки страницы или по первому движению мыши и прокрутке.
- Подключать скрипты с
deferилиasync, чтобы они не блокировали отрисовку. - Заменить тяжёлые встраивания на заглушки. Вместо видеоплеера показывать картинку-превью и загружать плеер по клику. То же с картами.
CSS и шрифты
Стили блокируют отрисовку: пока браузер не скачал CSS, он не покажет страницу. Если на сайт подключено пять файлов стилей от разных плагинов, общим весом 400 КБ, из которых используется 10 %, первый экран будет ждать их все.
Помогает:
- собрать стили в один-два файла и убрать неиспользуемые правила;
- встроить критические стили первого экрана прямо в HTML, а остальные грузить следом.
Шрифты отдельная тема. Каждое начертание (обычный, жирный, курсив) это отдельный файл. Сайт с тремя гарнитурами по четыре начертания грузит двенадцать файлов шрифтов.
- Используйте формат WOFF2 и только нужные наборы символов: латиница и кириллица, без греческого и вьетнамского.
- Ограничьте число начертаний. Переменные шрифты (variable fonts) заменяют несколько файлов одним.
- Добавьте
font-display: swap, чтобы текст показывался сразу системным шрифтом, а не ждал загрузки. - Загружайте шрифты со своего домена, а не с внешнего сервиса: это экономит лишнее соединение.
@font-face {
font-family: "Onest";
src: url("/fonts/onest-cyrillic.woff2") format("woff2");
font-weight: 400 700;
font-display: swap;
}Кеширование и сжатие
Эти настройки делаются один раз на сервере и ускоряют повторные визиты и переходы между страницами.
- Сжатие. Текстовые файлы (HTML, CSS, JS, SVG) должны отдаваться сжатыми через gzip или brotli. Без сжатия они весят в 3-5 раз больше.
- Заголовки кеширования. Статика с версией в имени файла (
app.3f2a1c.js) кешируется в браузере на год. HTML кешируется коротко или не кешируется совсем, чтобы изменения сразу были видны. - HTTP/2 и HTTP/3. Позволяют грузить много файлов параллельно по одному соединению. На современных серверах включаются одной строкой.
- CDN. Для сайтов с аудиторией по всей России отдача статики с ближайшего узла сокращает задержку.
Пример настройки nginx для статики:
gzip on;
gzip_types text/css application/javascript image/svg+xml application/json;
location ~* \.(js|css|woff2|webp|avif|png|jpg|svg)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}Что даёт эффект, а что почти нет
| Действие | Эффект | Сложность |
|---|---|---|
| Сжать и перевести изображения в WebP | высокий | низкая |
| Убрать лишние сторонние виджеты | высокий | низкая |
| Включить кеш страниц и обновить PHP | высокий при медленном TTFB | средняя |
| Отложить загрузку чатов и видео | высокий для INP | средняя |
| Настроить шрифты | средний | низкая |
| Сжатие и заголовки кеширования | средний | низкая |
| Перейти на статическую генерацию | очень высокий | высокая, обычно при редизайне |
| Минифицировать HTML | низкий | низкая |
| Добиваться 100 баллов вместо 90 | почти нулевой для посетителей | высокая |
Когда проще пересобрать сайт
Бывает, что сайт на конструкторе или старой CMS упирается в потолок: 30-40 баллов в мобильном PageSpeed, а каждая оптимизация даёт +3 балла и ломает что-то ещё. Тема с десятью слайдерами, двадцать плагинов, которые нельзя отключить, потому что непонятно, что от них зависит.
В такой ситуации дешевле не латать, а сделать редизайн на технологии, которая быстрая изначально. Мы делаем сайты на Astro со статической генерацией: страницы собираются заранее, JavaScript грузится только там, где он реально нужен, и сайты стабильно получают 90+ в PageSpeed Insights без отдельной оптимизации.
Частые вопросы
Влияет ли скорость сайта на позиции в Яндексе?
Напрямую скорость входит в число многих факторов и сама по себе в топ не выведет. Но медленный сайт теряет посетителей: часть уходит, не дождавшись загрузки, особенно с мобильного интернета. Растут отказы, ухудшаются поведенческие факторы, а они для Яндекса значат много. И в рекламе медленная страница повышает стоимость заявки.
Сколько баллов в PageSpeed Insights достаточно?
Ориентируйтесь не на баллы, а на Core Web Vitals: LCP до 2,5 секунды, INP до 200 мс, CLS до 0,1. Если они в зелёной зоне, разница между 85 и 100 баллами для посетителей незаметна.
Можно ли ускорить сайт на Tilda?
Частично. Можно сжать изображения, убрать лишние блоки с анимацией, отказаться от тяжёлых виджетов. Но на серверную часть и базовый код платформы вы не влияете, поэтому выше определённого уровня поднять скорость не получится.
Сколько времени занимает ускорение сайта?
Базовая оптимизация (картинки, скрипты, шрифты, кеш) обычно занимает от нескольких дней до двух недель, в зависимости от CMS и числа шаблонов. Пересборка на другой технологии это уже проект на несколько недель.
Если сайт тормозит и непонятно почему, мы проведём замеры и сделаем ускорение сайта с отчётом «до и после» по Core Web Vitals, а дальше можем следить за скоростью в рамках техподдержки.