Проверка скорости загрузки сайта

Содержание

Что влияет на скорость сайта

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


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

Когда сайт загружается (при первом визите) – происходят такие операции:

  • DNS-запрос названия сайта.
  • Связь с сервером по IP (по протоколу TCP).
  • Установка безопасного соединения при использовании протокола HTTPS (TLS соединение).
  • Запрос по URL-адресу HTML-страницы и ожидание сервера (на основе HTTP-протокола).
  • Загрузка HTML-кода страницы.
  • Анализ HTML-документа на стороне браузера и дальнейшее формирование серии запросов к ресурсам веб-документа.
  • Дальнейшая загрузка и разбор таблиц каскадных стилей (CSS). Загрузка и выполнение JS-кодов.
  • Дальше осуществляется рендеринг отображения страницы и активация Джава-скриптов.
  • Следующий этап – подгрузка имеющихся шрифтов.
  • Отображение картинок и других элементов страниц.
  • Окончание отображения полной страницы, выполнение отстроченных скриптов и кодов.

В вышеописанном процессе некоторые этапы могут проходить одновременно, а иногда меняться местами, но суть при этом не меняется.

Оптимизация сервера связана с четырьмя первыми этапами. А стадии с 5 по 12-ю предполагают оптимизацию клиента. Время каждого этапа является индивидуальным для разных сайтов. Поэтому вам нужно узнать метрики сайта для идентификации основных проблем.

Оптимизация JS

Аналогично файлам CSS, браузер может задерживать время отображения контента страниц сайта из-за загрузки и обработки файлов JS. Большинство рекомендаций повторяются, однако есть дополнения.

Для оптимизации скриптов на сайте необходимо следовать рекомендациям:

Загрузка только используемых файлов JS

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

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

Встраивание JS скриптов в HTML-код

Небольшие скрипты сайта рекомендуется не загружать отдельным серверным запросом, а встроить в код страниц с помощью тега <script>.

Также можно разделить блоки скрипта по методу приоритезации исполнения и влияния на страницы сайта, а также разделить файл на несколько: с асинхронной или последовательной загрузкой. Так, наиболее важные скрипты будут запускаться при загрузке страницы, а остальные, не приоритетные – после отображения содержимого. Это может оптимизировать скорость загрузки до первого отображения контента, что даст пользователю возможность раньше получить содержимое для взаимодействия.

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

Если же для корректной работы страницы или функционала требуется более раннее исполнение скрипта, можно включать его в начало. Например, Google Analytics просит устанавливать код своего счётчика ближе к началу тега <head>, а Яндекс Метрика — ближе к началу <body>.

Отложенная загрузка скриптов

Необходимо отложить загрузку не критичных для работы страницы скриптов с помощью атрибутов defer или async. Использование данных атрибутов схоже, но есть свои особенности. Подробное описание различий и примеры использования представлены на данной странице. 

Не рекомендуется загружать скрипты аналитики (Метрики или GA) с помощью атрибута defer, что подтвердил один из разработчиков Яндекс Метрики:

Минификация файлов JS

Рекомендуется аналогично с CSS использовать минификацию (minify) для скриптов. Google рекомендует использовать технологии: UglifyJS и Closure Compiler, или же загрузить минифицированные файлы из Google PageSpeed Insights.

В настройках Яндекс Метрики можно выгрузить уже готовый код «в одну строку». Это выбирается просто в настройках счётчика:

Также есть онлайн-минификаторы, что позволяют сократить лишнее в коде JS. Достаточно внести текущий код, и забрать уже готовый. Инструмент, которым пользуюсь я: minifier.org.

Использование атрибута rel=»preconnect»

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

Preconnect позволяет браузеру установить соединение прежде, чем HTTP-запрос будет отправлен на сторонний сервер. Preconnect добавляется непосредственно к тегу link как атрибут HTML. Ниже приведён пример возможного использования preconnect:

Кстати, эта доработка подходит для абсолютно любых элементов, которые загружаются со сторонних доменов: скриптов, шрифтов, иконок и стилей CSS.

В практике, для неподготовленных людей объяснить суть доработки у меня получилось вот так:

Оптимизация изображений

Высота и ширина

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

В качестве примера рассмотрим довольно подробную статью от Serpstat про оптимизацию изображений. В статье используются картинки такого вида (скриншот из сервиса webspeedtest.cloudinary.com):

 

Браузер должен загрузить изображение огромного размера (2,7 мегабайта), а также с большей высотой и шириной, с которой оно будет использоваться на самой странице сайта:

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

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

Помимо оптимизации используемой высоты и ширины, нужно обязательно делать сжатие качества изображения для уменьшения их объёма.

Объём, или же размер изображения

Мной заботливо украдена таблица из , где наглядно показана корреляция объёма изображения от его размера (ширины и высоты):

Размер Пиксели Размер файла
100 x 100 10 000 39 КБ
200 x 200 40 000 156 КБ
300 x 300 90 000 351 КБ
500 x 500 250 000 977 КБ
800 x 800 640 000 2500 КБ

Чем больше высота и ширина изображения, тем больше оно будет весить (логично), но масштабы увеличения этого объёма губительны для скорости загрузки.

То есть следует понимать, что для максимальной оптимизации изображения, необходимо:

  1. Уменьшить ширину и высоту
  2. Сжать качество

Для сжатия качества я чаще всего использую сервис compressor.io, однако у него есть существенный недостаток — работает только с одним изображением. Для оптимизации нескольких картинок нужно искать другие сервисы. Тут на помощь можно звать сервис Google PageSpeed Insights, который после анализа любой страницы предлагает скачать архив с уже оптимизированными и сжатыми ресурсами:

Lazy Load

Одна из рекомендаций в моём арсенале — реализация Lazy Load.

Тут буду краток — круто, если это будет реализовано на большом контентном проекте. Однако после внедрения на одном из самых крупных сайтов в моей практике, скорость загрузки не изменилась.

5 ноября Google добавил рекомендации для Lazy Load, а вот тут собрана подробная инструкция по настройке изображений и видео (материал на английском языке).

BASE64 и CSS-спрайты

Для небольших вспомогательных изображений-элементов дизайна рекомендуется рассмотреть кодирование картинок в BASE64 или использование CSS-спрайтов. Это позволит убрать дополнительный запрос к серверу, а изображение будет корректно отображаться на странице (во всех современных браузерах). Таким образом можно «разгрузить» сервер лишними обращениями, что тоже ускорит время загрузки. Как показывает практика, изображения лидируют по количеству обращений к серверу, однако вместе с использованием base64 можно изменить этот стандарт. Ниже показан скриншот из сервиса webpagetest.org. С перекодированием изображений в base64 мне удалось на одном своём сайте сократить количество реквестов до 14, и это очень мало.

Подробнее о цели этой доработки можно прочитать в блоке «Оптимизация количества серверных реквестов».

Инструменты для тонкой оценки

Тонкая оценка времени загрузки сайта, это серьезные инструменты, дающие полную раскладку времени открытия сайта по всем его файлам

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

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

Используя эти сервисы важно понимать, что каждый из них, тестирует сайт от своих дата центров, чаще расположенных в Америке или Европе. Это нужно учитывать

Pindom.com

https://tools.pingdom.com/

Отличный инструмент (язык английский) для анализа скорости загрузки сайта. Тестирование идет от пяти дата центров: 3 в США, 1 в Австралии, 1 в Швеции (Стокгольм).

Результаты тестов показывают раскрытой таблицей с пояснениями для каждого файла. Анализируется, каждый файл сайта, скрипты сайта, с советами по оптимизации.

Кроме точной оценки, сервис показывает качественные результаты проверки сайта в сравнении с другими сайтами, проходящими проверку на этом сервисе.

Webpagetest.org

http://www.webpagetest.org/

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

Отличается данный сервис, количеством точек проверки. Их 50 точек по всему миру, России нет.

Выполнить бесплатный тест скорости сайта можно из 50 мест по всему миру с помощью реальных браузеров (IE и Chrome) и на скорости реального присоединения потребителя. Вы можете запускать простые тесты или выполнять предварительное испытание, включая многоэтапных операций, захват видео, блокирование контента и многое другое. Ваши результаты дадут богатую диагностическую информацию, включая загрузку ресурсов в виде диаграмм Page Speed с проверками оптимизации и предложений по улучшению.

Webpagetest.orgтаблица результатов Webpagetest.org

Gtmetrix.com

https://gtmetrix.com/

Этот сервис (английский язык) позволяет оценить скорость загрузки из дата-центров: Vancouver, Canada, используя для анализа браузер Firefox.

Результаты показываются в виде диаграммных таблиц с расшифровкой данных и советами по оптимизации.

сервис Gtmetrix.com отчет теста

Примечание: Для WordPress есть плагин «GTmetrix for WordPress» (https://ru.wordpress.org/plugins/gtmetrix-for-wordpress/), который позволяет анализировать скорость сайта из административной панели.

Webo.in (Россия)

https://webo.in/

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

Однако, это единственный сервис, данного обзора, который анализирует скорость загрузки сайта по основным регионам России (Москва, Урал, Дальний Восток), а также, Европе и Украины.

Результаты анализа отдает качественной оценкой (как на фото) и расширенной таблицей с результатами по всем файлам сайта.

Webo.in (Россия)

Переезд на новую версию PHP

За всё время своего существования PHP развивался и развивается до сих пор. Начиная с версии 7x сильно оптимизирована скорость работы, что положительно сказывается на всём сайте. Подробное сравнение скорости работы от версии PHP я видел в статье на хабре.

По своим личным наблюдением, обновление версии PHP может быть одним из самых действенных способов значительно ускорить свой сайт. Этот сайт работает на версии PHP 7.3 (самая новая на момент написания статьи).

С обновлением версии PHP нужно предварительно проверить следующее:

  • Сервер поддерживает нужную версию PHP;
  • CMS сайта поддерживает нужную версию PHP;
  • Все плагины, которые используются на сайте корректно работают с новой версией PHP.

Последний пункт может быть самым проблемным, поэтому ему следует уделить внимание. Тщательно проверить работу всех форм и функционала на сайте перед переносом на рабочий домен


Ну и конечно же подготовить бэкапы сайта на всякий случай.

Переезд на PHP 7x это не просто возможность, а необходимость. В некоторых случаях даже требование — некоторые версии PHP ниже 5.3 устарели и могут быть уязвимы. Таких проблем на сайте никому не нужно.

Хвастаюсь:

Операция «Ускорить WordPress»

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

Прежде чем приступить к ускорению своего ресурса, Ник Лерой решил понять, с чем предстоит работать. Так как сайт построен на CMS WordPress, были проанализированы следующие области:

  • хостинг,
  • тема,
  • плагины,
  • изображения,
  • ресурсы.

На основе проверки был составлен список того, что можно улучшить. Затем Ник приступил к внедрению изменений.

Проблема: хостинг и TTFB

Первое, что бросалось в глаза при поверхностном анализе — большое время до получения первого байта после отправки запроса со стороны клиента (Time To First Byte или TTFB) для всех страниц сайта: от 1,5 до 2 секунд. И это было просто время, которое необходимо для первоначального соединения со страницей без ее загрузки.

Помимо этого были и другие проблемы, связанные с хостингом: отсутствие HTTP/2 setup/configured (проблему можно было бы исправить, используя CDN), отсутствие кеширования и т.п. Общий хостинг на Hostgator не способствовал достижению цели увеличения скорости загрузки сайта.

Решение: смена хостинг-провайдера

В качестве альтернативы существующему хостингу были выбраны два провайдера: FlyWheel и Kinsta. Оба провайдера:

В итоге было решено остановиться на хостинге FlyWheel. Этот провайдер был немного дешевле и предоставлял локальные решения для разработки новых сайтов на WordPress.

После некоторых раздумий Ник Лерой решил создать новый сайт NickLeRoy.com. И вот, почему.

Проблема: оптимизация тем, плагинов, изображений, ресурсов

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

Тема WordPress

Тема, которая изначально использовалась на сайте Ника, была куплена у сторонних разработчиков. Часто такие темы поставляются в комплекте с кучей различных функций. Имеют компоновщик страниц, плагины для слайд-шоу, несколько библиотек JavaScript, библиотеки шрифтов и многое другое. Нередко такие темы используют CSS и JavaScript, чтобы удовлетворять потребностям аудитории.

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

Плагины

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

Изображения

Большинство владельцев сайтов находят изображения, обрезают их в графических редакторах и загружают на свои сайты. Так делал и Ник.

Хотя WordPress сжимает загружаемые медиа-файлы, он справляется с этим не очень хорошо. Большинство изображений обычно весит гораздо больше, чем необходимо. А это, в свою очередь, влияет на скорость загрузки страниц.

Ресурсы

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

На сайте NickLeRoy.com использовалось большое количество ресурсов, даже там, где они не были необходимы. Шрифты, javascript-файлы для ненужных функций, CSS для стилей и эффектов и многое другое, от чего можно было бы избавиться.

Решение: создание нового сайта

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

Тогда Ник принял решение перезапустить сайт с нуля на новом хостинге. Для этого была проделана следующая работа:

  • чистая установка WordPress на Local by Flywheel с чистой базой данных и кодом,
  • установка облегченной темы,
  • установка конструктора страниц Elementor, чтобы сайт выглядел так же, как изначально, но загружался быстрее,
  • перестройка всего сайта,
  • оптимизация изображений с помощью imageOptim. Для этого все картинки были загружены в папку wp-content/uploads, пропущены через сервис imageOptim, и выложены обратно на сайт. Суммарное сжатие составило около 90% по сравнению с исходным размером файлов,
  • установка Autoptimize и Async Javascript, что позволило объединить JS и CSS и уменьшить / удалить блокировку рендеринга.

После реализации описанных выше действий сайт был перемещен из локальной среды разработки в промежуточную. Затем специалисты настроили SSL и HTTP/2 и после тестирования обновили DNS.

HTTPS (TLS) и ускорение

Ни для кого не секрет, что поисковые системы и браузеры призывают переводить все сайты не безопасное соединение с использованием TLS (ранее назывался SSL), особенно активно эту идею продвигает Google, который обещает в скором времени помечать обычные сайты как потенциально опасные, потому что они не используют шифрование. Суть технологии состоит в сквозном шифровании всего трафика от пользователя к серверу и обратно. При этом ключ для расшифровки есть только у сервера и клиента. Уже сейчас, Google рассматривает использование HTTPS как положительный сигнал для ранжирования. Со временем, значение этого фактора будет увеличиваться. Кроме того, многие нововведения в веб-стандартах будут работать только с HTTPS (сжатие brotli, service workers, HTTP/2).

Причины предпочтения HTTPS-сайтов просты: только защищённое соединение даёт пользователю уверенность в том, что он зашёл на настоящий сайт и его данные невозможно перехватить. Для владельцев сайтов также очень полезно следующее свойство: в контент сайта с TLS невозможно внести изменения третьим лицам по пути следования трафика (например, провайдеру, который захотел вставить свою рекламу на ваш сайт).

Получается, что мы можем получить множество преимуществ, используя HTTPS. Однако, с преимуществами приходит и проблема со скоростью работы: защищённое соединение добавляет накладные расходы и нагружает клиент и сервер задачами шифрования контента. При неоптимальной настройке сайт может значительно замедлиться.


Первую проблему позволяет решить использование нового протокола HTTP/2 и оптимизированные настройки веб-сервера (дающие как скорость, так и безопасность: OCSP, False Start, Session tickets, Session cache), вторая проблема решается использованием современных шифров, которые не требуют значительных ресурсов.

Мы считаем, что сейчас самое время перейти на HTTPS и реализовать преимущества защищенного TLS-соединения, минимизируя негативное воздействие на скорость работы сайта.

По каким метрикам оценить скорость загрузки сайта

Что такое скорость загрузки страницы? Это время от момента перехода пользователя на сайт до его полной загрузки…Так бы было, если бы сайт загружался в два этапа: запрос – загрузка.

Но в реальности загрузка выглядит так:

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

Именно поэтому для оценки скорости загрузки сайта есть более 15 метрик. Рассмотрим те из них, которые напрямую влияют на пользовательский опыт.

Время загрузки первого байта (TTFB)

Время загрузки первого байта (Time To First Byte, TTFB) – это время от момента отправки запроса на сервер до момента, когда браузер пользователя получает первый байт информации.

Эта метрика складывается из таких составляющих:

  • время, потраченное на отправку запроса на сервер;
  • время, потраченное на обработку и генерирование ответа;
  • время, за которое ответ идет назад к пользователю.

С точки зрения пользователя TTFB – это «белый» экран в процессе ожидания загрузки сайта.

Первая отрисовка контента (FCP)

Первая отрисовка контента (First Contentful Paint, FCP) – это время от момента отправки запроса на сервер до момента, когда браузер отображает первый пиксель контента на экране.

Метрика критически важна, поскольку отображение контента (пусть даже минимальное) – это сигнал для пользователя о том, что сайт загружается. Если показатель FCP высокий, пользователь подумает, что сайт не реагирует, и уйдет.

Время загрузки достаточной части контента (FMP)

Первая значимая отрисовка (First Meaningful Paint, FMP) – это время от момента отправки запроса на сервер до момента, когда пользователь видит достаточно контента для начала работы со страницей.

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

Время окончания работы ЦП (First CPU Idle)

Это период времени от момента отправки запроса на сервер до того момента, когда:

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

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

Первая задержка ввода (FID)

Чем выше FID, тем дольше пользователю приходится ждать реакции сайта (например, кликнул пользователь по «гамбургеру», и ждет, пока развернется меню).

Время загрузки для взаимодействия (TTI)

Время загрузки для взаимодействия (Time to Interaction, TTI) – это время от обращения к странице до момента ее полной готовности к работе.

Простыми словами TTI –  это время, спустя которое пользователь не будет ощущать дискомфорта, связанного с загрузкой страницы (страница не находится в состоянии загрузки, все элементы отображаются, все кнопки работают, все виджеты доступны).

Оценка производительности

PageSpeed Insights выставляет сайту балльную оценку на основе анализа скорости его загрузки с помощью инструмента Lighthouse (отдельно для десктопной и мобильной версии). Данные обновляются ежедневно и охватывают последние 30 дней.

Градация оценок такая:

  • 90-100 баллов — «зеленая» зона. Можно открывать шампанское.
  • 50-89 баллов — «оранжевая» зона. Есть недочеты, но жить можно.
  • 0-49 баллов — «красная» зона. Все плохо.

В идеальном мире сайт должен быть в «зеленой» зоне. Но реальность сурова:

Почти 90% площадок при просмотре с мобильных проходят тест по скорости загрузки с неудовлетворительным результатом. При просмотре с десктопов — около 52%.

Где отображаются показатели и что они означают

Отчет «Время загрузки страниц» > Вкладки «Статистика» и «Наложение данных на карту» > Раздел «Использование сайта»

Отчет «Время загрузки страниц» > Вкладки «Статистика» и «Наложение данных на карту» > Раздел «Технические характеристики»

  • Просмотры страниц: количество просмотров страницы за выбранный диапазон дат.
  • Среднее время загрузки страницы: время (в секундах), которое проходит с момента запуска просмотра (т. е. с нажатия на ссылку) и до отображения всех элементов страницы в браузере.

    Параметр Среднее время загрузки страницы включает в себя два компонента: 1) время сети и сервера; 2) время браузера. В разделе Технические характеристики на вкладке Статистика представлены показатели сети и сервера. Остальное время требуется браузеру для выполнения синтаксического анализа, обработки элементов JavaScript и отображения страницы.

  • Среднее время переадресации: сколько времени занимает переадресация до момента загрузки страницы. Если переадресация не выполняется, значение этого показателя будет равно 0.
  • Среднее время поиска домена: время выполнения запроса DNS для страницы.
  • Среднее время соединения с сервером: сколько времени компьютер пользователя устанавливает соединение с сервером.
  • Среднее время ответа сервера: время обработки сервером запроса пользователя (включая время реакции сети для местоположения пользователя).
  • Среднее время загрузки страницы: время, за которое страница полностью отобразится.

Соотношение этих показателей представлено на следующей диаграмме:

Отчет «Время загрузки страниц» > Вкладки «Статистика» и «Наложение данных на карту» > Раздел «Хронометраж DOM»

  • Просмотры страниц: количество просмотров страницы за выбранный диапазон дат.
  • Сред. время взаимодействия с документом: среднее время (в секундах), которое браузер затрачивает на синтаксический анализ документа (время взаимодействия), включая время ответа сети пользователя. В это время посетитель может взаимодействовать с объектной моделью документа, даже если она загружена не полностью.
  • : время (в секундах), которое браузер затрачивает на выполнение синтаксического анализа, а также отложенных и встроенных скриптов (загруженное содержание документа), включая время ответа сети пользователя. Загрузка таблиц стилей, изображений и вложенных окон может быть не окончена, даже если синтаксический анализ документа завершен и объектная модель документа готова. В этот момент обычно выполняется код JavaScript, например запросы JQuery и т. д.
  • Среднее время загрузки страницы: время (в секундах), которое проходит с момента запуска просмотра (т. е. с нажатия на ссылку) и до отображения всех элементов страницы в браузере.

    Параметр Среднее время загрузки страницы включает в себя два компонента: 1) время сети и сервера; 2) время браузера. В разделе Технические характеристики на вкладке Статистика представлены показатели сети и сервера. Остальное время требуется браузеру для выполнения синтаксического анализа, обработки элементов JavaScript и отображения страницы.

об API Navigation Timing и других параметрах времени (на английском языке)…коперативно-розыскных мероприяти

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

Отчет «Пользовательское время» > Вкладки «Статистика» и «Наложение данных на карту»

Вы сможете просматривать показатели по параметрам «Категория времени», «Переменная времени» и «Ярлык времени», которые можно определить с помощью кода времени.

  • Сред. пользовательское время: сколько времени (в секундах) нужно для выполнения выбранного кода.
  • : количество образцов в выборке.

Отчеты «Время загрузки страниц» и «Пользовательское время» > Вкладка «Распределение»

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

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


С этим читают