Производительность сайта Tilda без шаманства
С производительностью сайта часто происходит примерно так: вы сделали проект, всё открывается, заказчик доволен, а потом сайт проверяет сын заказчика, знакомый программист или просто человек, который знает про существование PageSpeed Insights. Через пять минут прилетает скриншот: «Почему здесь 63? Сайт медленный?»
Паниковать и удалять половину первого экрана ради зеленого кружочка не нужно. PageSpeed Insights и Lighthouse действительно полезны, но цифра Performance от 0 до 100 — это не оценка сайта по школьной системе и не процент его качества. Чтобы понять, есть ли проблема на самом деле, нужно смотреть, что именно измерил инструмент и в каких условиях.
PageSpeed Insights и Lighthouse — не одно и то же
Lighthouse — автоматический инструмент Google для тестирования веб-страниц. Он запускает страницу в контролируемых условиях, собирает показатели производительности и рассчитывает итоговый Performance Score от 0 до 100. PageSpeed Insights, или PSI, объединяет два типа информации: лабораторный тест Lighthouse и, когда данных достаточно, статистику реальных пользователей из Chrome User Experience Report — CrUX. Google называет их соответственно lab data и field data.
Разница принципиальная. Lab data — это один тест в смоделированных условиях. Он отлично подходит для поиска технических проблем. Field data показывает, как страницу действительно загружали пользователи Chrome на разных устройствах и сетях за последние 28 дней. Если посещений недостаточно, данных для конкретной страницы может вообще не быть, и PSI иногда показывает данные всего сайта или не показывает полевой блок.
Поэтому скриншот только с большим числом Performance рассказывает далеко не всю историю.
Что на самом деле означает Performance 63, 87 или 96
Lighthouse переводит измеренные показатели в оценки и объединяет их в Performance Score. Диапазоны сейчас такие:
Но самое интересное написано в документации Google буквально рядом: идеальные 100 баллов чрезвычайно сложно получить, и такой результат не считается ожидаемым. Более того, по мере приближения к 100 каждое следующее улучшение требует всё больших изменений. Google приводит пример: улучшение с 99 до 100 может потребовать примерно такого же изменения метрик, как переход с 90 до 94.
Поэтому задача «сделать обязательно 100» технически слабая. Нормальный вопрос звучит иначе: почему страница получила такой результат и есть ли здесь проблема, которую действительно заметят пользователи?
Почему Mobile почти всегда выглядит страшнее Desktop
Оценки для мобильных и десктопных устройств нельзя воспринимать как два одинаковых теста. Lighthouse использует для них разные профили и модели оценки, а PageSpeed запускает мобильный тест в условиях эмулируемого устройства и ограниченной сети.
Поэтому ситуация вроде:
Mobile — 62
Desktop — 94сама по себе не означает, что мобильная версия сайта сделана плохо. Google отдельно отмечает, что мобильные устройства обычно показывают худшую производительность из-за более ограниченных вычислительных ресурсов и менее стабильных сетей.
Смотреть нужно не на сам разрыв между двумя цифрами, а на причины результата.
С чего вообще начинать проверку
Если в PageSpeed Insights доступен раздел с реальными пользовательскими данными, я бы начинала именно с него. Там особенно важны три Core Web Vitals:
- LCP — Largest Contentful Paint показывает скорость появления основного крупного контента страницы. Хорошим считается результат до 2,5 секунды.
- INP — Interaction to Next Paint измеряет отзывчивость страницы при взаимодействии пользователя. Хороший результат — до 200 мс.
- CLS — Cumulative Layout Shift показывает визуальную стабильность: не прыгают ли элементы страницы во время работы. Хорошим считается значение не выше 0,1.
Для полевых Core Web Vitals Google использует
Это уже намного содержательнее, чем просто «у нас 68 баллов»: мы понимаем, что именно не так — медленно появляется основной контент, страница плохо реагирует или элементы скачут.
При этом важно не путать показатели. INP — полевой Core Web Vital, который требует реальных взаимодействий пользователей. В лабораторном Lighthouse для диагностики проблем с JavaScript используется, среди прочего, Total Blocking Time — TBT. Google отдельно рекомендует смотреть на TBT как на один из диагностических сигналов, если проблемы есть именно с отзывчивостью.
Что действительно имеет смысл проверять на Tilda
На Tilda значительная часть технической инфраструктуры находится под управлением самой платформы. Поэтому пытаться исправить вообще каждую строку отчета PageSpeed бессмысленно. Зато есть несколько вещей, которые находятся непосредственно под вашим контролем.
Изображения
Большие и плохо подготовленные изображения — первое, что стоит проверить. Tilda сама относит ручную оптимизацию изображений и Lazy Load к наиболее существенным действиям со стороны пользователя. Платформа автоматически адаптирует изображения под контейнер и устройство и создает WebP-версии, но всё равно рекомендует оптимизировать исходники до загрузки.
Если на первом экране стоит фотография в несколько мегабайт, сначала имеет смысл разобраться с ней, а не искать секретную настройку PageSpeed. Как подготавливать изображения перед загрузкой, лучше рассматривать отдельно: здесь достаточно понимать, что ненужные многомегабайтные исходники действительно могут ухудшать загрузку.
Lazy Load
Lazy Load позволяет загружать изображения не все одновременно при открытии страницы, а по мере того, как пользователь приближается к ним при прокрутке. В Tilda эта функция включена по умолчанию, и сама платформа рекомендует не отключать ее без необходимости.
Проверить это можно в Настройки сайта → Ещё: настройка «Выключить Lazy Load изображений» должна оставаться выключенной. Отдельно Lazy Load можно отключать для изображений и шейпов в Zero Block, поэтому там его тоже стоит проверить, если кто-то ранее менял настройки.
На длинной странице нет никакой пользы в том, чтобы сразу скачивать фотографию из блока, до которого пользователь, возможно, вообще не доскроллит.
Сторонний код
Чаты, виджеты, аналитические системы, пиксели, карты, формы сторонних сервисов и другие скрипты требуют ресурсов браузера. Tilda отдельно предупреждает, что сторонний код может существенно замедлять отрисовку страницы, особенно если подключен неудачно.
Здесь не работает принцип «JavaScript плохой, удаляем всё». Нужная аналитика остается нужной аналитикой. Но если на сайте подключено семь внешних сервисов, два из которых никто уже не использует, это вполне нормальное место для уборки.
Особенно внимательно стоит относиться к собственным модификациям и скриптам, добавленным через T123 или другие способы подключения кода. Если проблема появилась после добавления конкретного виджета или модификации, его временное отключение и повторный тест часто дает больше информации, чем час изучения общей цифры Performance.
Шрифты
Подключаемые веб-шрифты тоже являются ресурсами страницы. Tilda отдельно предлагает системные шрифты как самый быстрый вариант и позволяет включить мгновенную отрисовку контента, чтобы текст появился до окончательной загрузки фирменного шрифта.
Но это не означает, что ради PageSpeed нужно срочно заменить фирменную типографику на Arial. Здесь всегда есть компромисс между производительностью и дизайном. Если фирменный шрифт важен, он может остаться. А вот подключать большое количество семейств и начертаний, которые фактически нигде не используются, уже не имеет особого смысла.
Анимация, видео и сложные первые экраны
Если первый экран состоит из большого видео, нескольких изображений, сложной анимации, стороннего виджета и нескольких пользовательских скриптов, он объективно требует больше ресурсов, чем заголовок, текст и одна фотография.
Но отсюда не следует, что правильный сайт обязательно должен быть статичным. Нужно оценивать стоимость конкретного решения относительно его пользы. Если видео является важной частью истории бренда — возможно, оно оправдано. Если четыре декоративные анимации существуют только потому, что дизайнеру хотелось «немного оживить страницу», а на слабых мобильных устройствах всё начинает заметно тормозить, это уже хороший кандидат на упрощение.
Производительность — один из параметров дизайна, а не религия.
Почему не нужно выполнять все рекомендации PageSpeed подряд
В нижней части отчета PageSpeed можно увидеть длинный список рекомендаций и диагностических сообщений. Lighthouse сам описывает эти разделы как Opportunities и Diagnostics — то есть возможности и диагностические подсказки для дальнейшего анализа.
Это не чек-лист, где все пункты обязаны стать зелеными. На собственноручно написанном сайте разработчик может пересобрать JavaScript, изменить стратегию загрузки модулей или полностью переписать CSS. На Tilda значительная часть платформенного кода находится вне контроля пользователя.
Поэтому фраза PageSpeed вроде «уменьшите неиспользуемый JavaScript» еще не означает, что вы должны найти этот код и удалить его. Сначала нужно определить, кому он принадлежит: вашей модификации, подключенному стороннему сервису или самой платформе.
Работать имеет смысл прежде всего с тем, что контролируете вы: изображениями, сторонними интеграциями, собственным кодом, видео, анимацией, шрифтами и настройками загрузки.
Почему сегодня 72, а через минуту 68
Такое тоже нормально. Google прямо предупреждает, что лабораторные показатели могут изменяться между запусками даже без изменений на самой странице. На результат влияют, среди прочего, состояние сети, доступность вычислительных ресурсов и другие условия конкретного запуска.
Поэтому:
72 → 69 → 73не обязательно означает, что сайт за пять минут трижды сломался и починился. Не стоит оптимизировать страницу, ориентируясь на движение в несколько баллов между отдельными тестами. Гораздо полезнее смотреть на устойчивые проблемы и повторяющиеся диагностические сигналы.
А что тогда считать хорошим результатом?
Для лабораторного Lighthouse Score Google считает
Если Core Web Vitals у реальных пользователей находятся в хорошей зоне, страница нормально работает на мобильных устройствах и вы уже устранили очевидные тяжелые ресурсы, борьба за последние несколько баллов Lighthouse обычно имеет быстро уменьшающуюся практическую ценность.
Если же Performance низкий и одновременно PageSpeed показывает плохой LCP, тяжелый JavaScript, проблемы с отзывчивостью или нестабильную верстку, тогда цифра действительно стала полезным сигналом: есть конкретная проблема, которую нужно расследовать.
То есть сам балл не игнорируем, но и не лечим его отдельно от причин.
Нормальный порядок проверки сайта на Tilda
Я бы работала так:
- Откройте опубликованную страницу в PageSpeed Insights и проверьте Mobile и Desktop.
- Если доступны реальные пользовательские данные, сначала посмотрите Core Web Vitals: LCP, INP и CLS.
- Посмотрите лабораторный Performance и определите, какие именно метрики и диагностика тянут его вниз.
- Проверьте то, что находится под вашим контролем: тяжелые изображения, отключенный Lazy Load, сторонние скрипты, собственный код, видео, анимацию и лишние подключения.
- Исправляйте по одной существенной причине и запускайте проверку снова.
- Не пытайтесь устранять предупреждения платформенного уровня, если у вас нет возможности влиять на соответствующий код.
- После оптимизации обязательно проверьте сам сайт руками на обычном телефоне и компьютере.
Последний пункт важнее, чем кажется. Сайт делается для пользователя, а не для скриншота из Lighthouse.
Что отвечать заказчику на «Почему здесь 63?»
Говорить «PageSpeed вообще ничего не значит» нельзя. Это хороший инструмент диагностики. Но и начинать полную переделку сайта только из-за одного числа не нужно.
Можно спокойно объяснить:
PageSpeed проверяет страницу по нескольким метрикам, а итоговый балл Lighthouse рассчитывается в тестовых условиях. Поэтому сначала нужно посмотреть, какие именно показатели дали такой результат и совпадает ли это с опытом реальных пользователей. Проверим Core Web Vitals, изображения, сторонние скрипты и другие вещи, которые действительно можем оптимизировать. Само число 63 еще не объясняет, в чем именно проблема.
А если следующий вопрос:
Но почему не 100?
здесь у вас есть прекрасный официальный ответ: сам Google пишет, что идеальные 100 баллов чрезвычайно сложно получить и такой результат не является ожидаемым. На этом семейный аудит производительности можно считать конструктивно завершенным.
Главное
PageSpeed Insights и Lighthouse не нужно ни бояться, ни игнорировать. Они хорошо показывают проблемы и помогают понять, куда смотреть дальше. Но производительность сайта — это не соревнование за цифру 100.
Нам важно, чтобы основной контент появлялся достаточно быстро, интерфейс нормально реагировал на пользователя, элементы не прыгали при загрузке, а страница не скачивала и не выполняла очевидно ненужные ресурсы.
Если ради еще пяти баллов приходится удалить полезную аналитику, важный контент или оправданное дизайн-решение, сначала стоит посчитать, что именно вы выигрываете. Оптимизировать нужно сайт. Не кружочек вокруг цифры.