Справочник по сервису WebPageTest

Load Time

Общее время загрузки и отображения страницы. По сути это основное мерило времени загрузки страницы. Чем ниже показатель, тем быстрее загружается страница в браузере. К примеру наша страница загружалась почти 3 секунды.

First Byte

Сколько потребовалось времени, чтобы получить первый байт информации от сервера, на котором находится сайт. На данном этапе, иногда, находится основная проблема в скорости загрузки сайта. Например мы запрашиваем страницу, а она около 3-5 секунд "пустая" и лишь спустя это время начинается прогрузка основного контента и графики. В описанном примере проблему стоит искать на самом сервере или исполняемом скрипте - в это время сервер обрабатывает полученный запрос от клиента, потом формирует ответ и отправляет клиенту. О том, что входит в этот показатель я напишу далее.

Start Render

Сколько потребовалось времени, чтобы браузер инициировал визуальное отображение содержимого страницы. Таким образом, в данном примере, с 2,5 секунды мы можем наблюдать в браузере визуальные манипуляции, отрисовку содержимого страницы.

Visually Complete

Сколько потребовалось времени, чтобы браузер завершил визуальную отрисовку содержимого страницы. Сюда входит загрузка всех визуальных элементов и того, что необходимо для их отрисовки.

Speed Index

Самая интересная относительная оценка скорости страницы, в ней стоит помнить, чем меньше число показателя индекса скорости - тем лучше. Если коротко, то это числовой индекс скорости готовности страницы для просмотра пользователем для взаимодействия с контентом (о как, коротко). Понять пользу этой оценки можно сравнивая две версии одной страницы. Например взяли мы одну и ту же страницу (А и Б) и на странице "Б" изменили последовательность загрузки элементов или способ отображения. Страницы А и Б будут иметь одинаковое время полной загрузки страницы, но страница "Б" при ее визуальном просмотре будет "быстрее" отображаться, т.е. последовательность отрисовки будет начинаться раньше и элементы будут появляться последовательно без замедлений и зависания. Так вот, значение скорости индекса (Speed Index) у страницы "Б" будет ниже, тем самым эта страница будет для пользователя восприниматься как более быстрая, хотя скорость полной загрузки и отрисовки страниц А и Б будет фактически одинаковой. Стоит отметить, что не для всех типов сайтов этот показатель будет считаться приоритетным, например если просматривать сайт со статьей или новостью, то загрузка картинок будет занимать второстепенную роль и для того, чтобы пользоваться контентом не обязательно дожидаться полной загрузки страницы а читать статью, например.

First Interactive (beta)

На момент написания данного мини-справочника этот показатель находился на этапе предварительного тестирования (beta). Указывается приблизительное время, необходимое для обеспечения взаимодействия пользователя с контентом. Исходя из показателя "> 2.334s" при загрузке страницы необходимо около 2,5 секунд, чтобы можно было взаимодействовать с содержимым страницы. Данный показатель рассчитывается, если тест страницы запущен под Chrome в настройках перед анализом. Чем меньше секунд, тем меньше ждать загрузки перед использованием страницы человеком.

Result (error code)

Коды ошибок сервера, которые получил клиент от сервера во время проведения теста. Данный показатель не часто появляется в таблице за мою практику, видимо от того, что показать больше нечего в рамках теста (или у Вас все хорошо с сайтом).

Document Complete

В этой группе колонок отображаются показатели измерений для основного содержимого сайта. Образно это время загрузки основного содержимого страницы (в то же время это время не считается загрузкой всех элементов на странице, окончательной загрузкой).

• Time

  Это значение "Load Time"

• Requests

  Количество HTTP-запросов до начала события загрузки (load event). На графике "Waterfall View" это событие показано под маркером "On Load" (светло-сиреневый цвет, если я не дальтоник).

• Bytes In

  Общий объем загружаемых данных для текущего показателя (Document Complete).

Fully Loaded

В этой группе колонок отображаются показатели измерений для полного содержимого сайта. По сути это конечные и полные показатели и означают, что по мнению сервиса WebPagetest загрузка страницы полностью завершена со всеми дополнительными элементами.

• Time

  Суммируется время "Load Time" и время, затраченное на загрузку дополнительных запросов, после наступления события "Document Complete" из предыдущей группы показателей. Вроде как эти показатели и должны считаться конечными и основными. Но всеже первая колонка "Load Time" считается эталоном, что считать скоростью загрузки страницы.

• Requests

  Указывается сумма запросов Requests в группе "Document Complete" и остальных запросов, необходимых для окончательной загрузки страницы.

• Bytes In

  Окончательная сумма загружаемых файлов для окончательного отображения страницы.

• Certificates

  Еще известен как "Certificate Bytes". Общий размер TLS сертификатов, который вернул сервер клиенту.

DOM Interactive

На данном промежутке времени браузер завершил анализ документа и создал модель DOM. После наступления этого события сразу же начинается новое событие - "DOM Content Loaded" (если в документе отсутствует встроенный код JS).

DOM Content Loaded

После завершения предыдущего действия (модели DOM и CSSOM уже готовы) браузер приступает к созданию модели визуализации. На этом этапе создается древо рендеринга (прорисовки) и все готово к визуализации в браузере пользователя. В данном событии изображения и CSS могут быть еще не загружены.

msFirstPaint

Содержимое страницы начинает отображаться пользователю. По сути это означает время начала отрисовки содержимого страницы.

Start Render

Это собственная метрика WebPagetest, которая отслеживает визуальное изменение на загружаемой станице и указывает время, когда появляется первый пиксель для отображения на экране.

On Load

Документ находится в процессе завершения загрузки основных элементов для взаимодействия со страницей. Не иначе как "почти готов, еще чуток...". Время, потраченное на это событие более детально указано в второстепенной таблице, в колонке "loadEvent".

Document Complete

Загрузка и обработка документа завершена и документ готов к использованию.

Но мало знать теоритически, опишу на данном примере какие события происходят на графике, чтобы Вы смогли это применить в своей работе более продуктивно. Для более детальной расшифровки нам поможет вторичная таблица, которая отображается сразу под основной таблицей:

При инициализации загрузки анализируемой страницы в первую очередь возникает событие "DOM Interactive" на 1.624s. После этого в моем случае сразу же началось событие "DOM Content Loaded" продолжительностью 0.400s (с 1.624s по 2.024s). Далее наступает событие "msFirstPaint" на 2.038s, которое начинает прорисовку обработанного содержимого. Минуя этот этап переходим к событию "Start Render" на 2.585s, которое фиксирует визуальное изменение при загрузке страницы. Следущим этапом возникает событие "On Load" продолжительностью 0.018s (с 2.937s по 2.955s). Сразу же после предыдущего события возникает "Document Complete" на 2.954s и документ считается готовым к дальнейшим манипуляциям пользователя, хотя и после него может происходить загрузка/подгрузка файлов.

Отмечу, что событие "DOM Content Loaded" можно (а иногда и нужно) оптимизировать для уменьшения скорости обработки, это самый продолжительный из всех перечисленных.

Основные элементы, которые чаще всего оптимизируют:

• Если на странице есть открытый код JS (< script >< /script >), то в данное событие входит и обработка этого скрипта (если не установлены атрибуты "async и defer").
• Скрипты из внешних источников также будут обрабатываться в этом событии, соответственно это увеличивает время работы. В данном случае будут полезно проанализировать скорость загрузки этих скриптов. Если отключить внешний "медленный" скрипт нет возможности, можно попробовать установить ему атрибуты async или defer.
• Если после "< link type="text/css" />" следует сразу "< script>< /script>", то на данном этапе добаляется время на зарузку и обработку CSS, указанного в href.

dns (DNS Lookup)

При запросе URI адреса происходит запрос к DNS серверу у которого есть информация о запрашиваемом домене и запрос перенаправляется в необходимом направлении. На выполнение данной операции могут влиять кол-во цепей сертификатов или высокая задержка на DNS серверах.

connect (Initial Connection)

Инициализация подключения браузера клиента с сервером запрашиваемого источника.

ssl (SSL Negotiation)

Период времени когда клиент и сервер согласовывают безопасный способ передачи данных. Данный этап не инициализируется если анализируемый сайт или источник используют протокол HTTP, только для протоколов HTTPS и SPDY.

Time to First Byte (TTFB)

Важный этап, анализируя который можно найти и исправить основные проблемы обработки запросов сервером. На рафике указывается промежуток времени, которое необходимо серверу для подготовки ответа на поступивший запрос. Данный этап актуален для запросов каждого ресурса на странице: таблицы стилей, скрипты, изображения и т.д. Если на этом этапе Вы видите аномальную продолжительность, то это сигнал к тому, что нужно оптимизировать исполняемые скрипты на сервере, подключение к БД, скорость запросов и т.п.

Content download

Завершающий этап запроса, когда сервер в ответ на запрос клиента возвращает содержимое ответа. Затраченное время это сумма размера ответа и скорости соединения.

Этапы 4 и 5 в графике "Waterfall View" отображены для каждого типа файлов разной насыщенностью цвета. Например на рисунке выше есть тип "css" окрашенный в 2 оттенка - светло-зеленый и зеленый. Смотря на график "Waterfall View" для файла этого типа можно увидеть такую ситуацию:

На этой картинке светло-зеленая полоса это тот самый TTFB (запрос 4), а зеленая полоса это Content download (запрос 5). Исходя из этого можно сказать, что размер файла не маленький, возможно требующий оптимизации (сжатия, чистки). Если Вы заметили, что файл требует оптимизации, то можно более детально узнать сколкьо времени затрачивается на каждый этап. Для этого нужно кликнуть по строке с файлом в граике "Waterfall View" и откроется модальное окно с детализацией:

Исходя из приведенных данных видно, что запрос и обработка файла "https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" (CDN) заняло 251 ms. Из чего складывается время: DNS Lookup (38 ms) + Initial Connection (34 ms) + SSL Negotiation (55 ms) + Time to First Byte (84 ms) + Content Download (40 ms). Скачиваемый файл "весит" 22.9 KB (Bytes In (downloaded): 22.9 KB). Самым очеидным для оптимизации является сжатие файла, но так как это CDN в моем случае, то это не актуально.

Случаи с большими CSS файлами к сожалению не редкость, так как не все разработчики заботятся о чистоте кода, актуальности стилей и вообще размером заружаемых файлов (сетевой оптимизации в целом). Самые очевидные возможности уменьшения CSS файла:

• удаление неиспользуемых стилей;
• оптимизация стилей путем универсальности классов и DOM вложенности;
• удаление лишних пробелов и переводов строки;
• использование GZip сжатие на уровне сервера;
• создание отдельного CSS файла, который необходим, например, в личном кабинете пользователя. Таким образом не авторизованному пользователю не будут загружаться ненужные стили и это сэкономит немного времени (а иногда и прилично).

В графике загрузки файлов это будет выглядеть так:

В моем случае это выполняется JS счётчика Яндекс.Метрика, который взаимодействует со страницей с момента его загрузки до наступления события "Fully Loaded" (3.403s). С помощью данного маркера хорошо видно, когда работает Java Script на странице. Возможно найдутся случаи, когда активность JS будет излишней, что "даст сигнал" для его оптимизации.

Как и в предыдущем графике (Waterfall View) здесь можно найти знакомые визуальные маркеры по типам файлов и этапах загрузки страницы. К примеру исходя из приведенных данных можно предположить, что данный участок требует оптимизации:

Для выяснения причины такой задержки TTFB (светло-сиреневый маркер) и больших загружаемых данных (сиреневый маркер) мы можем обратиться к графику "Waterfall View" и расследовать какие файлы нужно оптимизировать.

В моем случае данная проблема нашлась без труда, сразу обращаешь внимание на файл изображения:

Строки таблицы окрашены в несколько основных цветов, постоянных цветовв таблице три: светло-зеленый, светло-фиолетовый, светло-серый.

Before Start Render

Цвет: светло-зеленый. Элементы, помеченные данным маркиром выполняются перед началом рендеринга. В графике "Waterfall View" это все загрузки до этапа "Start Render" (зеленая линия).

Before On Load

Цвет: светло-сиреневый. Элементы, помеченные данным маркиром выполняются начиная с этапа "Start Render" до этапа "On Load" (светло-голубая линия).

After On Load

Цвет: светло-серый. Элементы, помеченные данным маркиром выполняются после этапа "On Load" (светло-голубая линия) и длится до полного завершения обработки и загрузки (в основной таблице это "Fully Loaded->Time" на 3.403s).

Redirects

Цвет: светло-желтый. Если загружаемые файлы имеют HTTP-статус 301 или 302. Для поисковой оптимизации эти два кода имеют значение, поэтому иногда можно увидеть неверный редирект, который не предполагалось использовать.

Errors

Цвет: светло-красный. Это хороший сигнал для исправления самых серьезных ошибок, коды 404 и 500. Наличие данного кода ответа для поисковых систем и пользователя имеет важное значение, а для оптимизатора это возможность исправить ненайденные ранее ошибки.

С помощью данной таблице также хорошо смотреть у какого файла самое высокое время получения первого байта информации, колонка "Time to First Byte". Отсортировав от большего к меньшему можно поэтапно проанализировать какой файл, возможно, дольше обрабатывается сервером и исправить код исполняемого скрипта, подключение к БД, большую выборку данных и т.п.

Ниже графиков, в табличном формате, расположена детальная информация по количеству (Requests) и размеру в байтах (Bytes). Особо описывать этот отчет не имеет смысла, по-моему все развернуть и перевода не требует.

Например в моем случае видно, что основной объем загружаемой информации это файлы JS и CSS. Глядя на эти данные стоит проверить объем загружаемых файлов, оптимизировать их объем и по возможно сократить до минимума. По сути поисковым роботам, в основном, будут полезны только MIME типы image и html.