Если вы читаете эту статью, скорее всего, ситуация одна из двух. Либо сайт, который раньше открывался нормально, вдруг стал «тормозить» — и вы не понимаете, что изменилось. Либо он был медленным всегда, вы к этому привыкли, но конкуренты почему-то обгоняют вас в поиске, а заявок стабильно меньше, чем хотелось бы.
В обоих случаях причина, как правило, не одна. Медленная загрузка — это почти всегда сумма нескольких факторов, которые накладываются друг на друга: чуть слабый хостинг плюс тяжёлые фотографии плюс десяток виджетов от разных сервисов. По отдельности каждый фактор может казаться мелочью. Вместе они превращаются в 6-8 секунд загрузки, за которые половина посетителей успевает закрыть вкладку.
Дальше — пошаговый разбор всех причин, от самых частых до редких, с объяснением, как их проверить и что с ними делать. Статья написана как диагностический чек-лист: вы можете идти по пунктам последовательно и вычёркивать то, что не относится к вашему случаю.
Почему скорость — это не просто удобство
Есть соблазн отнести скорость загрузки к категории «было бы неплохо, но не критично». Это ошибка, и вот почему.
Скорость напрямую влияет на то, останется ли посетитель на сайте. Исследования поведения пользователей стабильно показывают: с ростом времени загрузки страницы с 1 до 3 секунд вероятность того, что человек уйдёт, не дождавшись, вырастает на десятки процентов. При загрузке дольше 5 секунд эта вероятность становится доминирующей. То есть медленный сайт — это не просто неприятный опыт, это прямая потеря трафика, за который вы, возможно, уже заплатили — через рекламу, SEO-продвижение или контекст.
Скорость влияет на конверсию. Даже если посетитель дождался загрузки, задержка в 1-2 секунды на каждом последующем шаге — открытии карточки товара, переходе в форму заявки, отправке формы — снижает вероятность того, что он доведёт действие до конца. В e-commerce разница между сайтом, который открывается за 2 секунды, и сайтом, который открывается за 5, может составлять десятки процентов конверсии в покупку. Для сайта услуг разница будет измеряться в количестве оставленных заявок.
Скорость — это официальный фактор ранжирования в поисковых системах. И Google, и Яндекс годами прямо говорят: скорость загрузки, и в частности показатели Core Web Vitals (LCP, INP, CLS), учитываются при ранжировании. Это не значит, что быстрый сайт автоматически окажется в топе — контент и ссылочная масса всё ещё важнее. Но при прочих равных, среди сайтов с похожим контентом, поисковик отдаст предпочтение более быстрому. А на мобильных устройствах, где скорость сети и так ограничена, эффект медленной загрузки на позиции ощущается ещё сильнее.
Скорость влияет на восприятие бренда. Здесь эффект менее измеримый, но не менее реальный. Медленный, «подвисающий» сайт подсознательно считывается как признак несерьёзной или устаревшей компании — даже если сам продукт или услуга безупречны. Это особенно ощутимо в B2B и в сферах, где доверие формируется на первых секундах контакта с брендом.
Итого: скорость сайта — это не техническая деталь для «айтишников», а бизнес-метрика, которая напрямую конвертируется в деньги. Именно поэтому имеет смысл разобраться, откуда берётся торможение, а не просто смириться с ним.
Причина 1: слабый или перегруженный хостинг
Это фундамент. Если фундамент слабый, любая оптимизация сверху даёт ограниченный эффект.
Что это значит на практике. Хостинг — это сервер, на котором физически лежат файлы вашего сайта и который обрабатывает каждый запрос посетителя. У дешёвого shared-хостинга (когда сотни сайтов делят один физический сервер) есть жёсткий потолок по ресурсам: процессору, оперативной памяти, количеству одновременных подключений. Пока у вас 10-20 посетителей в день, это может не ощущаться. Но стоит трафику вырасти — например, после успешной рекламной кампании или сезонного всплеска спроса — и сервер начинает захлёбываться: время ответа растёт, страницы отдаются с задержкой в несколько секунд, а иногда сайт вовсе «падает» под нагрузкой.
Есть и другой сценарий: хостинг сам по себе не перегружен, но настроен так, что не использует ресурсы эффективно — устаревшая версия PHP, отсутствие HTTP/2 или HTTP/3, слабый процессор, дешёвые (медленные) диски вместо SSD/NVMe.
Как это проявляется. Главный признак — так называемый TTFB (Time to First Byte), время до получения первого байта ответа от сервера. Если TTFB выше 600-800 мс — это тревожный сигнал именно про хостинг, а не про фронтенд сайта. Второй признак — нестабильность: сайт то грузится нормально, то «тупит», особенно в определённые часы (пиковая нагрузка) или сразу после рекламных рассылок и публикаций.
Что с этим делать. Если сайт стабильно медленный именно на уровне ответа сервера — вопрос решается либо переходом на более мощный тариф у того же провайдера, либо сменой хостинга на более качественный (желательно с NVMe-дисками, актуальной версией PHP, поддержкой HTTP/2). Для проектов с растущим трафиком имеет смысл рассмотреть VPS вместо shared-хостинга — там ресурсы не делятся с чужими сайтами.
Причина 2: неоптимизированные изображения (самая частая причина на практике)
Если бы нужно было назвать одну причину, которая встречается чаще всего при аудите реальных сайтов — это она. По опыту, на неё приходится значительная доля всех случаев медленной загрузки, особенно у сайтов, которые владелец наполняет самостоятельно.
Что происходит. Человек фотографирует товар на телефон или скачивает картинку из интернета, загружает её на сайт «как есть» — и получает файл на 4-8 мегабайт вместо оптимальных 100-300 килобайт. Один такой файл сам по себе не критичен. Но на типичной странице интернет-магазина или каталога услуг таких изображений может быть 15-30 штук: карточки товаров, баннеры, иконки, фотографии в разделе «о компании». В сумме страница может весить 10-15 мегабайт вместо разумных 1-2.
Отдельная проблема — формат. JPEG и PNG, при всей своей универсальности, значительно проигрывают по сжатию современным форматам WebP и AVIF. Один и тот же визуальный результат в WebP может весить в 2-3 раза меньше, чем в JPEG.
Третья частая ошибка — отсутствие адаптивных размеров. Если на сайте изображение размером 3000×2000 пикселей отображается в блоке 400×300, браузер всё равно скачивает полный файл, а потом сжимает его на лету средствами CSS. Пользователь платит трафиком и временем за пиксели, которые он физически не видит.
Как это проявляется. В PageSpeed Insights это будет отражено в рекомендациях «Properly size images», «Serve images in next-gen formats», «Efficiently encode images» — практически всегда с указанием конкретной потенциальной экономии в килобайтах или секундах.
Что с этим делать. Три направления работы, которые обычно дают вместе основной эффект:
- Сжатие всех изображений перед загрузкой (инструменты вроде TinyPNG, Squoosh, или автоматическая оптимизация на уровне CMS).
- Перевод изображений в WebP или AVIF с фолбэком на JPEG для старых браузеров.
- Настройка «ленивой» загрузки (lazy loading), при которой изображения ниже первого экрана подгружаются только тогда, когда пользователь до них доскроллил, а не все разом при открытии страницы.
Хорошая новость: это одна из немногих причин, которую владелец сайта во многих случаях может частично исправить сам — если использует CMS с встроенным сжатием изображений или готов вручную прогонять новые фото через сервис оптимизации перед загрузкой.
Причина 3: слишком много сторонних скриптов
Виджет онлайн-чата, счётчик Яндекс.Метрики, пиксель ВКонтакте, пиксель для ретаргетинга, виджет отзывов, всплывающая форма подписки, чат-бот, виджет обратного звонка, скрипт A/B-тестирования — по отдельности каждый из них решает конкретную бизнес-задачу. Проблема в том, что их количество на реальных сайтах имеет тенденцию расти со временем и никогда не сокращаться: кто-то один раз подключил виджет «на попробовать» два года назад, и с тех пор он просто висит на сайте, забытый.
Почему это тормозит сайт. Каждый такой скрипт — это отдельный запрос к стороннему серверу, который браузер должен выполнить, часто ещё до того, как начнёт отрисовывать саму страницу. Некоторые из этих скриптов блокируют рендеринг (browser не может продолжить отображать страницу, пока не выполнит скрипт). Некоторые скачивают свои собственные дополнительные файлы — шрифты, стили, изображения. А если сторонний сервер в момент загрузки страницы отвечает медленно (что вне вашего контроля), это напрямую замедляет весь сайт, даже если ваш собственный код и хостинг работают идеально.
Отдельная проблема — виджеты, которые выполняют собственный трекинг: они не просто показывают кнопку чата, а параллельно собирают данные о поведении пользователя, что добавляет ещё один слой фоновой активности.
Как это проявляется. В PageSpeed Insights это видно по разделу «Third-party usage» и по количеству блокирующих ресурсов (render-blocking resources). Часто именно сторонние скрипты — причина того, что сайт визуально «дёргается» уже после того, как основной контент загрузился: сначала страница выглядит готовой, а через секунду-две сверху выскакивает баннер подписки или сдвигается верстка из-за подгрузившегося виджета.
Что с этим делать. Провести ревизию: выписать все подключённые сторонние скрипты и честно ответить на вопрос — а нужен ли каждый из них прямо сейчас. Часто оказывается, что треть из них не используется вовсе. Для оставшихся — настроить асинхронную или отложенную загрузку (async/defer), чтобы они не блокировали отрисовку основного контента, и по возможности загружать их только после взаимодействия пользователя со страницей, а не сразу.
Причина 4: тяжёлый, неоптимизированный код на конструкторах вроде Tilda/WordPress с плагинами
Это причина, о которую разбивается больше всего надежд, потому что она структурная — её нельзя «подкрутить» одной настройкой.
Как это работает. Конструкторы сайтов (Tilda, Wix и подобные) и CMS с большим количеством плагинов (типичный WordPress-сайт с 20-30 установленными плагинами) устроены так, чтобы быть универсальными — подходить максимально широкому кругу задач без написания кода. Плата за эту универсальность — избыточность. Конструктор генерирует HTML и CSS, рассчитанные на любой возможный сценарий использования блока, а не на ваш конкретный случай, поэтому в код попадает много «лишнего» — неиспользуемых стилей, скриптов, обвязки. Каждый плагин WordPress добавляет собственные CSS- и JS-файлы, часто дублирующие библиотеки, уже используемые другими плагинами (классический пример — сайт, на котором библиотека jQuery загружена трижды разными плагинами независимо друг от друга).
В результате даже простая одностраничная визитка на тяжёлом конструкторе или перегруженном WordPress может отдавать несколько мегабайт HTML, CSS и JS ещё до единого изображения — притом что реальный, написанный вручную код для той же задачи занял бы в разы меньше.
Почему это сложнее других причин. Изображения можно сжать, скрипты — почистить, хостинг — усилить. А архитектуру конструктора или количество активных плагинов на CMS изменить без переделки самого сайта или серьёзной технической работы обычно нельзя — это заложено в саму платформу.
Как это проявляется. В PageSpeed Insights — большой объём «Unused CSS» и «Unused JavaScript», низкая оценка по «Reduce initial server response time» и «Minimize main-thread work», особенно на конструкторах. Субъективно — сайт может выглядеть простым и лёгким визуально, но при этом «весить» и загружаться неожиданно долго для своей кажущейся простоты.
Что с этим делать. Частичные меры — отключение неиспользуемых блоков и плагинов, минификация кода там, где это возможно средствами платформы — дают ограниченный эффект, потому что не убирают саму избыточную архитектуру. Радикальное, но по-настоящему работающее решение в таких случаях — переход на чистый, написанный вручную код без визуального конструктора, где каждая строчка решает конкретную задачу сайта, а не унифицированный сценарий «на все случаи жизни». Мы подробно разбирали разницу в подходе к коду и её влияние на скорость и SEO в статье «Чистый код без конструкторов» — рекомендуем прочитать, если ваш сайт сделан на Tilda или тяжёлом WordPress и это первый раз, когда вы всерьёз задумались о переезде.
Причина 5: отсутствие кэширования
Кэширование — одна из тех вещей, которые незаметны, пока работают правильно, и превращаются в ощутимую проблему, когда настроены неверно или вовсе отсутствуют.
Что это такое простыми словами. Когда браузер впервые открывает сайт, он скачивает все файлы — HTML, CSS, картинки, шрифты. Кэширование — это набор правил, которые говорят браузеру: «этот файл не изменится в ближайшие дни или недели, сохрани его у себя и в следующий раз не скачивай заново». Без правильных настроек кэширования браузер при каждом визите скачивает всё заново, даже если пользователь заходил на сайт пять минут назад.
Есть и второй уровень — серверное кэширование. Многие сайты (особенно на CMS вроде WordPress) при каждом запросе страницы заново обращаются к базе данных, собирают контент, формируют HTML — и только потом отдают его пользователю. Это занимает время процессора на сервере при каждом визите. Кэширование на стороне сервера позволяет один раз собрать готовую страницу и отдавать её всем следующим посетителям мгновенно, без повторных обращений к базе.
Как это проявляется. Повторные визиты на сайт открываются почти так же медленно, как первый. В PageSpeed Insights — рекомендация «Serve static assets with an efficient cache policy» с указанием конкретных файлов, у которых не настроен или настроен слишком короткий срок кэширования.
Что с этим делать. На уровне сервера — настройка заголовков кэширования (Cache-Control, Expires) для статических файлов: изображений, шрифтов, CSS и JS, которые не меняются часто. На уровне CMS — установка или настройка плагина/модуля кэширования, который создаёт готовые HTML-версии страниц и отдаёт их без повторного обращения к базе данных. Дополнительно — подключение CDN (сети доставки контента), которая кэширует статические файлы сайта на серверах по всему миру, ближе к пользователю.
Причина 6: медленная база данных на сайтах с большим каталогом
Эта причина актуальна не для всех, но крайне остро ощущается там, где применима — прежде всего для интернет-магазинов с большим ассортиментом, каталогов недвижимости, агрегаторов и любых сайтов, где контент не статичен, а формируется динамически из базы данных при каждом запросе.
Что происходит. Чем больше товаров, категорий, фильтров и связанных записей в базе данных, тем сложнее и «тяжелее» становятся запросы, которые сайт должен выполнить, чтобы собрать страницу. Особенно это касается страниц с фильтрацией и сортировкой (например, «показать товары в категории X, в наличии, по цене от Y до Z, отсортировать по популярности») — такие запросы при плохо спроектированной структуре базы данных или отсутствии индексов могут выполняться секундами вместо миллисекунд.
Отдельная проблема роста: сайт, который отлично работал с каталогом в 200 товаров, может начать заметно тормозить при росте каталога до 5 000-10 000 позиций, если база данных изначально не была спроектирована с расчётом на масштабирование.
Как это проявляется. Главный признак — избирательное торможение: главная страница и статичные разделы (типа «О компании») открываются нормально, а страницы каталога, поиска и фильтрации — заметно медленнее. Высокий TTFB именно на этих страницах, при нормальном TTFB на статичных.
Что с этим делать. Это одна из наиболее технически сложных причин для диагностики и исправления — требует работы на уровне базы данных: добавление индексов на часто используемые в запросах поля, оптимизация самих запросов, а иногда — кэширование результатов часто запрашиваемых выборок (например, кэширование результатов фильтрации на несколько минут вместо пересчёта при каждом визите). Для очень крупных каталогов может потребоваться пересмотр архитектуры хранения данных целиком. Это задача исключительно для разработчика с доступом к базе данных сайта — самостоятельно такие проблемы не решаются.
Причина 7: географическая удалённость сервера от аудитории
Причина, о которой редко задумываются, но которая может ощутимо влиять на скорость, особенно если бизнес работает на аудиторию из другого региона, чем расположен сервер.
Физика вопроса. Данные между сервером и браузером пользователя передаются не мгновенно — скорость ограничена расстоянием и качеством сетевой инфраструктуры между двумя точками. Если сервер физически находится, например, в Москве, а значительная часть аудитории сайта — в Сибири, на Дальнем Востоке или тем более за рубежом, каждый запрос будет добавлять десятки, а иногда сотни миллисекунд задержки только на передачу данных туда и обратно (это называется network latency). На статичной странице с одним запросом это малозаметно. Но современные страницы делают десятки отдельных запросов (за HTML, за каждым файлом CSS и JS, за каждым изображением, за каждым сторонним скриптом) — и задержка умножается на их количество.
Как это проявляется. Тест скорости, запущенный из разных географических точек, покажет заметно разные результаты — быстро там, где сервер физически близко, и медленнее там, где далеко. Если основная часть трафика приходится на удалённый от сервера регион, это будет системно занижать общие метрики скорости и восприятие сайта как медленного именно у этой аудитории.
Что с этим делать. Радикальный вариант — перенос сайта на хостинг, физически расположенный ближе к основной аудитории. Более гибкий и часто более практичный вариант — подключение CDN: сеть серверов-копий по разным регионам, которая отдаёт статический контент (изображения, стили, шрифты) с ближайшей к пользователю точки, даже если основной сервер остаётся на прежнем месте. Для аудитории в пределах одной страны эта причина обычно не критична, но для сайтов с международной аудиторией или очень большой территорией охвата — стоит проверить в первую очередь.
Как проверить скорость самостоятельно: PageSpeed Insights пошагово
Прежде чем что-то чинить, нужно точно понять, что именно тормозит именно ваш сайт — а не гадать по общему списку причин выше. Бесплатный и достаточно точный способ сделать это самостоятельно — сервис Google PageSpeed Insights.
Шаг 1. Откройте pagespeed.web.dev и вставьте в поле полный адрес страницы, которую хотите проверить — желательно не только главную, но и одну-две «рабочие» страницы: карточку товара, страницу услуги, форму заявки. Главная страница часто оптимизирована лучше остальных просто потому, что на неё смотрят чаще — а проблема может прятаться глубже.
Шаг 2. Дождитесь результата отдельно для мобильной и десктопной версии — сервис показывает их как две вкладки. Проверяйте обе: мобильная версия почти всегда медленнее, и именно она чаще всего важнее, поскольку значительная часть трафика у большинства сайтов сегодня приходит с телефонов.
Шаг 3. Обратите внимание на общую оценку (число от 0 до 100), но не останавливайтесь на ней — это агрегированный показатель, который сам по себе мало что объясняет. Спуститесь ниже, к разделу с конкретными метриками: там будут показатели LCP (Largest Contentful Paint — время отображения основного контента), CLS (Cumulative Layout Shift — насколько страница «прыгает» во время загрузки), INP (Interaction to Next Paint — насколько быстро страница реагирует на действия пользователя) и TTFB.
Шаг 4. Прокрутите ещё ниже до раздела «Diagnostics» и «Opportunities» (в русской версии — «Возможности» и «Диагностика»). Здесь сервис перечисляет конкретные найденные проблемы с указанием потенциальной экономии времени в секундах для каждой: неоптимизированные изображения, неиспользуемый CSS/JS, отсутствие кэширования, блокирующие рендеринг ресурсы и так далее. Именно этот раздел — практическая основа для сопоставления с причинами, разобранными выше в статье.
Шаг 5. Если есть техническая возможность, дополнительно проверьте сайт через GTmetrix или WebPageTest — они показывают похожую информацию, но с другой визуализацией и иногда с дополнительными деталями (например, водопадную диаграмму загрузки всех файлов страницы, где хорошо видно, какой именно ресурс «съедает» больше всего времени).
Как интерпретировать результат: на что смотреть в первую очередь, а что не критично
Отчёт PageSpeed Insights может выглядеть пугающе — десятки предупреждений, красные и жёлтые отметки почти везде. Не все из них одинаково важны.
Смотрите в первую очередь на:
- LCP выше 2,5 секунд. Это ключевая метрика восприятия скорости — время, за которое пользователь видит основной контент страницы. Если она сильно превышена, это системная проблема, а не мелкий недочёт.
- TTFB выше 600-800 мс. Почти всегда указывает на проблему с хостингом или сервером — фундаментальную причину, без решения которой остальная оптимизация даст ограниченный эффект.
- Большой процент экономии в разделе «Serve images in next-gen formats» и «Properly size images». Если сервис обещает экономию в несколько секунд только за счёт картинок — это, скорее всего, ваша основная проблема, и её проще всего решить.
- CLS выше 0,25 (заметные «прыжки» вёрстки) — сильно раздражает пользователей и напрямую портит впечатление от сайта, даже если остальные метрики в порядке.
Что не критично и не стоит тратить время на идеальное исправление:
- Оценка 85-95 из 100 вместо 100 — это уже хороший результат, охота за последними баллами часто не оправдывает трудозатрат.
- Мелкие предупреждения про отдельные некритичные сторонние библиотеки, если их суммарный вклад в время загрузки — доли секунды.
- Различия в оценке между лабораторными данными (Lab Data, результат одного теста) и полевыми данными (Field Data, реальный опыт пользователей за последние 28 дней) — если полевые данные хорошие, а лабораторный тест показал что-то похуже, ориентироваться стоит на полевые данные, они точнее отражают реальность.
Общее правило: если один-два раздела показывают экономию в разы больше, чем остальные — начинайте именно с них. Универсальной последовательности «сначала это, потом то» не существует, всё зависит от того, что именно оказалось узким местом на конкретном сайте.
Какая причина к чему относится и насколько сложно её исправить
Ниже — сводная таблица по всем семи причинам, разобранным в статье. Она поможет быстро сориентироваться: что можно попробовать закрыть своими силами прямо сейчас, а для чего сразу стоит привлекать разработчика.
| Причина | Насколько легко исправить | Кто может исправить |
|---|---|---|
| Слабый/перегруженный хостинг | Средне — требует смены тарифа или провайдера, но не требует программирования | Сам (смена тарифа) или разработчик (перенос сайта) |
| Неоптимизированные изображения | Легко — самая быстрая победа из всех | Сам, при наличии инструментов сжатия |
| Слишком много сторонних скриптов | Легко-средне — ревизия и отключение лишнего доступны без кода | Сам (отключение) или разработчик (асинхронная загрузка) |
| Тяжёлый код конструктора/CMS с плагинами | Сложно — требует переработки или переезда с платформы | Разработчик |
| Отсутствие кэширования | Средне — часто решается настройкой плагина или сервера | Разработчик, иногда сам через готовый плагин |
| Медленная база данных (большой каталог) | Сложно — требует работы с архитектурой данных | Только разработчик |
| Удалённость сервера от аудитории | Средне — решается подключением CDN или переносом сервера | Разработчик |
Если смотреть на таблицу целиком, видна логика: причины, которые чаще всего решает сам владелец сайта — это изображения и лишние скрипты. Всё, что связано с сервером, базой данных и архитектурой кода — зона разработчика.
С чего начать, если вы не технический специалист
Если после прочтения этой статьи и проверки через PageSpeed Insights вы видите список из пяти проблем сразу и не понимаете, за что хвататься первым — это нормальная ситуация, и решать её точечно, наугад, не самый эффективный путь. Часто одна структурная причина (тяжёлый конструктор, слабый хостинг) тянет за собой половину остальных симптомов, и без диагностики со стороны легко потратить время на то, что даст минимальный эффект, пока корневая проблема останется нетронутой.
Мы в G-land делаем бесплатную проверку скорости сайта: смотрим реальные метрики, находим конкретные причины именно вашего торможения и говорим прямо, что из этого можно закрыть быстро и дёшево, а что требует более серьёзного вмешательства — без продажи ненужных услуг. Напишите нам, чтобы получить конкретный разбор своего сайта, а не общий чек-лист.