Почему сайт грузится медленно и как найти виновника за 15 минут

«Сайт тормозит» — самая частая жалоба и самая бесполезная формулировка. Тормозить может сервер, который думает две секунды перед тем, как отдать первый байт. Могут картинки, которые весят как небольшой фильм. Может чат-виджет, который тянет полтора мегабайта скриптов ради кнопки в углу. Это три разные болезни с тремя разными лечениями, и лечить их наугад — верный способ потратить бюджет впустую.

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

Сначала договоритесь, что значит «медленно»

«Быстро» и «медленно» — не про общее ощущение, а про несколько разных моментов времени, которые полезно различать. Иначе разговор с подрядчиком превращается в спор о вкусах.

Между третьей и четвёртой строкой прячется самая раздражающая поломка: страница выглядит готовой, человек жмёт кнопку, а она молчит ещё секунду. Формально сайт «загрузился», по ощущениям — сломан.

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

Шаг 1. Измерьте время ответа сервера

Первый показатель называется TTFB — time to first byte, время до первого байта. Это пауза между тем, как браузер отправил запрос, и тем, как сервер начал отвечать. Всё, что происходит дальше — загрузка картинок, отрисовка — идёт уже поверх этой паузы.

Измерить проще всего командой в терминале — она есть и в macOS, и в Linux, и в Windows через встроенный WSL:

• Откройте терминал и выполните: curl -o /dev/null -s -w "%{time_starttransfer}\n" https://ваш-сайт.ru
• Повторите пять раз подряд: первый запрос почти всегда медленнее остальных, и судить по нему нельзя.
• Возьмите среднее из последних четырёх.

Если curl под рукой нет, тот же показатель виден в браузере: F12, вкладка «Сеть», обновление страницы, клик по первой строке списка (это сам документ), раздел «Тайминги». Строка «Ожидание ответа» или Waiting (TTFB) — то же число.

Что делать дальше, зависит от того, откуда берётся задержка. Причин на практике немного.

Последняя строка недооценена. Цепочка http → https → www → конечный адрес — это три обращения к серверу до начала загрузки, каждое со своим TTFB. На мобильной сети легко превращается в лишнюю секунду. Проверяется командой `curl -IL адрес`: в выводе видно все перенаправления.

Шаг 2. Взвесьте страницу

Откройте сайт в браузере, нажмите F12, перейдите на вкладку «Сеть» (Network) и обновите страницу с очищенным кэшем — Ctrl+Shift+R или Cmd+Shift+R. Внизу панель покажет общий вес и число запросов.

Ориентир простой: страница тяжелее 3 МБ почти всегда содержит хотя бы одну картинку, которую забыли сжать. Отсортируйте список по размеру — виновник окажется в первых строчках.

1. 01Отсортируйте запросы по колонке «Размер» по убыванию.
2. 02Посмотрите на верхние пять. Если это изображения тяжелее 300 КБ — вы нашли, с чего начать.
3. 03Проверьте формат: JPEG и PNG сжимаются в WebP в среднем вдвое без видимой разницы.
4. 04Проверьте размеры: картинку 4000 пикселей шириной браузер всё равно ужмёт до ширины экрана, но скачает целиком.

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

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

• Видео на фоне первого экрана. Красивый приём, который на мобильном интернете стоит десятков мегабайт. Если фон обязателен, отдавайте телефонам статичный кадр.
• Шрифты в полном наборе. Один шрифт в четырёх начертаниях с кириллицей и латиницей — это несколько сотен килобайт, часто ради двух реально используемых начертаний.
• Иконочные шрифты целиком. Подключённый набор из тысячи иконок ради пяти штук в подвале. Отдельные SVG весят единицы килобайт.
• Библиотеки, оставшиеся от шаблона. Слайдер, галерея, анимации прокрутки — часто подключены, но не используются ни на одной странице.
• Несжатая передача. Если текстовые файлы приходят без сжатия, они весят втрое больше необходимого. В колонке размера браузер показывает и переданный объём, и исходный — если они равны, сжатие выключено.

Отдельно про шрифты. Пока файл шрифта грузится, браузер по умолчанию может ничего не рисовать — человек смотрит на пустое место там, где должен быть заголовок. Свойство `font-display: swap` заставляет сначала показать текст системным шрифтом, а потом заменить. Одна строка в стилях, а разница на медленной сети — секунда белого экрана.

Шаг 3. Отключите чужие скрипты

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

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

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

Чего не покажет замер из браузера

Все три шага выше вы делаете на своём устройстве и своём интернете. Это хорошая диагностика, но не картина того, что видят посетители. Два дополнения закрывают разрыв.

Первое — искусственное замедление. В панели «Сеть» есть список профилей сети: выберите медленный мобильный интернет и обновите страницу. Заодно в панели производительности можно замедлить процессор в четыре-шесть раз — это приближает картину к недорогому телефону.

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

Что часто советуют зря

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

• «Объедините все скрипты в один файл». Совет из эпохи старых протоколов. Сейчас несколько параллельных запросов обычно не хуже одного большого, а склеенный файл заставляет скачивать заново всё из-за правки одной строки.
• «Поставьте CDN, и станет быстро». CDN ускоряет раздачу статичных файлов посетителям из других регионов. Если все ваши клиенты в одном городе, а тормозит база данных, CDN не изменит ничего.
• «Смените CMS, эта медленная». Смена системы — проект на месяцы с риском потерять позиции в поиске. Почти всегда та же CMS ускоряется кэшем и чисткой плагинов в десятки раз дешевле.
• «Уберите анимации, они тормозят». Анимации редко бывают причиной. Проверить легко: отключите их и замерьте — если разница в пределах погрешности, дело не в них.
• «Главное — сжать картинки». Работает, когда картинки действительно составляют основной вес. При медленном сервере это правка ради правки.

Скорость на телефоне — отдельная история

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

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

Сколько это стоит в заявках

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

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

Осторожнее с выводами по одному числу. Отказы растут и от непонятного первого экрана, и от несовпадения с рекламным объявлением, и от неудобной формы. Скорость — одна из причин, а не единственная. Надёжнее сравнивать до и после: зафиксируйте отказы и число обращений за месяц, сделайте правки, подождите столько же. Про то, каким цифрам в аналитике вообще можно верить, есть отдельный разбор: почему данные аналитики врут.

Когда ускорять уже не нужно

Оптимизация скорости имеет дно, ниже которого дальнейшая работа перестаёт окупаться. Признаки, что вы его достигли: сервер отвечает быстрее 0,2 секунды, страница легче полутора мегабайт, на телефоне с мобильным интернетом содержимое появляется за пару секунд, чужих скриптов почти нет.

Дальше идут работы с быстро убывающей отдачей: критический CSS, тонкая настройка предзагрузки, разделение бандлов. Они требуют разработчика и дают выигрыш в десятые доли секунды. Если на этом этапе заявок всё ещё мало, причина почти наверняка не в скорости — стоит вернуться к тому, что написано на странице и как устроена форма. Куда направить силы дальше, разобрано в статье куда вложить бюджет на сайт.

Порядок действий, если времени мало

1. 01Измерьте TTFB. Больше 1,5 секунды — занимайтесь только сервером, остальное подождёт.
2. 02Найдите три самые тяжёлые картинки и пересохраните их в WebP с шириной не больше 1600 пикселей.
3. 03Пересчитайте счётчики и виджеты, удалите неиспользуемые.
4. 04Повторите замер и запишите результат — без записи через месяц не вспомнить, стало ли лучше.

Эти четыре пункта закрывают большинство случаев «сайт тормозит» на небольших сайтах. Всё, что сложнее — критический CSS, разделение бандлов, предзагрузка шрифтов — имеет смысл, когда база уже в порядке.

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