Быстрый сайт на телефоне: как я поднял результат с 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.
Теперь обновление всегда начинается сверху, а кнопка «Назад» возвращает точно на то же место, потому что страница сама запоминает позицию.
Что из этого следует для Вашего сайта
На сайтах компаний, которые я проверяю, чаще всего повторяются одни и те же причины:
- Фотографии прямо с камеры или со стока, по несколько мегабайт, вместо файлов, подогнанных под место на странице.
- Слайдер или видео вверху страницы, которое появляется с задержкой и в глазах Google становится основным контентом.
- Тяжёлая тема и больше десятка плагинов, каждый из которых добавляет свои стили и скрипты на каждую страницу.
- Несколько видов шрифтов без подогнанных запасных, из-за чего текст подпрыгивает.
- Отсутствие измерений. Не проверив, какой элемент является основным контентом, легко исправлять не то, что нужно.
Проверка занимает полминуты: введите адрес в инструменте Проверить сайт, и Вы получите оценку скорости от Google вместе со списком конкретных причин.
Сколько стоит ускорение сайта
Мелкие исправления, такие как сжатие фотографий, наведение порядка в плагинах и настройки сервера, я делаю в рамках технической поддержки от 149 зл в месяц. Если сайт стоит на тяжёлой теме и исправления стоили бы больше, чем новая версия, модернизация сайта стоит от 2 900 зл. Все цены указаны без НДС.
Давайте проверим Ваш сайт
Проверьте свой сайт бесплатно и пришлите мне отчёт, который показан под результатом, или напишите через форму. Я отвечу в течение 24 часов, что замедляет сайт и сколько стоит исправление. Новые клиенты получают скидку 20% на первый заказ.
Частые вопросы
Выше 90 — очень хороший результат, 50–89 требует доработок, ниже 50 — слабый. Однако важнее самого числа три показателя Core Web Vitals: основной контент до 2,5 с, смещение макета до 0,1 и реакция на клик до 200 мс.
Google измеряет сайт на своих серверах и имитирует медленный телефон с медленным интернетом. Небольшие различия во времени загрузки файлов меняют результат даже на 10–20 баллов. Поэтому измеряйте несколько раз и смотрите на медиану, а не на единичный результат.
Да, но это не самое важное. Google учитывает Core Web Vitals как один из многих сигналов, а контент и релевантность ответа значат больше. Зато скорость напрямую влияет на то, останется ли клиент на сайте.
Простые исправления, такие как сжатие фотографий и наведение порядка в плагинах, я делаю в рамках технической поддержки от 149 зл в месяц. Если сайт стоит на тяжёлой теме и его трудно исправить, модернизация стоит от 2 900 зл без НДС.
Связанные услуги
Есть похожий проект?
Опишите, что Вам нужно, и в течение 24 часов я пришлю оценку. Новые клиенты получают скидку 20% на первый заказ.


