Почему сайт тормозит на телефоне и как проверить скорость загрузки сайта

Содержание

• Что значит «тормозит»: три цифры от Google
• Причина 1. Картинки, которых посетитель не видит
• Причина 2. Тяжёлые ролики
• Причина 3. Шрифт иконок на полмегабайта
• Причина 4. Страница, которая прыгает
• Причина 5. Метки в адресе обходят кэш
• Причина 6. Чужие скрипты
• Что дали правки
• Как проверить скорость загрузки сайта и не обмануться замером
• С чего начать самому за вечер

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

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

Что значит «тормозит»: три цифры от Google

«Медленно» у каждого своё, поэтому Google разложил его на три измеряемых показателя (Core Web Vitals):

• LCP - когда на экране появляется самый крупный блок страницы, чаще всего главное фото. Норма: до 2,5 секунды, больше 4 секунд - плохо.
• CLS - насколько страница «прыгает» при загрузке: вы тянетесь к кнопке, а она уезжает вниз. Норма: до 0,1, выше 0,25 - плохо.
• INP - как быстро страница откликается на нажатие. Норма: до 200 миллисекунд.

Оценивают по 75-му перцентилю, а не по среднему: в норму должны уложиться три посещения из четырёх. Телефон и компьютер считают отдельно. Владелец обычно открывает свой сайт на компьютере по хорошему интернету, а клиент заходит с телефона из машины или с объекта.

Вес страниц и время загрузки ниже сняты в эмуляции телефона на медленном 4G. Живой посетитель увидит цифры получше или похуже, но для сравнения «до и после» такой замер годится.

Причина 1. Картинки, которых посетитель не видит

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

Про отложенную загрузку на web.dev сказано так: картинки в блоке с display: none браузеры не качают, а картинки, спрятанные другими способами, например прозрачностью, качают (Browser-level image lazy-loading). Панель за краем экрана попала во вторую группу: спрятана для глаз, но не для сети.

После правки меню отдаёт уменьшенные копии фото, а картинки панели подгружаются, когда её открывают. Вес главной на телефоне до первой прокрутки упал с 2,7 до 1,0 МБ. На компьютере ничего не изменилось: там меню скрыто через display: none, и отложенная загрузка работала и раньше.

У той же проблемы есть вторая половина - очередь. На странице из каталога главное фото на телефоне грузилось почти 8 секунд: оно делило канал примерно с мегабайтом того, чего на экране ещё нет, - планировками, соседними слайдами, фонами нижних блоков. Их загрузку перенесли на после главного фото. Самой главной картинке Google советует обратное: ставить fetchpriority="high" и никогда не ставить отложенную загрузку (Optimize LCP). Высокий приоритет работает у одной-двух картинок. Раздайте его десяти, и он перестанет что-либо значить.

Что спросить у разработчика: «Какие картинки скачиваются на телефоне до того, как я прокручу страницу, и все ли они видны на экране?» Ответ видно во вкладке «Сеть» в инструментах разработчика браузера.

Причина 2. Тяжёлые ролики

35 роликов на сайте весили в сумме около 2 ГБ. Их пересохранили в 720p, вышло около 300 МБ, и к каждому добавили обложку. Теперь файл не загружается заранее: адрес подставляется при показе, а до нажатия человек видит обложку.

За это отвечает атрибут preload: значение none значит «заранее не загружать», metadata - загрузить только длительность и размеры (MDN: элемент video). Если видео на странице много и оно не главное, web.dev советует ставить none или metadata с обложкой, чтобы ролики не занимали соединения, нужные другим файлам (Fast playback with audio and video preload).

Что спросить: «Сколько весят ролики на странице и что скачивается, пока их никто не запустил? Есть ли у каждого обложка?»

Причина 3. Шрифт иконок на полмегабайта

Готовая тема сайта подключала полный набор иконок: файл стилей на 37 КБ, который задерживал отрисовку страницы, и шрифт на 490 КБ. На сайте использовалось 50 иконок из 5200. Из этих пятидесяти собрали свой набор: стили 2,5 КБ, шрифт 7 КБ.

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

Что спросить: «Какие шрифты, иконки и стили подключены целиком, хотя используется малая часть?»

Причина 4. Страница, которая прыгает

Сдвиг вёрстки - самая обидная проблема: сайт вроде бы загрузился, но текст уехал, и человек нажал не ту кнопку. Google называет типичные причины: картинки и видео без заданных размеров, веб-шрифт, который заметно отличается от запасного, и блоки, которые появляются выше уже видимого текста (Optimize CLS).

На сайте было два таких случая. В статьях блога боковая колонка стояла в коде раньше текста, а на узком экране её переносили вниз через стили. Браузер успевал нарисовать колонку над статьёй, потом приходил текст, и всё съезжало. CLS на телефоне был от 0,33 до 0,61, далеко за порогом «плохо». Статью поставили в коде первой, и сдвиг пропал совсем.

На главной и в карточках каталога файлы шрифтов и стилей встроили прямо в начало страницы и задали ширину одному из блоков. CLS главной упал с 0,23 до 0,02, карточек - с 0,16 до нуля.

Что спросить: «В каком порядке блоки лежат в коде страницы и у всех ли картинок заданы размеры?» Порядок в коде должен совпадать с порядком на телефоне.

Причина 5. Метки в адресе обходят кэш

Кэш нужен, чтобы сервер отдавал готовую страницу и не собирал её заново на каждый заход. На WordPress это делает плагин, например WP Super Cache. У таких плагинов есть особенность: адрес с параметрами после вопросительного знака считается другой страницей. В описании WP Super Cache прямо сказано, что метка utm_source мешает отдавать страницу из его быстрого кэша (WP Super Cache).

Допустим, реклама ведёт на адреса вида site.ru/page/?utm_source=.... Тогда каждый платный клик попадает на страницу, которую сервер собирает с нуля. На сайте из этой статьи это стоило 0,3-0,7 секунды сборки вместо 0,02 секунды из кэша. И доставалось именно тем посетителям, за которых заплатили.

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

Что спросить: «Страницы с рекламными метками отдаются из кэша или собираются заново? Как это проверить?»

Причина 6. Чужие скрипты

Счётчики, пиксели соцсетей, чаты, виджеты обратного звонка, запись поведения - у каждого свой код, и грузится он с чужого сервера. Google советует сначала спросить, нужен ли скрипт вообще, и удалить, если явной пользы нет, а остальные подключать так, чтобы они не задерживали отрисовку (Efficiently load third-party JavaScript).

Что сделала команда:

• Часть счётчиков и пиксели рекламных сетей стали грузиться после первого действия посетителя или через 5 секунд после открытия страницы, но не позже чем через 15.
• Компания отказалась от платного сервиса сквозной аналитики и выключила подмену номера в его кабинете. Но код сервиса остался на сайте: он грузился на каждой странице (около 50 КБ и четыре запроса) и у части посетителей подставлял в шапку старый номер. Его убрали отдельной правкой. Отключили сервис - проверьте, что с сайта ушёл и его код.
• Вебвизор Метрики, который записывает действия посетителей, по оценке теста добавлял около 0,9 секунды. Его оставили: инструмент нужен.

Мобильная оценка PageSpeed до всех правок была около 5 из 100, после - 92 в удачном прогоне. На том же коде выпадало и 80: разброс давал сторонний код.

Что спросить: «Какие скрипты на сайте чужие, зачем нужен каждый и когда он загружается? Есть ли среди них сервисы, которыми мы уже не пользуемся?»

Что дали правки

Карточку из каталога правили в два шага: сначала убрали лишнее из меню, потом переставили очередь загрузки. LCP упал примерно втрое, но 5,6 секунды всё ещё вдвое выше нормы, так что работа не закончена. На компьютере то же главное фото ускорилось всего с 2,5 до 2,1 секунды: основная проблема сидела в телефоне.

Как проверить скорость загрузки сайта и не обмануться замером

Любая цифра скорости зависит от того, как её сняли. На этом сайте встретились пять ловушек.

1. Один прогон. Один и тот же код дал 92 и 80. Google подтверждает: оценка может меняться от запуска к запуску даже без правок (About PageSpeed Insights). Делайте 2-3 прогона и записывайте разброс.
2. Первый запрос. Главная в автоматическом замере выходила медленной, 1,6-2,4 секунды. Дело было не в ней: самый первый запрос к сайту включает поиск адреса и установку защищённого соединения, это около 2 секунд, какую страницу ни открой первой. Из кэша та же главная отдавалась за 0,4-0,5 секунды. Поэтому в автоматическом замере сначала делают пробный запрос, а меряют следующий.
3. Кэш браузера. Замеряя вес страницы до прокрутки, открывайте каждую проверку в новой вкладке. Картинки из прошлых загрузок браузер берёт из памяти и в вес не считает.
4. Не тот телефон. Сжатое окно браузера ещё не телефон: сеть и процессор остаются компьютерными. Проверять нужно в режиме эмуляции устройства в инструментах разработчика, где задаются размер экрана, медленная сеть и замедленный процессор. Google для своего теста берёт телефон средней цены и мобильную сеть. Ваш новый смартфон на домашнем Wi-Fi покажет слишком хорошую картину.
5. Лаборатория вместо людей. Лабораторный тест - это один заход робота в одних условиях. У живых посетителей разные телефоны, сеть и путь по сайту. Google советует расставлять приоритеты по полевым данным, то есть по замерам реальных посетителей, а лабораторные оставлять для поиска причин (Lab and field data differences).

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

Реальных посетителей смотрите в Метрике: «Отчеты - Мониторинг - Время загрузки страниц» (справка Яндекс Метрики). Отчёт раскладывает загрузку на этапы: DNS, соединение, ответ сервера, загрузка HTML, отрисовка. По справке Метрики, скорость сайта посетитель субъективно оценивает по времени до отрисовки. По умолчанию отчёт показывает медиану. Поставьте квантиль 90%, и станут видны медленные заходы, которые медиана прячет. Чтобы смотреть одну страницу, сделайте сегмент по её адресу.

С чего начать самому за вечер

1. Откройте сайт на телефоне через мобильный интернет: Wi-Fi даст слишком хороший результат. Засеките, когда появляется главный блок и когда можно нажать на кнопку.
2. Прогоните три страницы через PageSpeed Insights по 2-3 раза. Запишите LCP, CLS и разброс оценки.
3. В Метрике откройте «Время загрузки страниц» и выберите квантиль 90%.
4. Отправьте разработчику вопросы из шести разделов выше и попросите ответить цифрами.
5. Правьте по одной причине и после каждой снимайте те же замеры. Так видно, что именно дало эффект.

Скорость стоит перепроверять регулярно: в осмотр сайта раз в неделю за полчаса входит и этот замер.

Ускорение сайта в мои услуги не входит. Я работаю с тем, что начинается после: человек дождался страницы и оставил заявку. Куда она попадает и где теряется, покажет бесплатный разбор. Если заявки теряются уже в компании, почитайте, почему теряются заявки, а если форма отправляется, а в CRM пусто, - как найти заявку, которая не дошла.

Бывает, что посетитель уходит не из-за долгой загрузки, а потому что на первом экране не нашёл, как связаться. Это отдельная проверка: какие кнопки первого экрана оставить.