Быстрый сайт на телефоне: как я поднял результат с 61 до 93

Кейс: основной контент виден через 2,5 с вместо 5,8 с, сайт без скачков и вес с 3 МБ до 0,5 МБ. Конкретные причины и исправления.

Иллюстрация: телефон с сайтом и индикатором скорости
Иллюстрация создана ИИ

Я проектирую быстрые сайты, поэтому и мой собственный должен быть быстрым. Между тем измерение в Google PageSpeed Insights показало на телефоне 61–70 баллов, а основной контент появлялся только через 5,8 секунды. На компьютере всё было хорошо, но большинство людей заходит на сайты с телефона.

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

Результат: до и после

Показатель (телефон) До После
Результат PageSpeed 61–70 88–98 (медиана около 93)
Основной контент (LCP) 5,8 с 2,3–2,9 с
Смещение макета (CLS) 0,044–0,114 0
Первое отображение (FCP) 3,0–3,8 с 1,7–2,1 с
Вес страницы 2,96 МБ 0,51 МБ

На компьютере сайт теперь набирает 100 баллов. И всё это без удаления анимаций и без отказа от интерактивного редактора вверху страницы.

Шаг 0: измерьте, прежде чем исправлять

PageSpeed Insights имитирует телефон среднего класса с медленным мобильным интернетом. Это хорошее приближение, но само число баллов говорит немного. Ключевой вопрос: какой элемент Google считает основным контентом и почему он появляется так поздно?

Ответ меня удивил. Google измерял не заголовок страницы, а фотографию в демонстрации редактора, которая появлялась примерно через 6 секунд. Файл загружался мгновенно, но анимация построения страницы открывала его лишь спустя долгое время. Без детального измерения я бы искал проблему совсем в другом месте.

1. Анимация, задерживавшая основной контент

Google считает основным контентом (LCP) самый большой элемент, видимый на экране. Если что-то большое появляется поздно, пусть даже в рамках эффектной анимации, страдает весь результат.

На моём сайте сложились две причины:

  • Демо построения сайта запускалось слишком рано. На телефоне оно начиналось, когда 75% редактора ещё находилось под экраном. Теперь оно стартует, когда редактор въезжает примерно до середины экрана. Это лучше и для посетителя, потому что он видит построение целиком, а не его конец.
  • Заголовок для Google состоял из нескольких мелких кусков. Каждая строка заголовка была отдельным блоком, а анимация дополнительно делила его на отдельные слова. Для Google это больше десятка мелких элементов вместо одного крупного. После изменения заголовок — один блок текста, и он учитывается с первой секунды.

Я также перенёс анимацию появления из JavaScript в CSS. Раньше контент появлялся, пропадал после загрузки скриптов и выезжал снова. Теперь анимация запускается вместе с первым отображением страницы, а заголовок становится чётким, вместо того чтобы проявляться из прозрачности.

2. Скачки при загрузке шрифтов

Сайт использует два шрифта: шрифт без засечек Geist и декоративный курсив Cormorant. Пока они не загрузились, браузер показывает текст запасным шрифтом, например Arial. Запасной курсив был на 17% шире настоящего, поэтому заголовок переносился иначе, а после подмены шрифта весь контент под ним подпрыгивал.

Решение — запасные шрифты с подогнанными размерами. CSS позволяет масштабировать Arial и Times New Roman так, чтобы они занимали столько же места, сколько настоящие шрифты (свойства size-adjust, ascent-override и descent-override). Я измерил оба шрифта, и разница в ширине снизилась с 17% до 2%. Смещение макета упало до нуля.

3. Слишком много файлов, блокирующих отображение

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

Исправления:

  • Один файл CSS вместо пяти. Объединение происходит автоматически при публикации сайта, а в исходном коде файлы по-прежнему отдельные.
  • Скрипты с атрибутом defer. Они загружаются параллельно и выполняются в том же порядке, но не задерживают первое отображение.
  • Стили чата загружаются в фоне. Кнопка чата в любом случае появляется только после загрузки скриптов.

4. Иконки: 1500 в файле, 135 в использовании

Иконки на сайте взяты из библиотеки Phosphor и загружаются как шрифт. Полные файлы содержали около 1500 иконок и весили вместе 280 КБ. Я использую 135.

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

5. Фотографии: правильный размер и формат

Это самая частая проблема сайтов компаний, и у меня она тоже была самой большой:

  • Фотографии в карточках имели ширину 1440 px, а отображались в рамках шириной 285–557 px. Теперь карточки получают версии WebP шириной 800 px. Большие карточки по-прежнему могут взять полное фото через атрибут srcset, если у экрана высокое разрешение. Одни только фотографии проектов похудели с 2,9 МБ до 0,9 МБ.
  • Ленивая загрузка работает не всегда. У фотографий было loading="lazy", но браузер всё равно загружал их сразу. При первой компоновке страницы, прежде чем скрипты достраивали секции выше, они находились близко к началу страницы. Решением стало уменьшение файлов и осознанное управление тем, когда что загружается.
  • Демо загружало фотографии для пяти отраслей про запас. Теперь оно загружает фотографии текущей отрасли непосредственно перед построением, а остальные — только тогда, когда показ действительно переключает отрасли. Экономия: около 1,6 МБ при каждом заходе.

Бонус: страница сама прокручивалась при обновлении

Попутно обнаружилась мелкая, но раздражающая ошибка: после обновления страница открывалась слегка прокрученной вниз. Браузер запоминает место прокрутки относительно конкретного элемента. У меня скрипты после загрузки достраивают половину страницы, поэтому этот элемент оказывался ниже, и страница подпрыгивала на 80–180 px.

Теперь обновление всегда начинается сверху, а кнопка «Назад» возвращает точно на то же место, потому что страница сама запоминает позицию.

Что из этого следует для Вашего сайта

На сайтах компаний, которые я проверяю, чаще всего повторяются одни и те же причины:

  1. Фотографии прямо с камеры или со стока, по несколько мегабайт, вместо файлов, подогнанных под место на странице.
  2. Слайдер или видео вверху страницы, которое появляется с задержкой и в глазах Google становится основным контентом.
  3. Тяжёлая тема и больше десятка плагинов, каждый из которых добавляет свои стили и скрипты на каждую страницу.
  4. Несколько видов шрифтов без подогнанных запасных, из-за чего текст подпрыгивает.
  5. Отсутствие измерений. Не проверив, какой элемент является основным контентом, легко исправлять не то, что нужно.

Проверка занимает полминуты: введите адрес в инструменте Проверить сайт, и Вы получите оценку скорости от Google вместе со списком конкретных причин.

Сколько стоит ускорение сайта

Мелкие исправления, такие как сжатие фотографий, наведение порядка в плагинах и настройки сервера, я делаю в рамках технической поддержки от 149 зл в месяц. Если сайт стоит на тяжёлой теме и исправления стоили бы больше, чем новая версия, модернизация сайта стоит от 2 900 зл. Все цены указаны без НДС.

Давайте проверим Ваш сайт

Проверьте свой сайт бесплатно и пришлите мне отчёт, который показан под результатом, или напишите через форму. Я отвечу в течение 24 часов, что замедляет сайт и сколько стоит исправление. Новые клиенты получают скидку 20% на первый заказ.

Частые вопросы

Связанные услуги

Есть похожий проект?

Опишите, что Вам нужно, и в течение 24 часов я пришлю оценку. Новые клиенты получают скидку 20% на первый заказ.

Рассчитать проектЗаписаться на звонок (20 мин)

Читайте также

Сайты1 ноября 2026 г.9 мин чтения

Сайт для ресторана: меню и онлайн-заказы

Что нужно сайту ресторана и пиццерии: меню в виде текста, 14 аллергенов при онлайн-заказах, собственные заказы наряду с порталами и профиль компании в Google.