Быстрый сайт в офисе ≠ быстрый сайт у реального пользователя: почему Lighthouse-оценка обманывает

Студия из Пакистана объясняет, почему высокий балл в Lighthouse — не гарантия быстрой работы сайта для реальных пользователей на слабом соединении, и какие базовые меры действительно решают проблему.

Lighthouse-оценка измеряет сайт в идеальных лабораторных условиях. Реальный пользователь с бюджетным Android-смартфоном и загруженным 3G — это совершенно другой мир, и дисциплина загрузки важнее любого синтетического теста.

Когда офисная скорость волокна не имеет значения

Есть соблазнительная привычка: запустить тест Lighthouse, получить 95+ баллов и объявить работу над производительностью завершённой. Потом пользователь из небольшого города говорит, что сайт грузится вечность на его телефоне, — и выясняется, что между лабораторной оценкой и реальным опытом — пропасть.

Автор оригинальной публикации — Мухаммад Фарзан из веб-студии WebTech Solutions, расположенной в Равалпинди, Пакистан. Его наблюдение ценно не пакистанской спецификой как таковой, а тем, что оно хорошо описывает типичную проблему любого развивающегося рынка: значительная часть аудитории сидит в перегруженных сетях 3G или на «придушенном» 4G, использует среднебюджетные Android-устройства и далеко от мегаполисов, где инфраструктура наилучшая.

Словосочетание «работает отлично в офисе» и «работает отлично у реального пользователя» — это, как правило, два разных утверждения.

CDN — не серебряная пуля

Content Delivery Network (сеть доставки контента) размещает копии ресурсов на серверах ближе к пользователю. Это действительно помогает сократить задержку. Но если между смартфоном пользователя и ближайшей точкой присутствия CDN — загруженный канал 3G, то вся «близость» сервера перестаёт быть преимуществом. Узкое место — последняя миля, и никакое кэширование на edge-узлах её не расширит.

Это меняет парадигму оптимизации: задача не столько «доставить байты быстрее», сколько «отправить меньше байтов». И это, разумеется, применимо не только к Пакистану — любой, кто тестировал свой сайт на реальном 3G-соединении вместо офисного Wi-Fi, подтвердит разницу.

Изображения: главный потребитель трафика

Изображения обычно составляют основную долю веса страницы. И решения здесь не хитрые, а рутинные:

Форматы. Использование WebP или AVIF вместо «сырых» JPEG и PNG сокращает объём на 25–50% при сопоставимом визуальном качестве. Поддержка браузерами этих форматов сейчас уже практически тотальная — бояться нечего.

Явные размеры. Указание атрибутов width и height (или использование компонента фреймворка, который делает это автоматически, например <Image> в Next.js) предотвращает сдвиг макета при загрузке. Это напрямую влияет на метрику Cumulative Layout Shift (CLS) — одну из трёх ключевых Core Web Vitals от Google.

Отложенная загрузка. Изображения ниже сгиба экрана (то есть те, которые пользователь увидит только при прокрутке) нет причин загружать сразу. Атрибут loading="lazy" позволяет браузеру отложить их загрузку до момента, когда они реально понадобятся.

Фарзан приводит пример: при перестройке одного e-commerce-проекта оптимизация только изображений (формат, ленивая загрузка, явные размеры) сократила общий вес страницы примерно на треть — без каких-либо изменений в дизайне. Цифра не уникальная, но наглядная: проблема часто не в сложных архитектурных решениях, а в отсутствии базовой гигиены.

Сторонние скрипты: аудит обязателен

Каждый сторонний скрипт — виджет чата, аналитика, маркетинговые пиксели, встроенные социальные виджеты — добавляет клиенту время на парсинг и выполнение JavaScript. И эта «цена» пропорционально выше на слабом устройстве с медленным соединением, чем на мощном ноутблоуке разработчика с оптоволокном.

Автор рекомендует простой аудит: открыть вкладку Network в Chrome DevTools, отфильтровать по JS и отсортировать по размеру. Для каждого скрипта, назначение которого не очевидно, стоит задать вопрос: оправдывает он своё присутствие в критическом пути загрузки?

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

Самостоятельный хостинг шрифтов

Подключение шрифтов из стороннего CDN (классический пример — Google Fonts через стандартный <link>) добавляет дополнительный DNS-запрос и сетевой обмен рукопожатиями ещё до того, как первый файл шрифта начнёт загружаться. При медленном соединении это ощутимо.

Самостоятельный хостинг шрифтов — например, через пакеты вроде @fontsource — убирает этот промежуточный шаг. В сочетании с CSS-свойством font-display: swap текст отображается шрифтом-заглушкой немедленно, а не остаётся невидимым, пока кастомный шрифт не скачается. Это классическая проблема «вспышки невидимого текста» (FOIT), и swap — стандартное решение.

Изменение минимальное, но на медленных соединениях оно стабильно даёт измеримое улучшение метрики Largest Contentful Paint (LCP) — времени отрисовки самого крупного видимого элемента.

Тестировать нужно на 3G, а не только на волокне

Chrome DevTools предлагает встроенную эмуляцию медленных сетей — пресеты «Slow 3G» и «Fast 3G» на вкладке Network. По наблюдению автора, этот инструмент используется разработчиками значительно реже, чем следовало бы.

Синтетический тест Lighthouse, запущенный на быстром соединении, может скрыть проблемы, которые реальный пользователь ощутит мгновенно. Ещё более полезным источником данных является секция «Field Data» в Google PageSpeed Insights — она основана на реальных данных Chrome User Experience Report (CrUX) от посетителей сайта, а не на лабораторном прогоне. Правда, эти данные доступны только для сайтов с достаточным объёмом трафика.

Что это значит для мобильного пользователя

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

Бюджетный Android-смартфон с 2–3 ГБ оперативной памяти и средний процессор вполне способен отрисовать большинство современных веб-страниц за секунду — если эти страницы не перегружены неоптимизированными изображениями, десятками сторонних скриптов и шрифтами, загружаемыми через три лишних сетевых запроса.

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