Сайт медленно загружается: как найти причину до заказа доработки

Сайт «висит» по 5–8 секунд, реклама дорожает, а клиенты уходят, не дождавшись загрузки формы заявки. Первая реакция большинства владельцев — заказать «оптимизацию» и надеяться, что подрядчик сам разберётся. Это рабочий вариант, но платить вслепую не обязательно: за 20–30 минут можно самостоятельно понять, где именно теряется время, и прийти к разговору о ускорении сайта уже с конкретным списком проблем, а не с общей жалобой «медленно грузится». Ниже — пошаговая диагностика, которую можно провести без доступа к коду и без специальных знаний.

Шаг 1. Измерьте скорость правильно, а не «на глаз»

Субъективное ощущение «долго» бесполезно для диагностики — нужны цифры и конкретные метрики. Откройте бесплатный сервис PageSpeed Insights от Google (pagespeed.web.dev), вставьте адрес сайта и дождитесь отчёта отдельно для мобильной и десктопной версии. Смотрите не только на итоговую оценку от 0 до 100, но и на три метрики Core Web Vitals:

• LCP (Largest Contentful Paint) — время, за которое отрисовывается самый крупный видимый элемент. Норма — до 2,5 секунды.
• INP (Interaction to Next Paint) — задержка отклика на клик или тап. Норма — до 200 мс.
• CLS (Cumulative Layout Shift) — насколько «прыгает» вёрстка при загрузке. Норма — до 0,1.

Проверьте сайт и на GTmetrix или WebPageTest — они показывают водопад загрузки (waterfall), то есть буквально каждый файл и время его загрузки. Это главный инструмент диагностики, к нему вы будете возвращаться на каждом следующем шаге. Важная деталь: мобильная оценка почти всегда ниже десктопной на 20–40 пунктов — это нормально, но именно она определяет, как сайт видит большинство посетителей и как его ранжирует поиск.

Шаг 2. Отделите хостинг от самого сайта

Прежде чем оптимизировать код и картинки, нужно понять, не тормозит ли сервер сам по себе — тогда любая доработка сайта результата не даст. В отчёте PageSpeed или GTmetrix найдите показатель TTFB (Time to First Byte) — время до первого ответа сервера, ещё до загрузки страницы. Если TTFB выше 600–800 мс — это почти всегда хостинг: слабый тариф, «соседи» на общем сервере, перегруженная база данных.

Быстрая проверка: откройте сайт через сервис вроде bitcatcha.com или dotcom-tools.com — они замеряют время отклика сервера из разных точек мира. Если задержка большая даже из ближайшего к вам региона — дело в хостинге, и никакая оптимизация картинок это не исправит. Стоит также посмотреть, на каком тарифе сайт сейчас размещён: часто сайт «вырос» — трафик, каталог, база — а тариф хостинга остался стартовым.

Шаг 3. Проверьте вес и формат изображений

Это самая частая и самая дешёвая в исправлении причина медленной загрузки. В отчёте GTmetrix откройте вкладку с водопадом и отсортируйте файлы по размеру — если картинки весят по 2–5 МБ каждая, а на странице их десяток, именно на них уходит основное время. Признаки проблемы:

• изображения загружены прямо с телефона или из фотобанка без сжатия;
• формат JPEG или PNG вместо современного WebP или AVIF — разница в весе может быть двукратной при том же визуальном качестве;
• картинки вставлены в исходном размере 4000×3000 px, хотя на экране показываются блоком 400×300 px — браузер всё равно скачивает полный файл;
• отсутствует «ленивая загрузка» (lazy load) — сайт грузит сразу все изображения страницы, даже те, что ниже экрана и пользователь их пока не видит.

Проверить вес конкретной картинки просто: кликните по ней правой кнопкой в браузере → «Открыть изображение в новой вкладке» → посмотрите размер файла в свойствах. Если он больше 200–300 КБ для обычной иллюстрации — это кандидат на сжатие.

Шаг 4. Найдите лишние скрипты и виджеты

Онлайн-консультанты, виджеты обратного звонка, счётчики аналитики, карты, сторонние шрифты — каждый из них подгружает свой JavaScript с внешнего сервера, и браузер ждёт ответа от каждого сервиса. В том же водопаде GTmetrix обратите внимание на домены, отличные от вашего собственного: если запросов к сторонним сервисам больше 15–20, а некоторые «висят» по 1–2 секунды — вероятная причина замедления найдена.

Особенно часто это встречается на сайтах, собранных на WordPress или другом конструкторе с большим числом плагинов: каждый плагин может подключать собственные CSS- и JS-файлы, даже если реально используется на одной странице из ста. Быстрая проверка без доступа к коду — открыть админку и посмотреть список активных плагинов: если их больше 15–20, а часть не используется месяцами, это прямой кандидат на чистку.

Шаг 5. Проверьте, не «тормозит» ли база данных

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

Самостоятельно продиагностировать SQL-запросы без доступа к коду сложно, но косвенный признак виден и без этого: если разница в скорости между главной страницей и страницей каталога больше 2 крат — это сигнал смотреть в сторону базы данных и её оптимизации, а не в сторону общего «ускорения сайта».

Шаг 6. Что чинится за 15 минут, а что требует подрядчика

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

• Своими силами, если есть доступ к админке: удалить неиспользуемые плагины, сжать 5–10 самых тяжёлых картинок через бесплатный онлайн-конвертер, отключить лишние виджеты на страницах, где они не нужны.
• Нужен подрядчик, но задача быстрая (1–3 дня): массовое сжатие и конвертация всех изображений сайта в WebP, настройка кэширования страниц и браузера, минификация CSS и JavaScript, отложенная загрузка шрифтов и сторонних скриптов.
• Комплексная работа (от 3–7 дней): оптимизация запросов и чистка базы данных, настройка серверного кэша, подключение CDN, перенос на более быстрый хостинг.

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

Практический вывод

Прежде чем заказывать оптимизацию, потратьте 20–30 минут и получите три конкретные цифры: оценку PageSpeed отдельно для мобильной версии, значение TTFB и список из 5 самых тяжёлых файлов в водопаде GTmetrix. С этими данными разговор с подрядчиком меняется — вы не описываете ощущение «сайт тормозит», а показываете, что именно измерено и где узкое место: сервер, картинки, скрипты или база данных. Это сокращает и стоимость работ (не приходится платить за диагностику, которую можно сделать бесплатно), и риск того, что вам продадут пакет услуг, который не решает вашу конкретную проблему. Если после самостоятельной проверки картина ясна и нужен именно технический аудит с замерами «до» и «после» — на этом этапе уже есть смысл обращаться к специалистам.