Как использовать индекс скорости Google для повышения производительности WordPress
В данной статье мы рассмотрим, как рассчитывается индекс скорости (Speed Index). А также как измерить его в браузере Chrome.
Что такое индекс скорости в Lighthouse?
Lighthouse – это инструмент с открытым исходным кодом, который сервис Google PageSpeed Insights использует для анализа скорости загрузки веб-станицы.
Lighthouse оценивает веб-страницу по следующим критериям:
Индекс скорости – это один из показателей оценки скорости работы сайта. Он отражает работоспособность сайта в реальных условиях.
Как Google измеряет индекс скорости
В официальной документации Lighthouse индексу скорости дается следующее определение:
Индекс скорости(Speed Index) – это метрика производительности загрузки веб-страницы. Она показывает, насколько быстро содержимое веб-страницы отображается визуально.
Вот как это работает: когда вы проводите проверку веб-страницы с помощью Google PageSpeed Insights, сервис Lighthouse записывает видео загрузки страницы. Значение индекса скорости будет варьироваться в зависимости от области просмотра, которую вы установили для теста.
Lighthouse разбивает видеоролик на кадры: по 10 кадров в секунду. Например, если ваш сайт загружается за 3 секунды, получится 20 кадров, демонстрирующих процесс загрузки.
Упрощенная версия того, как это выглядит.
Для определения того, насколько завершена загрузка страницы, Lighthouse сравнивает каждый кадр с финальным. Затем он наносит завершенность загрузки страницы на ось Y и продолжительность загрузки на Х, чтобы определить среднее значение. Общая оценка представляет собой сумму отдельных интервалов. Область графика, выделенная синим цветом, представляет собой индекс скорости.
Область выше оси представляет собой индекс скорости
Также для определения индекса скорости используется метод Visual Progress от Paint. Он применяется для определения индекса в браузерах, созданных на основе движка WebKit. При этом не используется запись видео загрузки. Показатель рассчитывается на основе данных временной шкалы о событиях отрисовки. Не все браузеры поддерживают данный метод, поэтому он не так широко распространен.
Как измерить индекс скорости в Google Chrome
К какому показателю индекса скорости следует стремиться?
Мы измерили индекс скорости веб-страницы. Но какой результат является хорошим?
По словам Пола Айриша (Paul Irish) из команды разработчиков Google Chrome, идеальный индекс скорости должен быть меньше 1000 мс, что эквивалентно 1 секунде. Получается, что необходимо добиться как можно более низкой оценки индекса скорости.
Как улучшить индекс скорости в WordPress?
Показатель индекса скорости WordPress можно улучшить следующим образом:
Чтобы улучшить восприятие контента, можно воспользоваться различными техниками прогрессивной загрузки.
Если это не приводит к увеличению конверсии – избавляйтесь от этого
Самый эффективный способ улучшить производительность сайта – удалить ненужные ресурсы. Например, неиспользуемые изображения, файлы JavaScript, CSS и т.д.
Довольно убедительные цифры, не так ли?
Применяйте определенную высоту блока и изображения-заполнители
Чтобы более быстро предоставлять пользователю важную часть контента, на странице оставьте место для элементов, которые долго загружаются (изображения и видео). Для этого с помощью CSS задайте блокам определенную высоту или предварительно загружайте изображения-заполнители.
Оптимизируйте изображения
Лучший способ уменьшить вес веб-страницы – избавиться от лишних изображений. А после этого оптимизировать оставшийся графический контент следующими методами:
Оптимизируйте таблицы стилей, скрипты и шрифты
Файлы CSS и JavaScript, которые подключены в верхней части разметки веб-страницы, замедляют ее загрузку. Поэтому их стоит оптимизировать.
Кроме этого каждый шрифт является ресурсом, для загрузки которого браузеру требуется дополнительное время. По умолчанию загрузка шрифтов не начинается до тех пор, пока не будут созданы модели DOM и CSSOM. Что также может привести к задержке рендеринга текста.
Способы оптимизации дополнительных ресурсов веб-страницы:
Оптимизируйте критический путь рендеринга
Критический путь рендеринга – это список ресурсов, которые необходимы браузеру, чтобы отобразить ответ на текущий вопрос пользователя.
Необходимо проанализировать компоненты в критическом пути рендеринга и поискать способы оптимизации загрузки. Вот что по этому поводу рекомендует Google :
Используйте кеширование
С помощью HTTP-кэширования браузер сохраняет копию ресурсов, загруженных пользователем через HTTP. Это позволяет извлекать их без повторного обращения к серверу.
Вам также следует использовать промежуточный кэш. Например, кэш сети доставки контента (CDN) идеально подходит для загрузки ресурсов из ближайшего к пользователю дата-центра.
Ограничения индекса скорости (Speed Index Limitations)
Если на вашем сайте есть динамические элементы – измерения индекса скорости будут неточными. Ниже приведены элементы, которые влияют на показатель скорости:
Индекс скорости при использовании вместе с другими метриками Google PageSpeed Insights помогает получить полное представление о том, как оптимизировать сайт.
Как улучшить индекс скорости с помощью WordPress-плагина
Мы разработали плагин Hummingbird не только для того, чтобы помочь вам повысить показатель индекса скорости. Он также позволяет улучшить пользовательский опыт для посетителей вашего сайта.
Дайте знать, что вы думаете по данной теме статьи в комментариях. За комментарии, дизлайки, лайки, отклики, подписки огромное вам спасибо!
Пожалуйста, оставляйте ваши отзывы по текущей теме статьи. Мы крайне благодарны вам за ваши комментарии, отклики, дизлайки, лайки, подписки!
Синтетический мониторинг производительности
Благодаря внедрению клиентского мониторинга производительности, мы с полной уверенностью можем диагностировать проблемные места проекта и составить план для дальнейшей оптимизации.
Однако было бы неплохо иметь инструмент, который еще на этапе разработки позволял бы выявлять возможные регрессы производительности. Именно так родилась идея о создании синтетического мониторинга.
Содержание
Мониторинг
Perfectum Synthetic — это инструмент для измерения синтетических показателей производительности. Рассмотрим основные требования, которые мы предъявляли к будущему мониторингу.
Гибкая конфигурация
С самого начали разработки мы понимали, что вариантов и условий использования мониторинга может быть много, а значит, от проекта потребуется возможность максимальной конфигурации.
Для удобства работа с инструментом мы разработали утилиту Perfectum CLI и добавили файл конфигурации perfectum.json.
Сочетание возможностей утилиты командной строки и файла конфигурации дает существенную гибкость в использовании мониторинга, начиная от определения бюджетов производительности, заканчивая динамической подменой аудируемых страниц.
Сборка и запуск проекта
Для нас было важно, чтобы инструмент, помимо выполнения основных функций, обеспечивал удобную работу с проектом на всех этапах разработки.
Поэтому возможность автоматической сборки и запуска проекта при внесении изменений избавляет от ручных пересборок, что значительно упрощает локальное использование мониторинга.
Возможность аутентификации
Некоторые наши проекты недоступны для публичного использования и требуют предварительной аутентификации. Поэтому такая возможность доступна через указание пути к файлу auth-скрипта, который выполнится непосредственно перед началом мониторинга.
В процессе аутентификации используется Puppeteer, поэтому содержимое скрипта должно соответствовать правилам использования данного инструмента.
Воспроизводимость результатов
Одним из основных требований, которые предъявляются к подобному виду мониторинга, является воспроизводимость и точность результатов.
Для аудита производительности используется Lighthouse, который в условиях изолированной среды показывает стабильные результаты между запусками.
Также наш мониторинг дополнительно определяет медианный результат среди всех запусков аудита, что позволяет получить наиболее стабильный отчет о производительности.
Метрики
Как упоминалось ранее, Perfectum Synthetic использует Lighthouse. Поэтому рассмотрим, как в этом инструменте происходит общая оценка производительности проекта.
Lighthouse использует значения шести метрик. Каждая метрика отражает состояние разных стадий загрузки страницы и имеет собственный вес, который показывает степень влияния метрики на общий результат.
Ниже приведена соответствующая таблица:
| Название метрики | Вес |
|---|---|
| First Contentful Paint (FCP) | 15% |
| Largest Contentful Paint (LCP) | 25% |
| Cumulative Layout Shift (CLS) | 5% |
| Speed Index (SI) | 15% |
| Time to Interactive (TTI) | 15% |
| Total Blocking Time (TBT) | 25% |
Метрики FCP, LCP и CLS подробно рассматривались в статье о клиентском мониторинге производительности, поэтому в этой мы рассмотрим остальные — SI, TTI и TBT.
Speed Index
Speed Index (SI) показывает, насколько быстро отображается содержимое страницы в процессе загрузки приложения.
Принцип работы
В основе работы SI лежит понятие визуального завершения (Visually Complete, VC):
Рассмотрим два возможных варианта загрузки страницы:
Оба варианта начинают загрузку и становятся визуально завершенными (VC) за одно и тоже время (5 секунд). Но очевидно, что вариант А гораздо предпочтительнее с точки зрения пользователя. И чтобы увидеть количественную разницу между подобными вариантами загрузки, используется показатель SI.
SI оценивает процент визуального завершения в разные моменты времени:
Стандартный механизм определения VC, используемый, к примеру, в WebPageTest, основывается на анализе оттенков цветовой палитры страницы. Каждые 100 мс происходит сравнение количества оттенков между двумя соседними фреймами:
Однако следует отметить, что в Lighthouse применяется другая модель определения визуальной завершенности. Вместо сравнения количества оттенков цветовой палитры используется индекс структурного сходства (SSIM), который основывается на оценке воспринимаемого качества изображения, включая информацию об изменениях яркости и контраста.
Разобравшись с тем, как происходит расчет показателя VC, представим графически рассмотренные варианты загрузки страницы:
Графики отображают отношение времени загрузки и процента визуальной завершенности.
Область графика под кривой можно представить как отрендеренную часть страницы в определенный момент времени:
Для вычисления SI мы могли бы использовать площадь данной области, однако есть важный нюанс. Напомню, что 5 секунд загрузки которыми мы оперируем, являются временем визуальной завершенности (VC), но они не являются показателем полной загрузки страницы. Это значит, что область под кривой будет увеличиваться пропорционально времени загрузки, при этом увеличивая результат показателя SI.
В то же время использование области графика над кривой будет лишено подобных недостатков, поскольку она всегда ограничена наступлением события VC:
Именно поэтому алгоритм работы SI использует данную область при вычислении результата.
Разумеется, для нахождения площади указанной области (плоской криволинейной фигуры) формула расчета использует определенный интеграл и выглядит следующим образом:
Поэтому чем меньше площадь данной области, а соответственно, и значение SI — тем лучше:
Оценка результатов
При оценке результатов показателя рекомендуется использовать следующие градации:
Способы оптимизации
Как правило, любые оптимизации, направленные на увеличение скорости загрузки страницы, положительно скажутся на показателе SI.
Список данных оптимизаций я приводил в статье о клиентском мониторинге производительности.
Дополнительной рекомендацией будет проверка на отсутствие явления FOIT (Flash Of Invisible Text).
Time To Interactive
Time To Interactive (TTI) измеряет время с момента начала загрузки страницы до момента стабильного реагирования на ввод пользователя.
Принцип работы
В основе работы TTI лежат три понятия: время первой отрисовки контента (First Contentful Paint, FCP), продолжительные задачи (Long Tasks) и временной интервал с отсутствием продолжительных задач и сетевых запросов (Quiet Window).
Для начала посмотрим на временную шкалу, представляющую типичную загрузку страницы:
Кроме выполнения сетевых запросов на ней также отмечено событие FCP и продолжительные задачи основного потока рассматривавшиеся в предыдущей статье.
Для полноты картины осталось определить, что такое Quiet Window.
Quiet Window — это временной интервал (5 секунд), на протяжении которого отсутствуют продолжительные задачи и выполняется не более двух сетевых запросов (GET). Отметим его на временной шкале загрузки:
Значением TTI будет время окончания последней продолжительной задачи перед наступлением Quiet Window.
При отсутствии продолжительных задач значение TTI будет равняться значению FCP.
Оценка результатов
При оценке результатов показателя рекомендуется использовать следующие градации:
Способы оптимизации
Основным улучшением, которое может оказать влияние на показатель TTI, является уменьшение количества JS-ресурсов на странице. Соответствующие рекомендации я приводил в предыдущей статье.
Дополнительные улучшения, направленные на увеличение скорости загрузки страницы, такие как минификация, компрессия, предварительные соединения и прелоадинг ресурсов, также положительно скажутся на значении показателя.
Total Blocking Time
Total Blocking Time (TBT) измеряет общее количество времени, в течение которого страница была недоступна для пользовательского ввода.
Принцип работы
Рассмотрим уже знакомую нам временную шкалу загрузки страницы:
Алгоритм работы TBT использует информацию о задачах основного потока, которые выполнялись между событиями FCP и TTI.
Поэтому оставим на шкале только нужную нам информацию:
и обозначим время выполнения каждой задачи:
Показатель TBT оперирует понятием времени блокировки пользовательского ввода.
Из спецификации продолжительных задач и модели производительности RAIL, мы знаем, что любая задача, выполняющаяся больше 50 мс, будет заметным образом блокировать взаимодействие со страницей. Поэтому время, оставшееся после первых 50 мс выполнения задачи, будет являться временем блокировки пользовательского ввода.
Отметим данное время на шкале загрузки:
Значением TBT будет сумма всех периодов блокировки, которая в нашем случае составляет 310 мс (200 + 70 + 40).
TBT является отличным дополнением к показателю TTI. Поскольку последний, в силу эвристики алгоритма (Quiet Window), не способен отобразить разницу между следующими сценариями.
Представим, что на протяжении 10 секунд загрузки приложения в основном потоке браузера возникли три продолжительные задачи длительностью 51 мс:
При таком варианте загрузки значение TTI составит около 9 секунд, а TBT — 3 миллисекунды.
Теперь рассмотрим второй вариант загрузки, который вместо трех продолжительных задач, будет иметь одну длительностью 8 секунд:
При таком сценарии значение TTI будет тем же, однако значение TBT заметно увеличится и составит 7950 миллисекунд.
Оба варианта загрузки имеют одинаковое значение TTI, но с точки зрения пользователя, это абсолютно разные сценарии взаимодействия со страницей. И показатель TBT способен такую разницу отобразить.
Оценка результатов
При оценке результатов показателя рекомендуется использовать следующие градации:
Способы оптимизации
Рекомендации по оптимизации TBT те же, что и для показателя First Input Delay.
Анализ данных
Результат работы синтетического мониторинга отображается в виде двух отчетов Lighthouse. Один отчет генерируется для десктопной версии страницы, другой — для мобильной:
Определить собственные характеристики среды можно через настройки аудита.
Для мониторинга сразу нескольких страниц приложения достаточно перечислить необходимые адреса в файле конфигурации.
Для предварительной аутентификации, необходимо указать путь к файлу auth-скрипта.
Бюджеты производительности
О том, что такое бюджеты производительности, я рассказывал в предыдущей статье.
Для работы с бюджетами в Perfectum Synthetic используется соответствующий раздел конфигурации мониторинга. Можно установить бюджет как для временных, так и для ресурсных показателей проекта.
Для отдельных страниц приложения могут устанавливаться собственные бюджеты. А каждый показатель может иметь бюджет как для десктопной, так и для мобильной версии страницы.
Вся информация о превышении бюджетов будет отображаться в соответствующем разделе отчета производительности:
Заключение
Хорошая производительность проекта не является приложением к экспертизе отдельного человека или целой команды — это всегда результат целенаправленной работы.
И если вы заботитесь не только о скорости разработки, но и о качестве продукта, то внедрение подобных инструментов этому только поспособствует.
Тестирование производительности — Speed Index и время до первого байта
Дата публикации: 2018-06-22
От автора: на прошлой неделе я рассказал вам, как я переместил сайт на новый хостинг, и мой сайт теперь работает на сервере с лучшими спецификациями по более низкой цене. Я также поделился результатами теста времени отклика сервера, и хотя теперь на Siteground оно лучше, чем было на моем старом хостинге, больше ничем я похвастаться не мог. Сегодня я хочу поделиться результатами ряда других тестов, которые я провел. Я делал тестирование производительности каждый раз, когда я вносил изменения как на сам сайт, так и на сервер, на котором он находится.
Меня особенно интересовали время до первого байта (TTFB) и Speed Index, определенный для сайта WebPageTest. В диаграммах водопада, которые сопровождают эти тесты, также было указано кое-что интересное, касающееся HTTP.
Еще раз, что такое время до первого байта (TTFB) и Speed Index?
Напоминаю, что время до первого байта (TTFB) является показателем того, сколько времени требуется от первоначального запроса веб-страницы до того момента, когда будет возвращен первый байт данных. Оно включает время, необходимое для отправки HTTP-запроса, выполнения поиска DNS и создания рукопожатия HTTP между клиентом и сервером. Оно также включает время, необходимое серверу для обработки запроса и отправки первого байта ответа клиенту, отсюда и название — время до первого байта.
Speed Index — это метрика, специфичная для WebPageTest. Она показывает среднее время до отображения видимых частей страницы. Speed Index предназначен для измерения общего опыта и восприятия данной страницы.
Первоначальные результаты тестирования
Поскольку Speed Index доступен только через WebPageTest, и они предлагают результаты для TTFB, вот откуда берутся все эти показатели. WebPageTest запускает три теста для каждого тестируемого места. Цифры в скобках относятся ко второму и третьему прогонам, и, как правило, они должны быть лучше, чем для первого запуска, благодаря кэшированию DNS.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Примечание. Следует отметить, что результаты этих тестов могут меняться изо дня в день. Я запускал их несколько раз при написании этого поста и иногда получал результаты, которые были намного лучше или хуже, чем при запуске в другой день. Я сделал все возможное, чтобы вытащить цифры из того, что показалось мне средним набором результатов.
Вот последний набор результатов, которые я получил для сайта, пока он был на моем старом хостинге. Здесь не отображено, но он получил общий класс C для TTFB.
Вот результаты, которые я получил при первом тесте, сразу после перехода на Siteground. Сайт получил общую оценку F за TTFB.
Вы заметили, что все цифры стали хуже, что не имеет смысла. Учитывая лучшие характеристики нового сервера, мое обновление до PHP 7, использование HTTP / 2 и лучшие результаты для времени ответа сервера, которое я определил на прошлой неделе, я, естественно, предположил, что TTFB и Speed Index также улучшатся, но не тут то было.
Моя первая реакция была такая — нужно дважды проверить это, чтобы убедиться, что старые цифры правильные, а также повторить тесты, которые я только что запустил. Но у меня были правильные старые цифры, и повторение теста привело к очень близким показателям.
Диаграммы водопада приходят на помощь
Я все еще чувствовал, что что-то не так, но чтобы выяснить что, мне может понадобиться рассмотреть внимательнее страницу результатов и изучить диаграммы водопада. Вот первый водопад из Далласа.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Как только я увидел водопад, я заметил кое-что странное. HTML для страницы (синеватая серая полоса в двух верхних строках) загружается дважды. Это заняло минуту или две, но я понял, что это связано с тем, что URL-адрес страницы перенаправляется с http на https. Если вы посмотрите налево, вы увидите, что рядом с первой строкой нет значка блокировки, но значок есть для второй и третьей строк и т. д. С одним единственным исключением.
Я перезапустил тест, используя https, чтобы устранить перенаправление, и вот результирующая диаграмма водопада.
Вы можете видеть, что начальный запрос исчез, и все происходит примерно на 400 мс быстрее, чем раньше. Вот результаты TTFB и Speed Index для тестирования непосредственно https.
Это выглядит лучше, и я ожидаю больше улучшений. Общий класс для времен TTFB теперь составляет B. Еще нужно кое-что сделать, но это определенное улучшение.
Это хорошая новость, но только когда кто-то обращается к сайту с использованием https-адресов. Это означает, что у меня есть работа, которую нужно сделать, чтобы обновить все абсолютные URL-адреса, которые я использовал за эти годы, которые все еще указывают на http-версии страниц.
Также, где это возможно, я, вероятно, должен изменить URL-адреса на других сайтах, которые указываются здесь. Над многими из них у меня мало контроля, но сигнатуры форумов и страницы социальных профилей — это URL-адреса, которые я могу легко изменить. Все ссылки на http будут перенаправляться правильно, но каждый, кто нажимает на них, должен будет подождать половину секунды или дольше для загрузки первой страницы. У меня уже есть задача, поставленная в Things — обновить URL-адреса.
Большая часть трафика на этот сайт идет из поисковых систем, в частности из Google, и я заметил, что Google уже начал отображать https-версию большинства страниц и, вероятно, отображает только https к тому моменту, когда вы читаете это.
Заключение
Помимо результатов Парижа, все тесты показывают, что сайт на Siteground быстрее загружается, чем на серверах моего старого хостинга. Как я упоминал на прошлой неделе, это показывает, что смена веб-хостов может повысить производительность вашего сайта.
Случайно я также увидел, как перенаправление может замедлить работу сайта. В моем случае перенаправления с http на https составило 400 мс или почти половину секунды для. Представьте, сколько времени может быть потеряно путем перенаправления цепочки, когда URL-1 указывает на URL-2, тот на URL-3 и так далее.
Далее в этой серии я хочу поговорить об эффективности динамических сайтов по сравнению со статическими, в частности о потенциальных проблемах производительности с PHP и MySQL, и о том, что вы можете сделать, чтобы сделать оба запуска быстрее.
Автор: Steven Bradley
Редакция: Команда webformyself.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения