Time To Interactive – измеряя пользовательский опыт
С самого начала веб-разработчики и браузеры сосредоточились на технических метриках, что не всегда соответствовало пользовательскому опыту. В качестве примера можно привести, показатели Page Load Time и DOM Content Loaded.
Последние нескольких лет мы стали уделять больше внимания метрикам, которые представляют взгляд пользователя на просмотр веб-страниц. В результате мы получили такие показатели, как “Speed Index”(коэффициент скорости), “first paint” (первое отображение). А также специфические показатели сайта. Например, “time to first tweet” (время до просмотра первого твита).
Сейчас интернет начал переходить на одностраничные приложения, отображаемые в браузере. Метрики, основанные на рендеринге, сильно наказали такие сайты. И есть за что: в них пользователь смотрел на пустой экран, ожидая загрузки приложения и начала создания интерфейса.
Большая часть фреймворков для создания веб-приложений перешла на серверный рендеринг. При этом клиенту сначала отправляется HTML код, чтобы его можно было быстрее отобразить, а уже затем присоединяется логика приложения. В результате они получили сразу два преимущества: быструю визуализацию при поддержке полнофункциональной работы приложения.
На самом ли деле?
Из-за глобального перехода приложений на серверный рендеринг и расширения их функционала, стали проявляться тревожные тенденции. Приложения быстро загружаются. Но если пользователь пытался взаимодействовать со страницей, он сталкивался с задержками в работе интерфейса. Пользователи могли многократно нажимать на кнопку или ссылку, но ничего не происходило в течение нескольких секунд.
При использовании серверного рендеринга пользовательский интерфейс загружается быстро. Но коду, отвечающему за подключение логики приложения, требовалось несколько секунд, и он блокировал основной поток браузера на все это время.
WebPageTest добавил строку внизу каскада для отображения отзывчивости основного потока браузера. Главный поток блокируется, если он не получает ответа в течение 50 мс.
Time To Interactive – это показатель, определяющий, когда был загружен основной контент и пользователь может начинать взаимодействовать с ним.
Преобразование понятия в технический показатель, готовый к применению, оказалось сложным процессом, который еще не завершен. Но в текущей версии реализации доступно два механизма измерения:
Самой большой разницей между двумя метриками является то, что «Consistently Interactive» будет учитывать любые задержки, возникающие в конце загрузки страницы. Например, очень медленный обработчик события загрузки. При этом «First Interactive» не будет наказывать сайты за эти задержки. Хотя именно они могут приводить к ухудшению пользовательского опыта:
Ни одна из метрик не является идеальной. Поэтому их следует рассматривать в качестве дополнительных метрик для оценки производительности.
Пожалуйста, опубликуйте свои комментарии по текущей теме статьи. За комментарии, лайки, подписки, дизлайки, отклики низкий вам поклон!
Пожалуйста, оставляйте ваши комментарии по текущей теме статьи. Мы очень благодарим вас за ваши комментарии, лайки, отклики, дизлайки, подписки!
Time to Interactive
Недавние исследования Google показали, что 53% посетителей покидают мобильный сайт, если его загрузка занимает более трех секунд. Но результаты, которые всплыли в процессе данных исследований стали шокирующими. Огромное количество сайтов, в своей мобильной версии при слабом интернет-сигнале, готовы к полноценному взаимодействию спустя только 22 секунды. После этого, поисковые системы изменили алгоритм ранжирования, поставив на первое место именно скорость загрузки. И сколько бы денег вы не вложили в платное продвижение, если не проведена полная оптимизация сайта и он работает медленно, поисковики не предложат его пользователям. После этого появилось большое количество скоростных интернет-ресурсов.
При проведении оптимизации сайта, некоторые веб-разработчики уделяют внимание исключительно скорости загрузки страницы. И это в корне неправильный подход. Настройки должны осуществляться полноценные и затрагивать все аспекты. Помимо простой загрузки различных ресурсов, составляющих веб-страницу, также необходимо учитывать время выполнения JavaScript. Это время, которое требуется браузеру для выполнения элементов JavaScript, которые делают страницу интерактивной. И все они добавляют время к традиционным показателям загрузки страниц. А если говорить непосредственно о взаимодействии — то являются даже важнее.
Одним из важнейших показателей в данном сегменте является Time to Interactive. Это время, за которое контент страницы становится функциональным и готовым для взаимодействия с пользователем после стабилизации контента. Это не опция, а критерий оценки.
Что такое показатель Time to Interactive
Time to Interactive (TTI) является метрикой Google, которая используется всеми браузерами, а также другими поисковыми системами. TTI измеряет сколько времени требуется в интервале от момента загрузки элементов страницы до момента, когда эти элементы становятся интерактивными — доступными для использования.
Следовательно, Time to Interactive — это точка, в которой макет стабилизировался, ключевые веб-шрифты видны, а основной поток доступен для обработки пользовательского ввода. Создано это для того, чтобы при работе со всё более сложными веб-интерфейсами, учитывать не только скорость загрузки страницы, но и насколько быстро она реагирует на действия пользователя.
Все показатели измеряются в миллисекундах. Полностью интерактивной страница является только при соблюдении трёх основных правил:
• На странице отображается полезный контент, который измеряется первой содержательной краской
• Обработчики событий регистрируются для наиболее видимых элементов страницы
• Страница реагирует на взаимодействие с пользователем в течение 50 миллисекунд и менее
Измерение TTI является крайне важным, так как некоторые сайты оптимизируют видимость контента за счет интерактивности. И этим пользуются недобросовестные веб-разработчики. При этом, для пользователя такой сайт будет не удобным и не функциональным. Он визуально кажется готовым к использованию, но когда пользователь пытается взаимодействовать с ним, то ничего не происходит. Это негативно сказывается на конверсии.
Как измерить TTI
Одним из основных расширений, которое в настоящее время использует TTI в качестве метрики в своих отчетах, является расширение Chrome Lighthouse. «Маяк» использует TTI как фактор измерения общей эффективности сайта. Запустив сайт с Lighthouse и проведя его тестирование, на выходе становится доступным подробный отчет об общей эффективности сайта его доступности и реальном времени, которое пользователи затрачивают на взаимодействие с ним.
Все показатели имеют как цифирное, так и цветовое значение:
• Быстро (зелёный) — 0,5-2 секунды
• Средне (оранжевый) — 5,3-7,3 секунды
• Медленно (красный) — выше 7,3 секунды
Стоит учитывать, что отследить Time to Interactive на устройствах реальных пользователей, а не на собственном ПК или мобильном устройстве, несколько сложнее. Для этого разработан метод getFirstConsistentlyInteractive(), используя который в Google Analytics,можно отследить TTI. Для его применения необходимо ввести приблизительно следующий скрипт:
import ttiPolyfill from ‘./path/to/tti-polyfill.js’;
eventCategory: ‘Performance Metrics’,
eventAction: ‘TTI’,
eventValue: tti,
nonInteraction: true,
Данный метод позволяет задать ряд параметров, настройка которых производится вручную, чтобы определить TTI в реальном времени.
За счёт чего улучшить показатели Time to Interactive
Наиболее очевидными решениями является проведение оптимизации JavaScript: отсрочка или удаление ненужной работы; сокращения полезных нагрузок JavaScript с помощью разделения кода и применения шаблона PRPL; проработка стороннего JavaScript и прочее.
Помимо этого, необходимо проанализировать и оптимизировать и иные элементы. К примеру, детально поработать над критическим путём рендеринга для его сокращения. Этого можно достигнуть рядом способов — применять ленивую загрузку изображений, использовать кэширование информации и прочее.
Задумываться о TTI и всём, что на него влияет, необходимо ещё на этапе этапе разработки сайта. Продумать шрифты, визуальные элементы и саму структуру страницы. Это делается не только с точки зрения «красиво», а что куда важнее — уровень производительности, которую сайт способен дать пользователю. В противном случае, потребуется проведение оптимизации с частичным ребренингом.
Особенности Google PageSpeed: улучшение оценки сайта и его рейтинга в поиске
Материал, перевод которого мы сегодня публикуем, посвящён рейтингу скорости сайтов, который можно вычислить с помощью Google PageSpeed Insights.
Ни для кого не секрет то, что скорость сайта в наше время стала одной из его важнейших характеристик. Чем быстрее сайт загружается и готовится к работе — тем выше может быть доход, который он приносит своему владельцу. Ускорение сайта означает снижение числа пользователей, которые, едва зайдя на этот сайт, покидают его, устав ждать загрузки его материалов. Особую значимость быстродействию сайта придаёт тот факт, что теперь показатели Google PageSpeed используются как один из факторов ранжирования сайтов в результатах поиска. В результате сегодня многие организации уделяют скорости своих сайтов самое пристальное внимание.
Изменения в алгоритмах ранжирования сайтов
В прошлом году компания Google внесла два серьёзных изменения в алгоритмы поискового индексирования и ранжирования сайтов.
Для того чтобы понять то, как эти изменения воздействуют на наши проекты в плане оптимизации их производительности, нам нужно разобраться с технологиями, лежащими в основе оценки скорости сайтов. PageSpeed 5.0 представляет собой полностью пересмотренную версию этой системы. Теперь в её основе лежат Lighthouse и CrUX (Chrome User Experience Report).
Это обновление, кроме того, принесло и новый алгоритм оценки, который значительно усложняет задачу получения высокого балла в PageSpeed.
Что изменилось в PageSpeed 5.0?
До версии 5.0 инструмент PageSpeed проверял страницу, анализируя её соответствие набору эвристических правил. Если на странице присутствовали большие несжатые изображения — PageSpeed мог посоветовать веб-разработчику сжать эти изображения. Нет заголовков Cache? Система могла посоветовать их добавить.
К этим проверкам страницы были привязаны рекомендации. Следование рекомендациям могло привести к улучшению производительности страницы. Но эвристические правила были довольно-таки поверхностными, они не были нацелены на исследование того, какие впечатления вызовут у реального посетителя сайта загрузка и рендеринг страницы.
В PageSpeed 5.0 страницы загружаются в настоящий браузер Chrome, которым управляет Lighthouse. Lighthouse записывает показатели, полученные из браузера, применяет к ним модель балльных оценок и выводит общую оценку производительности. Рекомендации по улучшению производительности приводятся на основании баллов, набранных исследуемой страницей по отдельным показателям.
В Lighthouse, как и в PageSpeed, есть система оценки производительности сайтов. В PageSpeed 5.0 оценка производительности берётся непосредственно из Lighthouse. Оценка производительности, выводимая PageSpeed, теперь является той же самой оценкой, что выдаёт Lighthouse.
Оценка производительности, выводимая PageSpeed, основана на оценке, формируемой Lighthouse
Теперь, когда мы знаем о том, откуда берётся оценка PageSpeed, давайте поговорим о том, как эта оценка вычисляется, и о том, что можно предпринять для улучшения скорости сайта.
Что такое Google Lighthouse?
Lighthouse — это опенсорсный проект, которым занимается специальная команда, выделенная из числа разработчиков Google Chrome. За последние пару лет Lighthouse стал стандартным бесплатным инструментом для анализа производительности сайтов.
Lighthouse использует средства Chrome по удалённой отладке (Chrome Remote Debugging Protocol) для чтения сведений о сетевых запросах, для измерения производительности JavaScript-кода, для проверки соблюдения стандартов доступности содержимого страницы. Этот инструмент измеряет временные показатели, ориентированные на особенности восприятия страницы пользователями. Среди них, например, First Contentful Paint (Время загрузки первого контента), Time to Interactive (Время загрузки для взаимодействия) и Speed Index (Индекс скорости загрузки).
Если вы интересуетесь Lighthouse — взгляните на этот материал из официального репозитория проекта, посвящённый общему описанию его архитектуры.
Вычисление оценки производительности сайта в Lighthouse
В ходе исследования производительности страницы Lighthouse записывает множество метрик, ориентированных на оценку того, что видит, и что испытывает пользователь, работая со страницей. Вот шесть показателей, используемых для вывода общей оценки производительности:
Следуя этому алгоритму и рассматривая данные, используемые для вычисления показателя TTI, можно заметить, что если страница смогла стать «интерактивной», пригодной для взаимодействия с пользователем, за 2.1 секунды, то показатель TTI окажется равным 92/100.
После того, как будет вычислен каждый из показателей, ему назначается определённый вес, который используется как модификатор при расчёте общего показателя. Вот веса, назначаемые различным метрикам.
| Метрика | Вес |
| Time to Interactive (TTI) | 5 |
| Speed Index | 4 |
| First Contentful Paint | 3 |
| First CPU Idle | 2 |
| First Meaningful Paint | 1 |
| Estimated Input Latency | 0 |
Веса указывают на то, какое воздействие каждый из показателей оказывает на впечатления мобильного пользователя от работы со страницей.
В будущем этот набор может быть расширен путём включения в него показателей, взятых из набора данных Chrome User Experience Report, связанных с восприятием сайтов пользователями.
Возможно, вам интересно будет узнать о том, как использование весов влияет на итоговую оценку производительности. Если это так — взгляните на эту таблицу, созданную командой Lighthouse. Проанализировав её, можно лучше понять этот процесс.
Фрагмент таблицы, демонстрирующей расчёт оценки производительности страниц
Если в примере, приведённом выше, изменить показатель interactive (это — то, что мы называем здесь TTI) с 5 секунд до 17 секунд (то есть — до уровня глобального среднего показателя TTI для мобильных страниц), то оценка страницы упадёт до 56% (то есть — она получит 56 баллов из 100 возможных).
В результате можно сделать вывод о том, что наибольшее влияние на итоговую оценку сайта оказывает метрика TTI. Из этого следует то, что для получения высокой оценки PageSpeed странице необходимо демонстрировать достойный показатель TTI.
Улучшение TTI
Если в общих чертах рассматривать проблему улучшения TTI, то можно сказать, что существуют два фактора, которые чрезвычайно сильно влияют на этот показатель:
Везде, где это возможно, уберите неиспользуемый JavaScript-код, или постарайтесь, чтобы страница загружала бы только те скрипты, которые используются на этой странице. Выполнение этой рекомендации может означать избавление от старых полифиллов или замену сторонних библиотек на более компактные и более современные альтернативы.
Важно помнить о том, что то, что называют «ценой JavaScript», это не только время, необходимое на загрузку кода. Браузеру нужно распаковать, распарсить, скомпилировать и, в итоге, выполнить загруженный JavaScript-код. Выполнение всех этих операций может занять заметное время. Особенно — на мобильных устройствах.
Среди эффективных мер по уменьшению объёма JS-кода, используемого страницами, можно отметить следующие:
Мониторинг TTI
Для того чтобы успешно исследовать то, как ваш сайт воспринимают пользователи, просматривающие его, мы рекомендуем использовать системы мониторинга производительности сайтов наподобие Calibre. В частности, речь идёт о том, что сайты испытывают минимум на двух устройствах — на быстром настольном компьютере и на мобильном телефоне, производительность которого находится на уровне медленных устройств среднего класса.
При таком подходе у вас будут данные и для наилучшего варианта работы с вашим сайтом, и для наихудшего. Вам при этом придётся свыкнуться с тем, что посетители вашего сайта не пользуются такими же мощными устройствами, какими пользуется ваша команда.
Тщательное ручное профилирование
Для того чтобы извлечь максимум пользы из профилирования производительности JS-кода тестовые страницы испытывают на специально замедленных мобильных устройствах. Если у вас в ящике стола валяется старый телефон — реализация этой идеи может дать ему замечательную вторую жизнь.
Хорошим заменителем реальных устройств являются возможности инструментов разработчика Chrome. Вот материал, посвящённый профилированию React-приложений с использованием этих инструментов.
Другие метрики
Такие метрики, как Speed Index, First Contentful Paint и First Meaningful Paint, основаны на том, как браузер визуализирует страницу. На них влияют факторы, похожие на те, о которых мы уже говорили. Воздействие на эти факторы часто ведёт к улучшению всех этих показателей.
Объективно говоря, улучшать эти метрики проще, чем TTI. Дело в том, что базой для их вычисления служит скорость рендеринга страниц браузером. Эти метрики можно улучшить, точно следуя рекомендациям, выдаваемым после анализа страниц с помощью Lighthouse.
Если вы ещё не выполняете предварительную загрузку шрифтов или не оптимизируете страницу с учётом особенностей критически важных запросов — то вы вполне можете начать улучшение показателей рендеринга своего сайта именно с этих двух направлений. В этом материале можно найти подробные сведения о том, как браузер загружает и выводит критически важные ресурсы, используемые при формировании веб-страниц.
Итоги: о наблюдении за сайтами и о внесении в их работу ощутимых улучшений
Обновлённая поисковая консоль Google, Lighthouse и PageSpeed Insights — это отличные средства, которые позволяют мгновенно оценить общие показатели производительности сайта. Однако они не очень хорошо подходят для команд, которым необходимо непрерывно отслеживать и улучшать производительность их проектов.
Непрерывный мониторинг производительности — это важнейшая деталь рабочего процесса, нацеленного на постоянное поддержание производительности сайта на высоком уровне. При таком подходе команда разработчиков проекта мгновенно узнаёт о проблемах с производительностью. При ручном тестировании производительности возможен неожиданный разброс результатов. В результате без создания специализированного тестового окружения оказывается почти невозможным проведение испытаний производительности сайта с использованием разных устройств, или с имитацией других изменяющихся параметров систем потенциальных пользователей.
Скорость страниц стала важнейшим фактором в SEO-ранжировании страниц. Особенно сильно это заявление звучит в наши дни, когда почти 50% веб-трафика создают мобильные устройства.
Для того чтобы ваш сайт не потерял бы позиции в поисковой выдаче, постарайтесь использовать современные версии инструментов для анализа производительности его важнейших страниц и поддерживайте его скорость на устраивающем вас уровне.
Уважаемые читатели! Оптимизируете ли вы свои веб-проекты с учётом улучшения показателей, влияющих на оценки, выставляемые Google PageSpeed?
Lighthouse. Руководство по оптимизации сайтов для начинающих
Быстрые сайты любят и пользователи, и поисковики.
С первыми всё просто: если страница долго грузится, пользователь её закроет и перейдёт на другой сайт. С поисковиками похожая история: скорость загрузки влияет на ранжирование сайта в поисковой выдаче.
Проверить производительность сайта можно с помощью разных инструментов. Один из наиболее известных — Lighthouse от компании Google. Он не только тестирует сайт и показывает оценку производительности, но и даёт конкретные рекомендации: что можно улучшить, чтобы сделать сайт быстрее.
Давайте разберём, как с помощью Lighthouse проверить качество сайта и повысить его производительность. Мы не будем углубляться в алгоритмы работы инструмента и принципы подсчёта внутренних метрик: начинающим веб-разработчикам это и не нужно. Однако знать, как работает инструмент, и уметь использовать его в своих проектах — очень важный навык.
Как запустить Lighthouse
Запустить инструмент можно тремя способами:
Через расширение для браузера Chrome или Firefox. Установите расширение, затем откройте свой сайт и запустите проверку с помощью кнопки Generate report.
Пример запуска Lighthouse из браузера Firefox
С помощью инструментов разработчика — Chrome DevTools. Чтобы запустить проверку, откройте инструменты разработчика, переключитесь на вкладку Lighthouse и нажмите на кнопку Generate report.
Мы разберем основы работы с Lighthouse на примере Chrome DevTools. Этого вполне достаточно, чтобы понять возможности инструмента. Для продвинутого использования можно установить npm-пакет и работать с Lighthouse через консоль. Этот способ позволяет более гибко настраивать инструмент и запускать его в автоматическом режиме.
Какие параметры оценивает Lighthouse
Lighthouse анализирует четыре показателя: производительность, доступность, SEO и лучшие практики. Для прогрессивных веб-приложений добавляется пятый параметр — PWA.
Performance — производительность. Анализирует скорость загрузки сайта. На эту оценку влияет время блокировки, отрисовки стилей, загрузки интерактивных элементов, шрифтов и контента.
Progressive Web App — Прогрессивные web-приложения. Проверяет, регистрирует ли сайт Service Workers, работает ли офлайн, возвращает ошибку 200.
Best Practices — лучшие практики. Проверяет безопасность сайта и использование современных стандартов веб-разработки. Оценка зависит от того, используется ли на сайте HTTPS, устаревшие API, правильная кодировка и другие параметры.
Accessibility — доступность. Проверяет, могут ли все пользователи получать доступ к контенту и эффективно перемещаться по сайту. Эта оценка зависит от понятности и воспринимаемости контента, возможности управлять интерфейсом и передвигаться по содержимому без помощи мыши.
SEO — оценивает соответствие страницы советам Google по поисковой оптимизации. Здесь проверяется использование метатегов, доступ к индексации и переобходу роботами, наличие атрибутов alt у изображений, адаптированность к мобильным экранам и другие характеристики.
Каждый параметр оценивается по 100-балльной шкале: чем выше, тем лучше. У каждой группы оценок также есть свой цвет. Зелёный выставляется при 90-100 баллах, он показывает, что с сайтом всё хорошо. Оранжевый можно получить при 50-89 баллах. То есть с сайтом всё хорошо, но можно сделать ещё лучше. Если оценка ниже 49 баллов, она становится красной. Это означает, что над производительностью стоит поработать.
Большой плюс Lighthouse в том, что проверять качество сайта можно как на десктопной, так и на мобильной версии.
Оценки при этом будут отличаться. Порой они различаются и при запуске нескольких тестов для одной версии сайта. В этом случае колебания возможны при:
использовании на сайте анимаций, которые отображаются рандомным образом;
использовании расширений для браузера;
запуске антивирусных программ;
использовании устройств с разной производительностью.
Чтобы оценка была максимально приближена к реальной, рекомендуется запускать проверку в режиме инкогнито. Тестируйте сайт при стабильном интернет-соединении и отключите программы, которые могут повлиять на результаты.
Результаты проверки десктопной версии сайта
Как улучшить производительность сайта с помощью Lighthouse
Lighthouse не только показывает оценку по каждому из четырёх критериев, но и даёт конкретные рекомендации: что можно улучшить.
Например, оценка производительности складывается из шести метрик:
First Contentful Paint — измеряет время, которое понадобится браузеру для отображения первой части содержимого DOM.
Speed Index — проверяет скорость визуального отображения контента во время загрузки страницы.
Largest Contentful Paint — измеряет время загрузки самого большого элемента в области просмотра.
Time to Interactive — проверяет, за какое время страница станет полностью интерактивной.
Total Blocking Time — смотрит, в течение какого времени происходит блокировка страницы в ответ на действия пользователя: клики мышью или нажатия клавиш.
Cumulative Layout Shift — проверяет визуальную стабильность: смещение макета из-за асинхронной загрузки ресурсов.
Показатели метрик — на этом сайте всё хорошо
Ниже под метриками Lighthouse описывает возможности и предложения, которые помогут улучшить показатели.
Давайте разберём, как можно повысить оценки Lighthouse на конкретном примере. Для этого возьмём стандартный сайт, размещённый на бесплатном хостинге, и проверим его производительность. Тестировать будем мобильную версию, так как Google преимущественно использует мобильную версию контента для индексации и ранжирования.
Как видно на скриншоте, у сайта средние показатели производительности: 69 баллов из 100. Это неплохо, но давайте их улучшим. Для этого используем рекомендации, которые даёт Lighthouse. Каждую из них можно раскрыть и посмотреть подробнее, что предлагается изменить:
Если такого описания недостаточно и вы всё равно не понимаете, что нужно делать — нажимайте на ссылку Learn more. В открывшемся окне появится более подробная информация и руководство для разработчиков. Вся информация на английском языке, но даже если вы его не знаете, Google Переводчик поможет вам разобраться.
В нашем случае Lighthouse предлагает использовать современные форматы изображений: WebP и AVIF, так как они весят меньше, чем PNG и JPEG. Мы также можем уменьшить размер изображения с 567 Кб до 500 Кб. На первый взгляд может показаться, что это мелочи. Но если мы оптимизируем изображения на сайте, то браузерам понадобится меньше времени на их загрузку.
Также важно помнить про блокирующие рендеринг ресурсы, такие как стили и скрипты. Lighthouse предупреждает нас о том, что мы можем уменьшить их влияние на скорость, если минифицируем код или встроим критические ресурсы инлайн.
Если соблюдать хотя бы эти рекомендации, мы повысим оценку Lighthouse. Пусть не до 100 баллов, но это уже будет значительный вклад в производительность сайта.
Среди разработчиков нет единого мнения о том, когда лучше проверять производительность сайта. Кто-то этим занимается в процессе разработки, кто-то — в самом конце. Неважно, какой способ выберете вы. Главное не забывайте тестировать свой продукт и работать над его качеством.
Базовые рекомендации для повышения производительности:
Подключайте к документу минифицированные стили и скрипты.
Подумайте, что можно сделать с неиспользуемым кодом. Возможно, его стоит переписать или удалить.
Оптимизируйте изображения. Используйте для этого специальные программы или пакеты npm.
Используйте современные форматы графики, собирайте SVG в спрайты.
По возможности уменьшайте количество подключенных ресурсов;
Подсказывайте браузеру, какие ресурсы самые важные: включайте предзагрузку или наоборот — ленивую загрузку.
Можно ли получить 100 баллов в Lighthouse?
Максимальная оценка вполне достижима. В сети есть проект Зака Лезермана — рейтинг сайтов с максимальными баллами Lighthouse. На момент подготовки этой статьи в нем было 133 ресурса, набравших сто баллов по каждому из четырёх критериев.
Нужно ли вам добиваться таких показателей — решайте сами. Но помните: главное не сама оценка. Главное — сделать сайт достаточно быстрым, безопасным и удобным для пользователей.
Какие еще есть инструменты для проверки производительности?
Lighthouse далеко не единственный инструмент для оптимизации скорости сайтов. Есть и другие, не менее популярные сервисы. Например, WebPageTest, GTmetrix и Pingdom Tools. Или даже PageSpeed Insights, который использует для проверки алгоритмы Lighthouse, но работает только с сайтами, размещенными в Интернете. Протестировать сайты на локальном сервере с его помощью не получится.
У каждого из таких инструментов есть свои особенности. Например, GTmetrix и Pingdom Tools дают более развёрнутые результаты проверки.
Так выглядят оценки и результаты проверки в WebPageTest
Они также показывают последовательность загрузки ресурсов и учитывают во время проверки местонахождение сервера — параметр, который тоже может влиять на производительность. А в GTmertix можно не только получить результаты тестирования, но и отслеживать их в дальнейшей работе.
Если по какой-то причине вам не подходит Lighthouse, можете остановиться на любом другом инструменте. Ведь главный принцип получения высокой оценки в любом из сервисов — это хороший, качественный код. А научиться его писать вы можете на профессиональных курсах «HTML и CSS. Профессиональная вёрстка сайтов» и «HTML и CSS. Адаптивная вёрстка и автоматизация».