Разное

Время до загрузки dom что это: 4 отчета Яндекс.Метрики, о которых все знают, но которыми не все пользуются

30.06.2021

Содержание

4 отчета Яндекс.Метрики, о которых все знают, но которыми не все пользуются

За технической частью сайта и его корректной работой нужен постоянный контроль. Это как с автомобилем. Не будет своевременного ТО, может и подвести.

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

Отчет «Мониторинг – Время загрузки страниц»

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

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

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

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

Время до загрузки DOM – это время от начала перехода на страницу до полной загрузки страницы со всеми ее компонентами: изображениями, CSS, скриптами и многим другим. Часть таких компонентов пользователь видит, некоторые из них являются служебными, и обычный юзер «пощупать» их не может. Наиболее оптимальная скорость загрузки сайта составляет 1–2 секунды. Увеличение этого времени прямо пропорционально проценту отказа, иными словами, вероятности ухода пользователя с сайта до его полной загрузки. Пороговым значением для высокого процента отказов является время в 15 секунд. Все, что грузится дольше – малоэффективный программный продукт.

Значимую роль, как базовая составляющая отчета, играет и время, потраченное на отработку запросов к DNS в процессе загрузки страницы. Данный показатель отмечен в отчете как «DNS». Кстати, значения с нулевым временем не учитываются по умолчанию.

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

Отчет «Мониторинг – Результаты проверки»

Продолжает начатую выше историю отчет «Время загрузки страниц».

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

В рассматриваемом отчете наиболее частый код ответа сервера «No response received after 10 s». Это означает, что от веб-сервера не получено ответа в течение 10 секунд. Одной из причин этого может быть перегруз сервера и, как следствие, его неспособность быстро обработать запрос. «Internal Server Error» и вовсе может говорить о сбое в работе программного обеспечения сайта. Появление подобных кодов ответа в отчете еще раз сигнализирует о низкой скорости загрузки анализируемого ресурса.

Отчет «Технологии – Браузеры»

Кто-то любит «Яндекс», кто-то пользуется исключительно «Google Chrome». На вкус и цвет, как известно, все карандаши разные. Многие владельцы сайтов любят мерить аудиторию сайта по себе. «Я вот, например, пользуюсь/не пользуюсь Яндексом/Хромом/Мозиллой и т.д.», – слышим мы почти от каждого клиента.

Выводы стоит делать не по своей субъективной оценке, а на основе информации из отчетов. Чаще всего, субъективное мнение далеко от реальности.

Именно поэтому категорией отчетов «Технологии – Браузеры» не стоит пренебрегать. Ведь в разных браузерах (и их версиях) сайт может выглядеть и загружаться совершенно по-разному.

Часто некорректное отображение сайта влияет на число обращений и показатели вовлеченности:

Как видите, в некоторых браузерах показатели вовлеченности заметно проигрывают. Почему? Откройте, протестируйте, посмотрите Вебвизор, что именно не так. В нашей практике был случай: в нескольких браузерах сайт клиента не вмещал на экране кнопку «Оставить заявку» в каталоге. Пользователи уходили с сайта, так и не находя возможности сделать заказ из каталога. А наш клиент ежедневно терял долю возможных обращений. Диагностировать ошибку, допущенную разработчиками сайта, помог именно отчет по браузерам.

Отчет «Технологии – Устройства»

Около 60% пользователей ищут нужную информацию в интернете через мобильные гаджеты – смартфон или планшет. Оперативно узнать, с каких именно устройств посетители заходят на страницы сайта, позволяет отчет «Технологии – Устройства». Благодаря ему можно вовремя диагностировать и устранить проблему некорректного отображения или функционирования сайта с мобильных устройств. Например, если показатель отказов с мобильных и планшетов выше, чем с десктопа – с мобильной версией вашего сайта явно что-то не так, стоит протестировать, что заставляет пользователей уходить со страницы? Ведь чем эффективнее сайт будет работать с каждого типа устройств, тем выше будет отдача.

***

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

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

Время загрузки страницы сайта — какое считать оптимальным и как его достичь

Performance Marketing основывается на четко и однозначно измеряемых параметрах Мы находим оптимальные решения в любой отрасли! Работаем над правильными KPI

Получи нашу книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Подпишись на рассылку и получи книгу в подарок!


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


Больше видео на нашем канале — изучайте интернет-маркетинг с SEMANTICA

Основные понятия

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

Среднее время загрузки страницы сайта варьируется от улучшенного времени загрузки (1-1,5 секунды) до оптимального в 2 секунды. Замедление скорости загрузки страницы даже на 200 милисекунд приводит к потере тридцати шести процентов переходов за шесть недель. Если же время загрузки замедлится еще вдвое (400 мс) то процент переходов упадет на семьдесят шесть процентов.

Медленными считаются сайты на загрузку которых тратится от 3 секунд и более.

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

Измерение скорости работы сайта

Один из самых животрепещущих вопросов, связанных с измерением скорости сайта – это что измерять? Ниже представлены основные важные пункты важный для того, чтобы проверить время загрузки страницы сайта:

  • Загрузка основных элементов страницы.
  • Полная загрузка сайта.
  • TTFB – time to first bite. Это время, за которое страницы выдает первые результаты загрузка.
  • Начало рендеринга (измерения покажет время от конца «белого экрана» до прорисовки элементов страницы).

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

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

  • Использовать панель разработчика в браузере.
  • Запустить аудит сайта (через вкладку Audits. Используя плагин, мы получаем скорость работы сайта на мобильных устройствах).
  • Использовать веб-сервис (например WebPagetest. Сервис загрузит сайт в браузере и даст отчет по этапам и метрикам).
  • Воспользоваться сервисом Google PageSpeed Insights (не дает детального отчета, но поможет быстро сформировать основные моменты из-за которых сайт «тормозит»).

Эти способы связаны с измерением клиентской скорости. Когда измеряется серверная скорость, чаще всего это делает веб-мастер и для измерения скорости он проверяет:

  • Ресурсы хостинга,
  • Сервисы базы данных,
  • Влияние CMS и программного кода,
  • Кэширование.

Оптимизация скорости работы сайта

Оптимизация скорости загрузки страницы это одна из самых важных глав для успешности вашего сайта.

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

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

Клиентская

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

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

Есть несколько популярных примеров.
Самый известный сервис для проверки скорости это Google PageSpeed Insights. Он довольно точно и наиболее широко укажет что именно в работе вашего сайта нужно поправить для его ускорения.

https://developers.google.com/speed/pagespeed/insights/?hl=ru

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

https://tools.pingdom.com/

  1. Провести анализ основного контента сайта. Сжимание размера картинок и оптимизируя дизайн можно сильно ускорить время загрузки сайта.
  2. Сократить количество рекламы.
    Да, безусловно, количество рекламы напрямую влияет на вашу прибыль. Но не стоит забывать, что ее излишнее количество, увеличивая оптимальное время загрузки сайта уведет от вас потенциального пользователя, а значит повлияет на целевую аудиторию. Реклама влияет как на скорость загрузки, так и на поведенческий фактор. Избыток рекламных баннеров отпугнет потенциального посетителя.
  3. Проанализировать ошибки в коде (валидация).
  4. Воспользоваться хорошим хостингом.

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

Серверная

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

  1. Сбрасывание кэша.
    Самый простой и популярный способ ускорения работы сервера. Этот способ связан с тем, что не все элементы страницы легко кэшируются, и если вопрос замедления можно решить этим способом, то он наиболее эффективен.
  2. Улучшение сервиса базы данных.
    Один из мощных способов, с помощью которого, можно получить действительно сильное ускорение.
  3. Оптимизация «движка» сайта.
    В частности, оценить все дополнительные модули, плагины, которые работают не только с серверной стороны, но и со стороны создателей страницы и сайта.
  4. Вынос статического контента.
    Перенос статического контента в память и снятие этой задачи с сервера.

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

Какое среднее время загрузки страницы в 2020 году

От автора: по прошествии еще одного года настало время подвести итоги того, как производительность сайта сравнивается со средним временем загрузки страницы в 2020 году. Мы рассмотрим средние значения, чтобы помочь вам понять, является ли ваш сайт более быстрым чем среднестатистический.

Как вы знаете, существует множество показателей, определяющих скорость страницы сайта, и мы не можем рассматривать только один из них, чтобы определить, насколько эффективен сайт. Анализируя данные Backlinko.com и рассматривая их статью о скорости страницы, написанную Брайаном Дином, мы постараемся ответить на следующие вопросы:

Какого размера должен быть сайт?

Каково должно быть среднее время загрузки страницы в 2020 году?

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Какое количество ресурсов я должен загружать?

Каково должно быть среднее время до первого байта (задержка сервера)?

Какое влияние оказывает возросшее использование мобильных устройств?

Мобильные устройства остаются главным приоритетом

В 2017 году использование мобильного интернета превзошло использование настольных компьютеров. Спустя 3 года ситуация по прежнему остается той же — 53% посещений веб-сайтов приходится на мобильные устройства. Прогнозы на следующие несколько лет предполагают увеличение доли мобильных устройств, поскольку они становятся все более мощными и распространенными.

К сожалению, данные от Backlinko рисуют мрачную картину, когда речь заходит о просмотрах мобильного интернета. Они обнаружили, что в среднем загрузка веб-страницы на мобильных устройствах занимает на 87% больше времени, чем на настольных компьютерах. Кроме того, средне время до первого байта (TTFB) на настольных компьютерах составляет 1,28 секунды и 2,5 секунды на мобильном устройстве. Наконец, они обнаружили, что среднее время до полной загрузки веб-страницы составляет 10 секунд на настольных компьютерах и 27 секунд на смартфонах.

Очевидно, что ключевая фраза здесь «полная загрузка». Много времени уходит на обработку скриптов под капотом, программного обеспечения для отслеживания, рекламы и т. д. Это вещи, которые загружаются в фоновом режиме, даже если вы можете взаимодействовать со страницей задолго до этого. Так в чем же проблема, если пользователь этого не замечает? Это все еще разряжает батарею устройства посетителя и расходует мегабайты трафика. В целом, это огромная утечка ресурсов.

Каково будет среднее время загрузки страницы в 2020 году?

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

В исследовании средний показатель индекса скорости составляет 4,7 секунды на настольных компьютерах и 11,4 секунды на смартфонах. Рекомендации Google — индекс скорости должен быть менее 3 секунд. Сколько на вашем сайте?

Каков средний размер веб-страницы?

Важность этого показателя нельзя переоценить. Из более чем 5 миллионов проанализированных веб-сайтов общий размер страницы оказался фактором номер 1 в скорости загрузки.

Согласно HTTPArcive и их отчету о размере страниц, на момент написания статьи средний размер веб-сайта составляет 1,966 МБ для настольных компьютеров и 1,777 МБ для мобильных устройств. Рекомендация Google — менее 0,5 Мб.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Каково среднее количество ресурсов?

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

Текущее среднее количество запросов для настольных компьютеров — 75, в то время как для мобильных устройств выполняется в среднем 70 запросов (согласно отчету о размерах страниц). На самом деле эти цифры снизились примерно на 8% по сравнению с прошлым годом, поэтому в этой области произошли значительные улучшения. Тем не менее, рекомендация Google заключается в том, чтобы количество запросов не превышало 50, поэтому работа еще не завершена.

Какова средняя задержка сервера?

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

В ходе анализа средняя скорость TTFB составила 1,28 секунды на настольных компьютерах и 2,59 секунды на мобильных устройствах. Рекомендация Google заключается в достижении времени менее 1,3 секунды. Это на самом деле выполняется в среднем для настольных компьютеров, но для мобильных устройств все еще есть необходимость в оптимизации.

Как вы тестируете свой сайт на соответствие лучшим практикам?

Теперь, когда мы знаем, каков должен быть среднестатистический сайт, пришло время протестировать свой собственный. Если у вас показатели меньше средних — отлично! Тем не менее, мы действительно хотим стремиться к тому, чтобы соответствовать критериям, которые Google устанавливает в качестве рекомендаций. Это беспроигрышный вариант, поскольку он радует ваших пользователей и гарантирует, что Google положительно оценит вас. В конце концов, вы определенно не хотите быть внизу списка и получить их знак стыда!

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

WebPageTest: отраслевой стандарт для измерения производительности сайта — результаты собираются в реальных браузерах, работающих под управлением распространенных операционных систем.

Google PageSpeed Insights: дает практические советы о том, как оптимизировать скорость веб-страницы.

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

MachMetrics: профессиональный мониторинг скорости сайта — расписание тестов для URL-адресов из различных регионов и устройств и суммирование результатов.

SpeedCurve: мониторинг производительности интерфейса

Убедитесь, что вы лучше, чем отраслевой стандарт по времени загрузки страниц в 2020 году

Как видно из первого графика, каждая секунда имеет огромное значение для показателя отказов. Если вы знаете, что у вас показатели лучше среднестатистического сайта, это огромное преимущество. Даже лучше, если вы соответствуете стандартами Google.

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

Источник: //www.machmetrics.com

Редакция: Команда webformyself.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

VUE JS. Быстрый старт

Создание веб-приложения на VUE JS

Смотреть

метрики, инструменты и способы повышения

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

Из статьи вы узнаете:

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

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

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

Есть масса исследований, которые это подтверждают. Например, в аналитическом отчете Akamai указано, что если страница открывается более 3-х секунд, то 53 % пользователей ее покинут, не дождавшись загрузки. Выглядит это так: пользователь перешел по URL, подгрузились элементы из раздела <head>, счетчик зафиксировал переход, но контент не загрузился, и человек ушел. В итоге трафика нет, конверсии нет, и в пассиве сайта лишь очередной отказ.

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

1 Последовательность загрузки страницы

Упрощенно этапы загрузки страницы выглядят так:

  1. Ввод адреса страницы в браузере и обработка DNS-запроса к серверу, на котором размещается площадка.
  2. Обработка HTTP-переадресаций при загрузке страницы.
  3. Подключение браузера к серверу.
  4. Ответ сервера. Данные передаются от HTTP-сервера к браузеру.
  5. Обработка загруженной информации браузером и отрисовка элементов.
  6. Полная загрузка страницы (со всеми скриптами, картинками, стилями и т. д.).

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

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

2 Скорость загрузки страницы: основные метрики

Раньше для оценки производительности сайта учитывались 2 события:

  • DOM Content Loaded (DCL). Время, когда страница загрузилась, а скрипты только начали выполняться.
  • Loaded. Время, когда страница полностью загружена и с ней можно взаимодействовать.

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

Первая отрисовка (FP). Это время, спустя которое пользователь видит белую пустую страницу в браузере впервые. Любое первоначальное изменение на экране считается первой отрисовкой.

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

Это очень важный показатель, по которому пользователь понимает, что сайт начал загрузку. Нормативные значения такие (согласно Google):

  • высокая скорость — менее 1 с;
  • средняя скорость — от 1 до 2,5 с;
  • низкая скорость — более 2,5 с.

Первая значимая отрисовка (FMP). Время, спустя которое весь основной контент появляется на экране. Таким контентом считается:

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

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

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

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

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

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

Нормативные значения:

  • высокая скорость — менее 50 мс;
  • средняя скорость — от 50 до 250 мс;
  • низкая скорость — более 250 мс.

Индекс скорости (SI). Показывает, насколько быстро страница заполняется видимым контентом. Чем меньше значение этого индекса, тем лучше.

Визуально готово (VR). Эта метрика в анализе производительности страницы показывает время, когда страница на 100 % загружена и готова к использованию.

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

3 Инструменты для проверки скорости загрузки страницы

Оценить скорость загрузки можно с помощью специальных сервисов.

Google PageSpeed Insights

Самый популярный инструмент измерения и оптимизации времени загрузки страницы — Google PageSpeed Insights. В 2018 году сервис обновили — теперь в нем используются данные Lighthouse (на этом расширении для Google Chrome мы еще остановимся).

Инструмент находится в свободном доступе. Для работы достаточно ввести URL проверяемой страницы и нажать кнопку «Анализировать». Данные выдаются в разрезе десктопной и мобильной версии.

Страница в сервисе оценивается по 6 метрикам. Эти данные сравниваются с показателями лучших сайтов и переводятся в баллы.

Шкала выглядит так:

  • низкая скорость (красный) — 0-49;
  • средняя (оранжевый) — 50-89;
  • высокая (зеленый) — 90-100.

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

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

Lighthouse

Бесплатное расширение Lighthouse для браузера Google Chrome используют для выявления ошибок на сайте. С помощью этого инструмента можно провести не только анализ скорости загрузки страницы, но и юзабилити сайта, и SEO-оптимизации.

После установки расширения значок Lighthouse появляется в верхнем углу браузера справа. Чтобы провести аудит, надо открыть интересующую страницу в браузере и нажать кнопку «Generate report».

Отчет открывается в новом окне браузера и выглядит так:

Страница оценивается по пяти направлениям:

  • Performance. Оценивается скорость загрузки страницы. Именно эти данные подтягиваются в сервис PageSpeed Insights.
  • Accessibility. Показывает уровень доступности страницы для пользователей с разными потребностями. При расчете анализируется ряд метрик, учитывающих контрастность цветов, адаптацию сайта под приложения для чтения с экрана и т. д.
  • Best Practices. Показывает, насколько сайт соответствует лучшим мировым практикам. Среди пунктов аудита, например, наличие HTTPS, HTTP/2, правильное соотношение сторон изображений и т. п.
  • SEO. Показывает уровень оптимизации страницы под требования поиска Google.
  • PWA. Показатель оценивает соответствие страницы стандартам Progressive Web Ap.

Lighthouse выдает развернутый отчет по каждому направлению и рекомендации по улучшению.

Web Page Test

Еще один удобный сервис для измерения скорости сайта — Web Page Test. Для высокой точности результатов он проводит три проверки подряд и предлагает сравнить результаты каждой из них. В настройках можно выбрать устройство и местоположение сервера.

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

4 Как повысить скорость загрузки сайта

Есть много подходов, позволяющих повысить скорость загрузки страниц. Остановимся на тех, которые сможет самостоятельно внедрить каждый, кто обладает базовыми знаниями HTML, CSS и JavaScript. Практика показывает, что описанных способов вполне достаточно для перехода в «оранжевую» и даже «зеленую» зону PageSpeed Insights.

Переход на PHP 7.2

Переход на PHP 7.2 позволяет не только увеличить скорость загрузки страниц. Если у вас сайт на WordPress, это необходимая мера для обеспечения безопасности, ведь версия 7.0 лишена поддержки безопасности, 7.1 — активной поддержки, 5.6 — любой поддержки.

Перейти на PHP 7.2 просто. Делается это в панели управления хостингом. Например, в панели Plesk необходимо зайти в раздел «Настройки PHP», выбрать в выпадающем списке версию PHP и нажать «Применить».

Серверное кэширование

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

Есть много разных способов настроить кэширование, но самый простой и эффективный — с помощью файла .htacсess. Хранится он в корневой папке сайта. Откройте его и вставьте эти строки:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 6 months"
ExpiresByType image/jpeg "access plus 6 months"
ExpiresByType image/gif "access plus 6 months"
ExpiresByType image/png "access plus 6 months"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 3 months"
ExpiresDefault "access plus 1 month"
</IfModule>

Обратите внимание!

Работа с файлом .htacсess требует аккуратности, поскольку малейшая ошибка может привести к поломке сайта. При отсутствии опыта рекомендуем обратиться к специалистам.

Сроки кэширования отдельных типов данных можете корректировать. Главное, чтобы они были не слишком короткими, иначе метод перестанет быть эффективным.

Уменьшение количества плагинов

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

По его результатам обновите устаревшие и отключите неиспользуемые плагины. Кроме того, по возможности реализуйте функции плагинов с помощью PHP или команд в .htacсess (например, для серверного кэширования используйте не плагин, а команды в .htaccess).

Правильное расположение JavaScript и CSS

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

CSS, наоборот, необходимо располагать в самом верху. Так сразу после начала загрузки страницы начнут отображаться стили, и будет больше шансов удержать пользователя. Более этого, критически важные стили (например, отвечающие за отрисовку шапки сайта и основного контента) Google рекомендует прописывать в разделе <head> с помощью тега <style>. Остальные же стили — подгружать из файла (style.css и др.).

Оптимизация шрифтов

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

Сжатие изображений

Редкий сайт не имеет изображений. Проблема в том, что они много весят, особенно если речь идет о фотографиях в высоком разрешении. При этом пользователям зачастую не нужна высочайшая детализация фото, особенно если они заходят на сайт с мобильных.Content-Encoding:.*gzip.* </IfModule>

Проверить, настроено ли сжатие на вашем сайте, можно с помощью сервиса Ciox.

Сокращение размера кода CSS и JavaScript

Коды CSS и JavaScript довольно громоздкие. Чтобы сделать их меньше, необходимо удалить лишние символы — пробелы и комментарии. Плагины лучше не использовать. Для сжатия CSS воспользуйтесь сервисом CSS Compressor. Скопируйте код из файла style.css или другого и вставьте его в поле «CSS Source Code Input». Затем выберите уровень сжатия (Compression Level) и нажмите «Compress». Скопируйте полученный код и замените им старый.

Для сжатия JavaScript есть аналогичный сервис — JavaScript Compressor.

Заключение

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

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

Хотите больше узнать о SEO-продвижении? Запишитесь на интенсивные курсы от обучающего центра Cybermarketing. За 8 занятий вы пройдете путь от основ SEO до внутренней и внешней оптимизации, а также аналитики SEO.

Время загрузки сайта в SEO 2021 — главный параметр ранжирования

Содержание:

Влияет ли время загрузки страницы сайта на его позиции

Как вы считаете, если использовать все возможные секреты продвижения, но забыть оптимизировать время загрузки сайта, он сможет попасть в ТОПы выдач поисковиков?

Да? Серьезно? Не верите в важность этого показателя?

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

Почему время загрузки сайта оказывает влияние на выдачу

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

Чем больше медленных сайтов попадает в ТОП выдачи конкретной поисковой системы, тем реже пользователи будут ее использовать.

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

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

Немного теории и статистики в подтверждение

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

Оптимальное время загрузки сайта (норма) – около 2-х секунд.

Когда скорость загрузки веб-ресурса уменьшается всего на 200 мс, это приводит к сокращению количества переходов на 36% в течение 6 недель.

И аналогично при увеличении задержки на 400 мс переходы сокращаются на 76% за тот же промежуток времени.

Показатель, при котором на выдачу не влияет время загрузки сайта (норма) – не более 1% пострадавших пользователей.

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

Google рекомендует работать над улучшением скорости работы, если она меньше, чем у 95% веб-ресурсов.

Способы ускорения загрузки сайта

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

  1.  PageSpeed Insights в сервисе для вебмастеров от Google. В его функции входит проверка времени загрузки сайта и предоставление рекомендаций по улучшению этого показателя.


     

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


     

  3.  Отсрочка загрузки также является одним из вариантов, который может значительно повлиять на время загрузки страницы сайта.
    Реализуется путем откладывания загрузки не очень важных или не имеющих особого значения элементов. Чаще всего это блоки, располагающиеся в конце страницы, к которым посетитель добирается позже либо не добирается вообще.
     
  4.  Валидация сайта поможет выявить ошибки в коде, устранение которых может повлиять на ускорение загрузки.
     
  5.  Оптимизировать дизайн сайта и графический контент. Сжимая отдельные элементы дизайна и картинки, публикуемые на страничках, можно значительно ускорить время загрузки сайта.
     
  6.  Сократить количество рекламных баннеров на страницах веб-ресурса.
     
  7.  Перенести веб-ресурс на надежный хостинг с более производительными серверами.

И напоследок…

Расскажем, что одному известному сайту дало ускорение времени загрузки страниц на 3 секунды. В результате:

  •  количество просмотров страничек увеличилось на 25%;
  •  конверсия возросла на 7–12 %;
  •  нагрузка снизилась на 50%.

 

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

А как быстро загружаются страницы вашего сайта?

За сколько секунд должен загружаться веб-сайт в 2020, что такое «быстро», и причем тут зеркала в лифтах?

Казалось бы, померил время от HTTP-запроса браузера до загрузки последнего байта страницы — и готово. Not so fast! У Google, например, целых 6 метрик для оценки скорости работы сайта. Под катом НЕ будет перевода документации Lighthouse и НЕ будет советов по написанию SEO текстов, зато вы узнаете:


  • о хронологии изменения политики ранжирования сайтов Google
  • об объективных оценках субъективного восприятия времени загрузки сайта
  • насколько интернет остается медленным в 2020
  • как время загрузки влияет на посещаемость сайта, а сам процесс на конверсию
  • смешная картинка в конце


(не) Google’ом единым

Медленно, но верно своей железной рукой Google устанавливает новые стандарты для веб-страниц. Мотивация проста – Google выгодно показывать в выдаче быстрые, удобные, безопасные и содержательные сайты. Если пользователь быстро нашел, что ему нужно – поисковик справился со своей задачей. Получается, как ни посмотри, user в выигрыше? – да. А вот воплощать в жизнь стандарты, задаваемые Google, конечно же, приходится разработчикам и создателям контента.


Скорость

История со скоростью загрузки страниц началась еще в далеком 2009 году, когда Google выступила с инициативой “Let’s make the web faster”. В ее основе лежало видение сооснователя компании Ларри Пейджа: «Переход от одной веб-страницы к другой должен быть таким же быстрым, как перелистывание глянцевого журнала». За этим последовал выпуск набора инструментов для оптимизации сайта PageSpeed tools и функции предварительной загрузки первых результатов поиска в Chrome. В 2010 Google объявила, что при ранжировании будет учитывать скорость загрузки страниц в десктоп версии. Но на релизе это повлияло только на 1% от всех страниц. Google открыто заявила, что скорость — не ключевой фактор, и специалисты по SEO продолжили спокойно сочинять тексты и добавлять ссылки. И на этом все на следующие 7 лет.


“Browsing the web should be as fast as turning the pages of a magazine”
Larry Page

Мобильные версии сайтов

Сейчас в фокусе мобильные версии сайтов, их контент и скорость работы. И это не удивительно: в 2017 доля контента, потребляемого с мобильных устройств, превысила 50%.

В 2017 году Google выпустила свой хрестоматийный отчет «Mobile page speed new industry benchmarks». В 2018 году вышла его обновленная версия. Мы поговорим подробнее о них чуть позже. Летом 2018 вышел «Speed update», который внес изменения в алгоритм индексирования страниц. C июля 2018 года Google учитывает скорость работы мобильных версий страниц при ранжировании и наказывает медленные.

Ровно через год — 1 июля 2019 года — Google начала индексировать все новые страницы с приоритетом мобильного контента. Такое индексирование означает, что рейтинг страниц зависит главным образом от их мобильной версии. Буквально на днях Google анонсировала, что с 1 сентября 2020 года все страницы будут индексироваться таким образом. Пока же Google переводит на мобильное индексирование страницы, которые считает готовыми к этому. Таких веб-страниц порядка 70%. Получается, с осени этого года, помимо прямой зависимости ранжирования от скорости работы мобильных страниц вашего сайта, добавляется косвенная. Чем быстрее работает сайт — тем больше страниц Googlebot для смартфонов успеет проиндексировать (на каждом ресурсе бот проводит ограниченное время).


Безопасность

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

В 2014 Google начала поощрять сайты, использующие SSL, поднимая их в выдаче.

С января 2017 Chrome сообщает, что веб-страница “Not secure”, если она содержит поля для ввода паролей и не использует SSL.

С июля 2018 года небезопасными считаются любые страницы, не использующие SSL.

В 2019 Яндекс тоже начал «штрафовать» сайты без SSL шифрования.

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

Если с использованием TLS все более-менее понятно (есть — хорошо, нет — плохо), то со скоростью загрузки страниц все не так очевидно. Что такое быстро? На что влияет скорость? Какие показатели в среднем по сети?


Измеряем время до…

Итак, берем страницу, измеряем время с отправки HTTP-запроса браузером клиента до момента, когда последний байт страницы загружен — готово! Not so fast… Time to Fully Loaded (TTFL), именно его мы только что померили, не очень-то отражает реальное положение дел. TTFL не достаточно, чтобы понять насколько сайт быстрый. Еще одна популярная характеристика оценки скорость работы сайта — Time to First Byte (TTFB). Это время между отправкой HTTP-запроса пользователя и получением первого байта информации запрашиваемой страницы. Она отражает «отзывчивость» сервера, на котором находится сайт. Чтобы проверить TTFB, можно использовать отладчик браузера или консоль. В Chrome и Firefox нажмите комбинацию «Ctrl+Shift+I». Выберите вкладку «Сеть». После этого перезагрузите страницу, отфильтруйте ресурсы по типу HTML и найдите document файл. Поле «Ождиание» и есть TTFB.

Конечно, чем эти промежутки времени меньше — тем лучше, но для пользователя все эти TTFB и время до получения последнего байта мало что значат. Никто не заходит на страницу с открытым отладчиком и не смотрит, когда пришел первый байт с aliexpress.com. (Ну, может быть вы сейчас зашли, ради интереса). В первую очередь user смотрит на окно браузера с интересующим его сайтом. Можно оценивать скорость работы веб-страницы, опираясь на время отображения ее элементов.

Time to First Contentful Paint (TTFCP), если коротко, — время до отображения первого элемента на экране устройства пользователя. Цветной фон, картинки, svg файлы, текст — все, за исключением встраиваемых элементов.

Time to Visually Complete (TTVC) — это время в секундах, которое требуется, чтобы в окне браузера посетителя страница выглядела полностью загруженной. Это значит, что если пользователь никак не будет взаимодействовать со страницей, в том числе скроллить ее, то вид страницы уже никак не изменится.

Ну, теперь то все? — нет. Люди не заходят на страницу с секундомером в руках, чтобы засечь, когда на экране их телефона появилось хоть что-то. Главное для пользователя — восприятие времени загрузки или perceived loading duration. То, сколько он скучал, прежде чем начать пользоваться страницей.


Объективная оценка субъективного восприятия

Чувство восприятия времени user’а можно «обмануть», скрасив мучительные секунды ожидания. Вот любопытное исследование на эту тему — «Faster Progress Bars: Manipulating Perceived Duration with Visual Augmentations». Исследователи из Питтсбурга выяснили, что пульсирующая полоса progress bar’а кажется на 11% быстрее, чем обычная монохромная. Может, это одна из причин сложившегося предубеждения: «мак работает быстрее»?

Вот еще интересный пример манипуляции, но уже с переносом зоны ответственности. Разработчики приложения Facebook для iOS провели A/B тестирование и сравнили реакцию пользователей на кастомный индикатор загрузки и стандартный. Выяснилось, если показывать стандартный спиннер, большинство пользователей будут считать медленным не приложение, а свой телефон. Вот так можно повысить лояльность пользователей, просто заменив анимацию.

Теперь пример уже не из мира IT. Большинство не самых современных лифтов двигаются довольно медленно. Ускорение, с которым может двигаться лифт, ограничено не только характеристиками установленного оборудования, но и из соображений безопасности и комфорта. Людей нельзя подвергать сильным перегрузкам. Одна из функций зеркал в лифте — занять пассажиров на время поездки. По этой же причине в некоторых лифтах включают музыку и делают кабинки прозрачными. Конечно, зеркала выполняют и более прикладную функцию — людям на инвалидной коляске проще и безопаснее выезжать из такого лифта.

И как раз тут на сцену выходит Speed Index и First Meaningful Paint. Speed Index — довольно «хитрая» характеристика. Как мы уже убедились, если пользователя развлекать — ожидание не будет для него такой большой пыткой, и время загрузки пройдет «быстрее». Speed Index во многом отражает ощущения пользователя. Итак, пусть у нас есть две одинаковые веб-страницы с TTVC 12 секунд. Страница «А» отображает большую часть контента за 1 секунду, а «B» — только под конец TTVC.

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

Speed Index будет определятся площадью над этим графиком (учитывая, что мы ограничим его сверху ста процентами). Для самых любопытных оставил формулу для расчета.

Чем Speed Index ниже — тем лучше. Получается, это совсем никакая не скорость, а скорее время, ну а по большому счету и не время вовсе. Вот такая семантическая путаница. Итак, если Time to Visually Complete отражает время до результата — полной отрисовки контента страницы в браузере — то Speed Index учитывает еще и путь, по которому мы добираемся до этого результата.

First Meaningful Paint (FMP) показывает, когда на мониторе или экране телефона пользователя уже можно что-то почитать или посмотреть — начать потреблять контент. Если кратко, ее определяют как время за которое с отображаемой страницей происходят наибольшие перемены. Подробнее можно прочитать тут. FMP для страниц «А» и «B» будут выглядеть вот так:

Наконец, давайте разместим все рассмотренные метрики (события) на временной шкале.


Как время загрузки влияет на поведение посетителей?

Какие количественные данные использовать, если мы хотим оценить реакцию посетителей на скорость загрузки страниц? Для этого хорошо подходят величины, традиционно используемые в SEO для оценки UX:


  • показатель отказов (bounce rate) — отношение числа посетителей покинувших сайт со страницы входа к их общему числу.
  • время на сайте (time per visit) — время, которое посетитель провел на сайте, прежде чем уйти
  • число страниц за посещение (pageview per visit) — сколько страниц посетитель просмотрел, прежде чем уйти
    Эти метрики зависят от многих факторов, но скорость работы веб-страницы — один из важнейших. Давайте смотреть, что нам сообщают исследования.

Что говорят сами пользователи

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

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

Уже после трех секунд ожидания половина посетителей покинут страницу, и это не удивительно. У большинства веб-страниц нет progress bar’а. User не знает, сколько ему еще осталось ждать — секунду, две или десять. Он перейдет на другую вкладку, нажмет «back to previous page» или вообще закроет браузер и откроет Instagram. Учитывая, что attention span зумеров сильно сократился из-за Instagram, TikTok и прочих Twitter’ов, страницы должны загружаться молниеносно.

79% пользователей повторно не вернутся за покупкой на медленно работающий сайт.

66% пользователей считают скорость работы сайта важной частью имиджа компании.
Более того, по разным оценкам от 12% до 44% пользователей поделятся своим негативным опытом и предостерегут знакомых от использования медленного ресурса. Как заметил Дуглас Адамс в 5 части своего культового цикла «Автостопом по галактике»: «Ничто не движется со скоростью большей, чем скорость света, за исключением, может быть, плохих новостей, которые подчиняются своим, особенным законам»


«Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws»
Mostly Harmless, Douglas Adams

Что показывает статистика

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

Akamai опубликовала результаты с еще более резкими зависимостями. Каждые 100 миллисекунд ожидания снижают конверсию на 7%. Каждые 2 секунды ожидания увеличивают вероятность отказа на 103%.
The Daily Telegraph совместно с Optimizely провели свое исследование в 2016 году. Они внесли дополнительную искусственная задержку при загрузке страниц, результаты — на картинке ниже. The Daily Telegraph — одна из самых популярных газет Великобритании с ежемесячной посещаемостью в 70 млн., достаточно возрастной (читай терпеливой) и лояльной аудиторией. Учитывайте это, когда будете смотреть на график.

Ну и вдогонку еще несколько оценок от гигантов e-commerce. Walmart и Amazon сообщают, что каждые сэкономленные 100 миллисекунд времени загрузки их сайта увеличивают прибыль на 1%. На Edge of Future Commercials 2016 AliExpress [заявили], что после того, как они снизили время загрузки своего сайта на 36%, число заказов возросло на 10.5%. Среди новых покупателей конверсия выросла на 27%.


Сколько секунд — хорошо?

Веб-мастера Google могли дать фору многим политикам, отвечая на вопросы про скорость загрузки в рубрике Ask Google Webmasters. Они так и не дали четкого временного интервала допустимой скорости загрузки. Нам посоветовали делать сайт настолько быстрым, насколько возможно, не впадая в крайности при погоне за PSI score, и как обычно рекомендовали сосредоточится на контенте.Прочитать про PSI score и измерить его для любого сайта вы можете здесь, а вот пост на Хабре, где его померили за вас.
Большинство ресурсов, на которые я здесь ссылаюсь, сходятся на том, что хорошее время загрузки — не более трех секунд. Разные источники понимают под этим временем разные вещи, как минимум это Visually Complete, как максимум — полная загрузка. Как показывают исследования, среднее время загрузки мобильных и десктоп страниц сильно больше этого показателя.

В первой версии отчета «Mobile page speed new industry benchmarks» среднее время загрузки лендинговых страниц составило 22 секунды.

В обновленной версии 2018 года, этот показатель улучшился до 15.3 секунд.

В 2019 году Backlinko проанализировали 5 миллионов страниц и установили, что среднее время полной загрузки мобильной страницы — 27 секунд! А среднее время полной загрузки десктоп версии — 10 секунд.

Цифры отличаются потому, что Google анализировал только лендинговые страницы, а Backlinko — все подряд. Теперь немного статистики по Speed Index. На картинке ниже — сравнение средних показателей времени загрузки веб-страниц в 2019 году. Еще раз убеждаемся, насколько Speed Index и Visually Complete — разные вещи.

В 2010 году Мэйли Охей (Maile Ohye), на тот момент Developer Programs Tech Lead в Google, сказала, что они нацелены на показатель в пол секунды. Спустя десять лет ее заявление выглядит примерно, как 2015 год в Back to the Future II.


«…studies by Akamai who found that two seconds is actually the threshold for e-commerce site acceptability. Meaning that that’s what users like to shop with. At Google, we aim for under a half second…»
Maile Ohye


Самое главное


  • В 2020 большая часть интернета все еще очень медленная, а хорошее подключение к сети позволяет в этом убедиться.
  • Скорость загрузки существенно влияет на доход, будь это продажи или реклама.
  • Люди заходят в интернет с мобильных устройств чаще, чем с десктопа.
  • Удобство и скорость мобильной версии сайта не менее важны, чем его настольной версии.
  • Удобным, быстрым и безопасным сайт нужно делать, прежде всего, для реальных пользователей, а уже потом — чтобы Google по голове погладил.
  • При индексировании сайтов в приоритете у Google мобильные версии.
  • Время полной загрузки страницы не всегда отражает реальный опыт пользователей. Нет магического числа, которое бы однозначно показывало скорость работы сайта, но есть набор общепринятых метрик.
  • Скорость работы для пользователя важнее красивой анимации, видео (если это не стриминговый сервис) и других декоративных элементов.
  • Если ваш сайт выглядит готовым к работе через 3 секунды после перехода — это хорошо.

Во второй части этого поста мы рассмотрим самые простые и эффективные способы ускорить загрузку сайта. Разберемся, как в этом могут помочь сервисы по защите и доставке контента. Обсудим, почему комплексные решения, предоставляющие защиту + ускорение как сервис, лучше подходят для большинства проектов. Заходите к нам в блог еще, будет интересно.

10 советов о том, как увеличить скорость загрузки страницы | by Nikita | WebbDEV

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

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

Итак, поехали:

1. Уменьшите количество HTTP-запросов

80% загрузки страницы ориентировано на загрузку компонентов страницы: скриптов, фотографий, файлов CSS, flash. Спецификация HTTP/1.1 советует, чтобы браузеры параллельно загружали не более 2-х компонентов веб-страницы с одного хоста. Уменьшив количество этих компонентов мы уменьшаем количество HTTP-запросов к серверу и как результат увеличиваем скорость загрузки страницы.

Но как уменьшить количество запросов к серверу не затрагивая внешний вид страницы?

На самом деле есть несколько способ.

  • Использование CSS-спрайтов. CSS-спрайт — это комбинированное изображение, которое содержит в себе несколько маленьких изображений, которые в нужный момент для нужного элемента страницы вырезаются используя свойства: background-image и background-position.
  • Использование Inline-картинок. Inline-картинки используют URL-схему data: для встраивания картинки в саму страницу. Это, однако, увеличит размер HTML-документа. Встраивая inline-картинки в ваши таблицы стилей вы добьетесь уменьшения запросов к серверу, а размер HTML останется прежним.
  • Объединение нескольких файлов в один. Если у Вас на страничке подключается больше одного css- или js-файла, то Вы можете объединить их в один. Это очень простой, но действенный способ уменьшения количества http-запросов на сервер. О том, как это делать на лету я писал в своей заметке здесь «Разгони свой сайт. Статическое сжатие css- и js- файлов на лету»

2. Помещайте CSS файлы в начале страницы

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

Если размещать CSS файлы внизу страницы, то это не позволяет многим браузерам рендерить страницу постепенно. Это объясняется тем, что браузер «не хочет» перерисовывать элементы, у которых после загрузки страницы может измениться стиль. Так что все свои CSS файлы всегда подключайте в верхней части страницы в секции HEAD.

3. Помещайте javascript в конец страницы

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

Кроме того, внешние .js-файлы блокируют параллельную загрузку. Спецификация HTTP/1.1 советует, чтобы браузеры параллельно загружали не более 2-х компонентов веб-страницы с одного хоста. Таким образом, если картинки для вашего сайта располагаются на разных хостах, вы получите более 2-х параллельных загрузок. А когда загружается скрипт, браузер не будет начинать никаких других загрузок, даже с других хостов.

4. Минимизируйте css и javascript

Минимизация файла — это удаление из кода всех несущественных символов с целью уменьшения объема файла и ускорения его загрузки. В минимизированном файле удаляются все комментарии и незначащие пробелы, переносы строк, символы табуляции. Здесь все просто. Чем меньше объем файла, тем меньше времени понадобится браузеру на его загрузку. А минимизировать Ваш код помогут вот эти 24 онлайн-сервиса для сжатия и оптимизации CSS кода
5. Используйте поддомены для параллельного скачивания

Как я уже говорил Выше, согласно спецификации HTTP/1.1 на браузеры накладываются ограничения на количество одновременно загружаемых компонентов сайта, а именно не более 2-х компонентов с одного хоста. Поэтому если на Вашем сайте много графики, то ее лучше вынести на отдельный поддомен или поддомены. Для Вас это будет один и тот же сервер, а для браузера — разные. Чем больше поддоменов Вы создадите, тем больше файлов браузер сможет одновременно загрузить и тем быстрее загрузится вся страница сайта. Вам остается лишь изменить адрес картинок на новый. Очень простой, но действенный способ.

6. Используйте кэш браузера

Кеширование становится крайне важным для современных веб-сайтов, которые используют обширное подключение JavaScript и CSS. Дело в том, что когда посетитель зашел на Ваш сайт в первый раз, то браузер выполнит загрузку всех javascript и css-файлов, также загрузит всю графику и флэш, однако правильно выставив HTTP-заголовок Expires, вы сделаете компоненты страницы кешируемыми. Таким образом, когда посетитель зайдет на Ваш сайт снова или перейдет на следующую страницу Вашего сайта, в кэше его браузера уже будут находится некоторые нужные файлы и браузеру не потребуется загружать их снова. Отсюда и выигрыш в скорости загрузки сайта.

Поэтому выставляйте HTTP-заголовок Expires везде, где только это возможно, на несколько дней или даже месяцев вперед. Для того, чтобы веб-сервер Apache отдавал соответствующие рекомендациям HTTP-заголовки Expires, необходимо добавить в файл .htaccess, находящийся в корневой папке сайта, следующие строки:

<IfModule mod_expires.c>Header append Cache-Control "public"FileETag MTime SizeExpiresActive OnExpiresDefault "access plus 0 minutes"ExpiresByType image/ico "access plus 1 years"ExpiresByType text/css "access plus 1 years"ExpiresByType text/javascript "access plus 1 years"ExpiresByType image/gif "access plus 1 years"ExpiresByType image/jpg "access plus 1 years"ExpiresByType image/jpeg "access plus 1 years"ExpiresByType image/bmp "access plus 1 years"ExpiresByType image/png "access plus 1 years"</IfModule>

Данный фрагмент файла конфигурации Веб-сервера Apache проверяет наличие модуля mod_expires и, если модуль mod_expires доступен, включает отдачу HTTP-заголовков Expires, которые устанавливают срок хранения перечисленных выше объектов в кэше браузеров и прокси-серверов равный одному году с момента первой загрузки. Установив такой срок жизни кэша браузера, может возникнуть сложность с обновлением файлов. Поэтому если Вы изменили содержимое css или javascript-файла и хотите, чтобы эти изменения обновились в кэше браузера, то необходимо изменить название самого файла. Обычно в название файла добавляют его версию, например так: styles.v1.css

7. Используйте CDN для загрузки популярных JavaScript библиотек

Если на Вашем сайте используется популярный javascript фреймворк, например jQuery, то для его подключения лучше использовать CDN.

CDN (Content Delivery Network) — это множество веб-серверов, разнесенных географически для достижения максимальной скорости отдачи контента клиенту. Сервер, который непосредственно будет отдавать контент пользователю, выбирается на основании некоторых показателей. Например, выбирается сервер с наименьшим числом промежуточных хопов до него либо с наименьшим временем отклика. Кроме того браузер кэширует javascript-файлы, и если Вы посещали сайты на котором используется такой метод, то эта библиотека уже есть в кэше Вашего браузера, и он не будет загружать её снова.

Одним из таких CDN — является Google Libraries. Это CDN для популярных open-source JavaScript библиотек. Загрузка популярных javascript фреймверков с Google Libraries позволяет увеличить скорость загрузки страницы и снизит траффик на ваш сервер.

О том как загружать jQuery с репозитория Google я писал вот в этой заметке «Увеличиваем скорость загрузки страницы загружая jQuery с репозитория Google».

8. Оптимизируйте ваши изображения

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

  • GIF — идеально подходят для изображений с несколькими цветами, например логотип.
  • JPEG — отлично подходят для детализированых изображений с большим количеством цветов, такие как фотографии.
  • PNG — ваш выбор, когда вам нужно высококачественное изображение с прозрачностью.

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

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

9. Не масштабируйте изображения

Не изменяйте размер изображения при помощи атрибутов width и height тега , либо при помощи CSS. Это тоже негативно влияет на скорость загрузки страницы. Если у Вас есть изображение размером 500x500px, а вставить на сайт Вы хотите изображение с размером 100x100px, то лучше изменить размер оригинальной картинки при помощи графического редактора Photoshop, или любого другого. Чем меньший вес картинки, тем меньше времени потребуется для её загрузки.

10. Используйте Gzip- сжатие

Как показали проведенные исследования, gzip-сжатие текстового файла «на лету» в 95–98% случаев позволяет сократить время на передачу файла браузеру. Если хранить архивированные копии файлов на сервере (в памяти proxy-сервера или просто на диске), то соединение в общем случае удается освободить в 3–4 раза быстрее.

Начиная с версии протокола HTTP/1.1, веб-клиенты указывают, какие типы сжатия они поддерживают, устанавливая заголовок Accept-Encoding в HTTP-запросе.

Accept-Encoding: gzip, deflate

Если веб-сервер видит такой заголовок в запросе, он может применить сжатие ответа одним из методов, перечисленных клиентом. При выдаче ответа посредством заголовка Content-Encoding сервер уведомляет клиента о том, каким методом сжимался ответ.

Content-Encoding: gzip

Переданные таким образом данные меньше первоначальных примерно в 5 раз, и это существенно ускоряет их доставку. Однако здесь есть один недостаток: увеличивается нагрузка на веб-сервер. Но вопрос с сервером всегда можно решить. Так что не будем обращать на это внимание.

Для того, чтобы включить GZIP-сжатие на своем сайте, необходимо в файле .Mozilla/4.0[678] no-gzipBrowserMatch bMSIE !no-gzip !gzip-only-text/html<ifmodule mod_gzip.c>mod_gzip_on Yesmod_gzip_item_include file \.js$mod_gzip_item_include file \.css$ </ifmodule> </IfModule>

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

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

Процесс загрузки страницы | Документация New Relic

В этом документе объясняется:

  • Как загружается веб-страница
  • Как мониторинг браузера измеряет время загрузки страницы, также известный как мониторинг реального пользователя (RUM)

Процесс загрузки страницы

Вот основные шаги в загрузка большинства веб-страниц. Цифры 1-6 на схеме соответствуют пронумерованным шагам ниже.

График загрузки страницы: Шаги загрузки веб-страницы.Диаграммы мониторинга браузера отображают следующие сегменты этого процесса: Сеть , веб-приложение , обработка DOM и рендеринг страницы .

  1. Загрузка страницы начинается, когда пользователь выбирает гиперссылку, отправляет форму или вводит URL-адрес в браузере. Это также называется начальным запросом или началом навигации . Действие пользователя отправляет запрос по сети на сервер веб-приложений.
  2. Запрос поступает в приложение для обработки. (Для начала обработки запроса может потребоваться некоторое время. Это может быть результатом постановки запросов в очередь или других факторов.)
  3. Приложение завершает обработку и отправляет ответ HTML обратно по сети пользователю браузер. Иногда это называется , начало ответа или первый байт .
  4. Браузер пользователя получает ответ HTML и начинает обрабатывать объектную модель документа или DOM .
  5. DOM завершает загрузку; эта точка известна как DOM ready . Используя DOM, браузер пользователя начинает отображать страницу.
  6. Страница завершает рендеринг в браузере пользователя, и возникает событие загрузки окна . (Для страниц, которые используют асинхронную загрузку, некоторые элементы могут продолжать загружаться после события загрузки окна.)

Диаграммы времени загрузки страницы в мониторинге браузера

Мониторинг браузера фиксирует основные сегменты времени загрузки страницы на странице браузера Сводка а страница просматривает страницу .Если у вас включен мониторинг SPA, у вас будет доступ как к этой диаграмме, так и к диаграммам, относящимся к SPA. Диаграммы показывают:

  • Сеть
  • Время веб-приложения
  • Обработка DOM
  • Отрисовка страницы
  • Другие применимые сегменты, например, очередь запросов

Цвета диаграммы соответствуют цветам на временной диаграмме загрузки страницы.

one.newrelic.com> Браузер> (выберите приложение)> Сводка : диаграмма времени загрузки отображается на странице Сводка и просмотров страницы.

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

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

Веб-приложение

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

Сеть

Сетевой уровень включает время, затрачиваемое на перенаправления, а также на запрос и получение HTML. Он не включает время на сервере или статические активы.

Измерение сетевого времени начинается с первого щелчка по ссылке. Сетевое время включает в себя DNS и может включать более одного поиска, если у вас есть перенаправления на вашем сайте, TCP (включая брандмауэр, если вы не настроили мониторинг времени очереди запросов) и время соединения SSL.

  • Если у вас настроен мониторинг времени очереди запросов , то сетевое время не включает в себя какое-либо время очереди запросов, которое происходит после заголовка X-Request.

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

    API спецификации времени навигации предоставляет подробную разбивку сетевого времени. (Для старых браузеров таймер запускается по «событию перед выгрузкой».)

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

    Для получения дополнительной информации о том, как это внутреннее время разбивается с точки зрения браузера, используйте страницу Session traces . Трассировка сеанса сообщает обо всех доступных сетевых событиях, поэтому вы можете видеть в каждом конкретном случае, как браузер тратит время на поиск DNS и другие сетевые события.

    Важно

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

Обработка DOM

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

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

Отрисовка страницы

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

Очередь запросов

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

Запросы сервера приложений и транзакции браузера

Часто количество транзакций сервера приложений (запросов в минуту или об / мин ) превышает количество транзакций браузера (страниц в минуту или ppm ) для того же приложения. Для получения дополнительной информации см. Процедуры устранения неполадок.

Выбросы

Независимо от того, насколько хорошо работает ваше приложение, будут медленные браузеры, платформы и сети, из-за которых общее время отклика будет казаться медленнее.Чтобы свести к минимуму перекос, вызванный выбросами, время загрузки страницы ограничивает и масштабирует время ответа конечного пользователя, которое больше чем в 4,5 раза превышает значение Apdex T вашего приложения, до 4,5 раза Apdex T или до 13,5 секунд, в зависимости от того, что больше. (Выбросы гистограммы отсекаются на 95%.)

Например, если пороговое значение Apdex T для конечного пользователя вашего приложения составляет 8 секунд, то время отклика будет ограничено 36 секундами. Это сводит к минимуму влияние этого времени отклика на ваше приложение в целом, но все же обеспечивает учет «разочарованных» оценок Apdex.

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

Дополнительная справка

Дополнительные ресурсы документации включают:

Что такое показатели производительности? — Rigor

Rigor предлагает более 40 показателей, которые помогут вам лучше понять данные о вашей веб-производительности. Эти показатели помогут находить, исправлять и предотвращать дефекты и дадут вам более полное представление о том, как формировать вашу веб-производительность.

Время работы

Время первого байта: Время от начала первого запроса до получения первого байта первого запроса без перенаправления. На этот раз количество редиректов 3xx увеличится.

Время взаимодействия DOM: Время до полной загрузки и обработки DOM.

Время первой отрисовки: Время, пока браузер не отобразит что-либо, кроме фона по умолчанию.

Время первой отрисовки содержимого: Время до первого отображения браузером содержимого.

Время первой значимой отрисовки: Время до самого крупного изменения макета верхней части страницы и загрузки веб-шрифтов.

Время начала рендеринга: Время до отрисовки первого пикселя содержимого.

Время загрузки DOM: Время до загрузки документа и анализа начальной разметки. Это соответствует событию DOMContentLoaded браузера.

Время завершения DOM: Время до готовности страницы и всех ее подресурсов.

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

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

Время загрузки: Время до загрузки страницы. Это соответствует событию загрузки браузера.

Время завершения визуализации: Время до завершения рендеринга всего верхнего содержимого.

Индекс скорости: Вычисляемая метрика, показывающая, насколько быстро страница отображает содержимое верхней части страницы. Подробнее о том, как это работает, читайте здесь.

Время полной загрузки: Время до 1,5 секунд бездействия сети после загрузки с ожиданием до 5 секунд. Если загрузка никогда не достигается, время от начала первого запроса до конца последнего запроса заканчивается.Последний запрос для завершения не всегда является последним запущенным запросом.

Время подключения

Время DNS: Время, необходимое для разрешения имени хоста от DNS-сервера

TCP Connect Time: Время для создания TCP-соединения.

Время SSL: Время, необходимое для согласования SSL / TLS.

Время отправки: Время, необходимое для отправки данных HTTP на сервер.

Время ожидания: Время с момента завершения запроса до момента получения первого байта ответа для первого запроса на странице.

Время приема: Время, необходимое для чтения всего ответа от сервера.

Количество ресурсов и ошибок

Количество запросов: Общее количество сделанных запросов. Это эквивалентно сумме всех типов ресурсов (HTML, изображение, JavaScript, CSS, видео, шрифт и другие значения).

Количество HTML: Количество запросов HTML-документов.

Количество изображений: Количество запросов изображений.

Количество JavaScript: Количество запросов файлов JavaScript.

Количество CSS: Количество запросов на файлы CSS.

Количество видео: Количество запросов на видео.

Количество шрифтов: Количество запросов шрифтов.

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

Количество ошибок клиента: Количество ответов с кодом состояния от 400 до 499.

Количество ошибок подключения: Количество ответов с кодом состояния 504 или 0 (запрос, прерванный браузером).

Количество ошибок сервера: Количество ответов с кодом состояния 500 или выше (исключая 504).

Количество ошибок: Общее количество ответов с кодами состояния больше или равными 400. Это эквивалентно общему количеству ошибок клиента, соединения и сервера.

Размеры содержимого

Размеры содержимого рассчитываются с использованием размера передачи (или размера передачи) каждого запроса.

Размер содержимого: Общий размер (в байтах) всего загруженного содержимого. Это эквивалентно общей сумме размеров всех типов ресурсов (HTML, изображение, JavaScript, CSS, видео, шрифт и другие размеры).

Размер HTML: Общий размер (в байтах) всего загруженного содержимого HTML.

Размер изображения: Общий размер (в байтах) всех загруженных изображений.

Размер JavaScript: Общий размер (в байтах) всех загруженных файлов JavaScript.

Размер CSS: Общий размер (в байтах) всех загруженных файлов CSS.

Размер видео: Общий размер (в байтах) всех загруженных видео.

Размер шрифта: Общий размер (в байтах) всех загруженных шрифтов.

Другой размер: Общий размер (в байтах) всех других ресурсов, кроме запросов HTML, изображений, JavaScript, CSS, видео или шрифтов.

Web Vitals

Самая большая Contentful Paint: измеряет время загрузки страницы, воспринимаемое пользователями. Метрика «Самая большая краска содержимого» (LCP) сообщает время визуализации самого большого элемента содержимого, видимого в области просмотра.

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

Совокупное смещение макета: измеряет стабильность страницы. CLS основан на формуле, которая подсчитывает, сколько раз компоненты на странице перемещаются или «сдвигаются» во время загрузки страницы. Лучше меньше смен.

Другие показатели

Время отклика: Время отклика для одной страницы Real Browser Check такое же, как время загрузки.Если настоящая проверка браузера состоит из нескольких этапов, то время отклика равно сумме времен загрузки для каждой страницы, доступной во время пользовательского потока. Время отклика для проверки работоспособности равно времени сервера.

Время безотказной работы: Для проверки работоспособности метрика «Время работы» представляет собой процентное время безотказной работы конечной точки в течение заданного периода времени.

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

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

Основы скорости страницы

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

  • Количество ресурсов (например, изображений, шрифтов, HTML и CSS), загруженных на страницу
  • Размер файла этих ресурсов
  • Воспринимаемая производительность вашего сайта пользователями

В дополнение к тому, что пользователи видят при отображении контента в браузере, есть дополнительные улучшения, которые вы можете внести в серверную часть, включая оптимизацию любой работы, которую сервер должен выполнить, чтобы вернуть первый байт обратно клиенту.На время загрузки страницы приходится больше, чем просто то, что происходит во внешнем интерфейсе вашего сайта, например, вызовы базы данных или компиляция шаблонов в HTML. Однако, как говорит Стив Содерс, «от 80 до 90% времени ответа конечного пользователя тратится на интерфейс». Поскольку именно здесь живет подавляющее большинство пользователей, мы сосредоточимся на интерфейсных аспектах времени загрузки страницы.

Как браузеры отображают контент

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

Сначала браузер отправляет запрос на получение контента. В первый раз, когда браузер делает запрос к новому домену, ему необходимо найти сервер, на котором находится этот контент. Это называется поиском DNS . Поиск DNS определяет, где в Интернете живет ваш веб-хост, чтобы запрос контента мог дойти до вашего сервера. Браузер запомнит это местоположение в течение определенного периода времени (определяемого настройками DNS для вашего сервера), поэтому ему не нужно тратить драгоценное время на поиск по каждому запросу.

Как только ваш сервер устанавливает соединение с браузером пользователя и получает свой первый запрос, он декодирует запрос и обнаруживает контент, который браузер ищет, пытаясь отобразить страницу. Затем ваш сервер отправит обратно этот контент, будь то изображение, CSS, HTML или другой вид ресурсов, и браузер начнет его загружать и отображать страницу для пользователя. Рисунок 2-1 иллюстрирует этот цикл.

Рисунок 2-1. Цикл времени загрузки страницы между браузером вашего пользователя и содержанием на вашем сервере.

Первый байт контента, который получает браузер, измеряется и называется временем до первого байта (TTFB). Это хороший показатель того, насколько быстро серверная часть вашего сайта может обрабатывать и отправлять обратно контент. Во внешнем интерфейсе, как только ваш браузер начинает получать этот контент обратно с вашего сервера, может потребоваться некоторое время, чтобы загрузить и отобразить контент на странице. Некоторые типы файлов обрабатываются и обрабатываются браузерами быстро; другие типы запросов (например, блокирующий JavaScript), возможно, потребуется полностью обработать, прежде чем браузер пользователя сможет продолжить отображение дополнительного контента.

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

Запросы

Оптимизация размера и количества запросов, необходимых для создания вашей веб-страницы, окажет огромное влияние на время загрузки страницы вашего сайта.Чтобы проиллюстрировать, как запросы влияют на общую скорость страницы, давайте рассмотрим пример каскадной диаграммы с использованием WebPagetest. (Мы рассмотрим, как использовать WebPagetest в главе 6.) Каскадная диаграмма, такая как на рис. 2-2, показывает, сколько времени требуется для запроса содержимого страницы, такого как CSS, изображения или HTML, и сколько время, необходимое для загрузки этого содержимого перед его отображением в браузере.

Рисунок 2-2. Каждая горизонтальная линия на каскадной диаграмме представляет отдельный запрос актива.

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

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

Например, когда мы работаем с изображениями, мы можем организовать отдельные запросы изображений в один спрайт (т. Е. Набор изображений), чтобы сократить количество запросов, которые браузер должен выполнять (мы рассмотрим эту технику в «Спрайтах»).Мы также можем запускать каждое изображение с помощью инструментов сжатия, которые уменьшают размер файла изображений без ущерба для их качества (подробнее см. В разделе «Дополнительное сжатие»). Мы также сосредоточимся на сокращении общего количества файлов CSS и JavaScript и загрузке их в наиболее оптимальном для воспринимаемой производительности порядке, как описано в разделе «Загрузка CSS и JavaScript». Оптимизация размера и количества запросов, необходимых вашему браузеру для загрузки вашей страницы, поможет вам оптимизировать скорость вашего сайта.

Подключения

Количество запросов , которые требуется для загрузки вашей страницы, отличается от количества подключений , которые ваш браузер делает для получения этого содержимого.В WebPagetest в представлении «Подключение» (рис. 2-3) показано каждое подключение к серверу и запросы, полученные через него.

Рисунок 2-3. В представлении «Подключение» в WebPagetest отображается каждое подключение к серверу и полученные запросы.

Для каждого подключения вы можете увидеть поиск DNS для домена (темно-зеленый), начальное соединение с сервером (оранжевый) и, возможно, согласование SSL, прежде чем браузер начнет получать контент (ярко-розовый) для активов, обслуживаемых через HTTPS.Но браузеры умны и пытаются оптимизировать загрузку контента, как только у них будет открыто соединение с вашим сервером.

Что такое согласование SSL?

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

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

Вы также заметите, что браузер (в данном случае Chrome) установил несколько открытых подключений одновременно, распараллеливая объем контента, который он может получить.Количество одновременных постоянных подключений, которые может установить каждый браузер, варьируется. Современные браузеры допускают до шести одновременных открытых подключений (Chrome, Firefox, Opera 12) или до восьми (Internet Explorer 10).

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

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

Вес страницы

Размер файла HTML, изображений и другого содержимого, необходимого для загрузки вашей страницы, будет влиять на общее время загрузки страницы. Один из способов измерить размер файла каждого типа контента — использовать плагин для браузера YSlow.Мы расскажем, как использовать его в YSlow.

После того, как вы запустите YSlow на своей странице, переключитесь на вкладку «Компоненты» (рис. 2-4), чтобы увидеть список типов контента для этой страницы и их размер.

Рисунок 2-4. На вкладке «Компоненты» в YSlow вы можете увидеть список типов контента, используемых на веб-странице, и их размер.

В этом примере мы видим, что включение gzip уменьшает размер наших файлов HTML («doc» в этой таблице), JavaScript и CSS. Если вам интересно, как работает gzip, мы расскажем об этом в статье «Минификация и gzip.«Мы также можем видеть, что, хотя для загрузки страницы требуется всего шесть изображений, их общий размер составляет 722,6 КБ! Это очень большие изображения. Строка cssimage отделяет любые изображения, вызываемые и применяемые с помощью CSS, от изображений, встроенных непосредственно в HTML-код сайта.

Посмотрите на свой собственный вес страницы и сравните его с графиками «среднего байта на страницу» на https://httparchive.org/interesting.php. Вы много используете CSS или JavaScript? Какова разбивка типов контента на вашей странице: значительно ли ваши изображения перевешивают другие типы контента, как в предыдущем примере, или есть еще один выброс?

Что такое HTTP-архив?

HTTP-архив — это постоянное хранилище информации о веб-производительности, такой как размер страниц, неудавшиеся запросы и используемые технологии.Он собирает информацию WebPagetest для URL-адресов, включенных в список 250 000 сайтов Alexa Top.

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

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

Воспринимаемая производительность

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

Критический путь рендеринга

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

Чтобы понять, как работает критический путь рендеринга, вам необходимо понять, как браузеры обрабатывают визуальный рендеринг веб-страниц, читая HTML, CSS и JavaScript для страницы. Браузеры начинают с создания объектной модели документа или DOM. Браузер получит HTML-код обратно от веб-сервера и начнет его анализ: необработанные байты становятся символами, строки символов становятся токенами, такими как , токены становятся объектами, имеющими свойства и правила, и, наконец, эти объекты связаны друг с другом в структура данных.Этот последний шаг — создание DOM-дерева, на которое браузер пользователя полагается для всей дальнейшей обработки страницы.

Когда браузер читает HTML-код, он наталкивается на таблицу стилей. Браузер приостановит все и запросит этот файл с вашего сервера. Когда он получит файл обратно, браузер повторит аналогичный процесс: необработанные байты станут символами, строки символов станут токенами, токены станут объектами, объекты будут связаны в древовидной структуре, и, наконец, у нас будет объектная модель CSS , или CSSOM.

Затем браузер пользователя объединит DOM и CSSOM для создания дерева рендеринга , которое он будет использовать для вычисления размера и положения каждого видимого элемента. Дерево рендеринга содержит только то, что необходимо для рендеринга страницы (поэтому все с отображением : нет не будет включено в дерево рендеринга). Наконец, браузер отобразит на экране окончательное дерево рендеринга.

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

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

Рисунок 2-5. В режиме просмотра ленты WebPagetest вы можете видеть, что отображается на экране пользователя по мере загрузки страницы.

Если посмотреть на Yahoo! домашняя страница в 0.С 5-секундными интервалами мы видим, что страница остается пустой примерно до 2 секунд времени загрузки. Чем раньше вы начнете отображать видимый контент на странице, тем быстрее страница будет восприниматься вашим пользователем.

Примечание
Результаты

WebPagetest зависят от местоположения, браузера, скорости соединения и других факторов. Хотя легко посмотреть на загрузку Yahoo! Домашняя страница с интервалами 0,5 секунды, вы, вероятно, захотите просмотреть 0,1-секундные интервалы времени загрузки вашего собственного сайта, которые вы можете выбрать в режиме просмотра ленты WebPagetest.

Есть несколько способов оптимизировать критический путь рендеринга. Поскольку по умолчанию CSS обрабатывается как ресурс, блокирующий рендеринг, используйте типы мультимедиа и медиа-запросы, чтобы указать, какие части вашего CSS могут не блокировать рендеринг:

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

  2. Эта таблица стилей будет применяться только в том случае, если ширина браузера равна или больше 61,5 см. Он не будет блокировать рендеринг, если ширина браузера меньше 61,5 em, но он будет блокировать рендеринг, если браузер соответствует этому условию min-width .

Другой способ оптимизировать критический путь рендеринга — убедиться, что вы загружаете JavaScript наиболее эффективным способом.JavaScript блокирует построение DOM, если оно не объявлено как асинхронное; Узнайте больше о том, как заставить ваш JavaScript хорошо взаимодействовать с остальной загрузкой страницы, в разделе «Загрузка CSS и JavaScript».

Хотите получить больше информации о предполагаемом влиянии критического пути на производительность вашего сайта на производительность? WebPagetest также предоставит вам показатель под названием «Индекс скорости» для вашей страницы. Согласно документации WebPagetest, индекс скорости — это среднее время, в течение которого отображаются видимые части страницы. Он выражается в миллисекундах и зависит от размера выбранного окна просмотра.

Показатель Speed ​​Index — отличный показатель, за которым стоит следить, когда вы пытаетесь измерить воспринимаемую производительность вашей страницы, поскольку он показывает, насколько быстро контент, находящийся в верхней части страницы, заполняется вашими пользователями. Лучше сосредоточиться на том, как быстро ваши пользователи начнут видеть и смогут взаимодействовать с контентом, а не на том, сколько времени требуется браузеру, чтобы полностью завершить загрузку контента вашей страницы (включая любой асинхронный контент, который извлекается и выполняется после документа. визуально завершена).Вы можете узнать больше об измерении индекса скорости WebPagetest и о том, сколько времени требуется для полной загрузки страницы в главе 6.

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

  • Асинхронная загрузка содержимого
  • Расставляйте приоритеты для запросов на «заметное» содержание
  • Следуйте рекомендациям по загрузке CSS и JavaScript (подробнее см. «Загрузка CSS и JavaScript»)
  • Кэширование ресурсов для вернувшихся пользователей (подробнее в разделе «Кэширование ресурсов»)
  • Убедитесь, что все основные действия на странице доступны пользователю как можно быстрее.

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

Янк

Вы когда-нибудь замечали заикание или пропуски при прокрутке веб-страницы? Это называется jank и возникает, когда скорость рендеринга браузера замедляется ниже 60 кадров в секунду. Jank создаст неудобства для пользователей и негативно повлияет на восприятие пользователями производительности вашего сайта.

Это заикание вызвано попыткой браузера нарисовать изменение на странице. Изменение визуальных свойств элемента (таких как фон, цвет, радиус границы или тень) вызовет новую раскраску в браузере.Пользователь также может запускать рисование, выполняя действие, изменяющее видимость элемента вашей страницы, например отображение или скрытие содержимого или щелчок по карусели. Браузер будет «перерисовывать» части экрана вашего пользователя по мере изменения вещей.

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

Если вы заметили, что на вашем сайте наблюдаются симптомы нежелательной почты, существуют некоторые инструменты браузера, которые помогут вам отладить основную причину. В Chrome DevTools есть представление временной шкалы (рис. 2-6), которое показывает частоту кадров при взаимодействии со страницей.

Рисунок 2-6. Временная шкала Chrome DevTools показывает частоту кадров с течением времени при взаимодействии с веб-страницей.

После того, как вы нажмете «запись» и начнете взаимодействовать со своей страницей, Chrome DevTools будет записывать количество кадров в секунду, а также то, что делал браузер, например, пересчет стилей, запуск событий или рисование.Как только вы найдете область, в которой частота кадров упала ниже порога 60 кадров в секунду, вы можете начать нацеливаться на эту область, чтобы уменьшить проблемы с перерисовкой. Начните с скрытия элементов в этой области страницы, чтобы увидеть, какие элементы могут вызывать задержку, а затем поиграйте со скрытыми цветами, тенями и анимацией, чтобы увидеть, что может быть основной причиной медлительности. Подробнее о том, как использовать Chrome DevTools, читайте в разделе «Chrome DevTools».

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

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

Другие факторы, влияющие на скорость загрузки страниц

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

География

Географическое положение пользователя может сильно повлиять на время, необходимое для загрузки вашего сайта.Если вы запустите несколько тестов в разных географических точках с помощью инструмента тестирования, такого как WebPagetest, вы заметите разное время загрузки. Это связано с тем, что браузеры запрашивают и получают данные через физические соединения, и существует ограничение на скорость, с которой контент может перемещаться на большие расстояния; Браузеру вашего пользователя потребуется больше времени, чтобы связаться с вашим сервером, если он находится дальше. Если пользователь находится в Австралии, а ваш контент находится на сервере в Соединенных Штатах, для этого пользователя потребуется гораздо больше времени для доступа к вашему контенту, чем для человека, живущего в Соединенных Штатах.

Вот почему сетей доставки контента (CDN) используются сайтами с глобальной базой пользователей. Сети CDN создают серверы с копиями данных по всему миру, чтобы пользователи могли связываться с ближайшим к ним сервером, экономя время. Для австралийской пользовательской базы в этом примере вы можете рассмотреть возможность обслуживания вашего контента из CDN с расположением в Азиатско-Тихоокеанском регионе, чтобы пользователи могли получать доступ к вашему контенту с сервера, расположенного ближе к их месту проживания.

Сеть

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

Точно так же сеть пользователя может иметь огромное влияние на то, сколько времени занимает каждый запрос контента.В медленной сети браузеру вашего пользователя потребуется гораздо больше времени, чтобы найти и затем установить первоначальное соединение с вашим сервером, а затем еще больше времени для загрузки вашего контента. Это число будет увеличиваться по мере увеличения количества запросов, которые браузер вашего пользователя должен сделать для отображения вашей страницы. Мобильные сети — хороший пример влияния задержки сети; подробнее об этих проблемах читайте в разделе «Мобильные сети».

Браузер

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

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

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

Двухсекундная загрузка страницы

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

В Google Analytics вы можете получить представление о производительности вашего веб-сайта и сервера в разделе «Поведение → Скорость сайта» меню «Отчеты». Отчет «Скорость загрузки сайта» всегда создается на основе выборочных данных, и по умолчанию размер выборки составляет 1% посетителей. Скорость сайта также можно отслеживать только для посетителей, которые используют браузер, поддерживающий время навигации HTML5 (например, Chrome, Firefox 7 и более поздних версий, Internet Explorer 9 и более поздних версий [более ранние версии IE, если установлена ​​панель инструментов Google], Edge, некоторые версии Safari, Android 4.0 и выше, дополнительные браузеры также поддерживают эту функцию, но используются реже.)

Самым важным показателем производительности системы на странице «Скорость сайта» для веб-сайта является среднее время загрузки страницы . Среднее время загрузки страницы получается путем объединения семи отдельных показателей (время перенаправления, время поиска домена, время соединения с сервером, время ответа сервера, время взаимодействия с документом, время загрузки содержимого документа и время загрузки страницы) в единую метрику.Следует отметить, что эталонное время загрузки страницы для типичного веб-сайта, основанного на данных, в 2016 и 2017 годах составляло 3 секунды. Из-за более быстрого компьютерного оборудования и подключения к Интернету, которые стали доступны с 2017 года, для посетителей было бы разумным ожидать, что время загрузки страницы составит 2 секунды или меньше по сегодняшним стандартам.

Ниже приводится объяснение среднего времени загрузки страницы:

Среднее время загрузки страницы (Целевой диапазон для этого показателя должен составлять 2 секунды или меньше.) — Среднее время загрузки страницы — это среднее время, измеряемое в секундах, которое требуется для полной загрузки страницы на основе набора данных образца и выбранного диапазона дат.

Среднее время загрузки страницы начинается, когда начинается процесс навигации (т. Е. Посетитель нажимает ссылку либо внутри на странице вашего сайта, либо на внешнюю ссылку на другом веб-сайте, который ссылается на ваш веб-сайт) и заканчивается, когда веб-страница полностью загружается. в своем браузере. Эта мера включает в себя все меры, указанные ниже (пункты 1–7), и, как таковая, всегда будет самой большой временной метрикой при измерении производительности системы.

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

  • Среднее время перенаправления (Целевой диапазон для этого показателя должен составлять от 0 до 0,30 секунды.) — следует избегать перенаправления, но иногда они неизбежны, и если перенаправления задействованы, это будет указывать время, необходимое для начала и окончания перенаправления, если перенаправления не задействованы, этот показатель будет показывать ноль (0.
  • Среднее время поиска домена Время (Целевой диапазон для этого показателя составляет от 0,01 до 0,03 секунды.) — Google определяет это как «среднее время (в секундах), затрачиваемое на поиск DNS для этой страницы». Он измеряет, как долго браузер пользователя ищет IP-адрес вашего веб-сайта.На данный момент на временной шкале никакие данные с вашего веб-сайта не начали загружаться, и общий фактор, который может повлиять на это измерение, — это контент, отображаемый из нескольких мест (например, сторонние скрипты). Это должно быть одним из самых коротких связанных измерений времени. с временной последовательностью загрузки страницы.
  • Среднее время соединения с сервером (Целевой диапазон для этого показателя составляет от 0,01 до 0,25 секунды.) — Google определяет это как «среднее время (в секундах), затраченное на установление TCP-соединения для этой страницы.Этот таймер запускается сразу после завершения поиска домена и измеряет время, необходимое серверу для подключения к устройству посетителя. Этот показатель, как и среднее время поиска в домене, также должен быть одним из двух самых быстрых на временной шкале для загрузки страницы.
  1. Среднее время ответа сервера (ART) (Целевой диапазон для этого показателя должен составлять 0,20 секунды (200 мс) или меньше.) — Google определяет это как «среднее время (в секундах), которое требуется вашему серверу для ответа на запрос пользователя, включая сетевое время от местоположения пользователя до вашего сервера.На этот показатель может влиять любое или все из следующих факторов: медленная логика приложения, медленные запросы к базе данных, медленная маршрутизация и проблемы с ресурсами, такие как нехватка ЦП, нехватка памяти, даже местоположение посетителя и сетевая архитектура.
  2. Среднее время взаимодействия с документом (Целевой диапазон для этого показателя составляет менее 0,80 секунды.) — Это измерение начинается, когда фактическое содержимое страницы начинает загружаться в браузер посетителя. Во время интерактивного взаимодействия с документом страница все еще загружается, но загружено достаточно контента, чтобы посетитель мог начать взаимодействовать со страницей.Пользователь может увидеть текст, щелкнуть гиперссылку и увидеть одно или два изображения. Этот показатель измеряет количество времени в секундах, которое требуется, чтобы добраться до этой точки на временной шкале от начала временной шкалы (пункты 1–4 выше). Хотя контент загружен не полностью, именно в этот момент большинство посетителей будут воспринимать страница загружается быстро или медленно.
  3. Среднее время загрузки содержимого документа (Целевой диапазон для этого показателя должен быть менее 1,0 секунды.) — Google определяет этот показатель как «среднее время (в секундах), которое требуется браузеру для синтаксического анализа документа и выполнения отложенного и синтаксического анализа. вставленные сценарии (загружено содержимое объектной модели документа (DOM)), включая сетевое время от местоположения пользователя до вашего сервера.Этот показатель учитывает всю временную шкалу до этого момента (пункты 1–5) и, как таковой, всегда должен быть выше, чем Среднее время взаимодействия с документом.
  4. Среднее время загрузки страницы (Целевой диапазон для этого показателя составляет 1,0 секунды или меньше.) — Google определяет это измерение как «среднее время (в секундах) для загрузки этой страницы». На этом этапе загрузка веб-страницы завершена, но другие аспекты, такие как CSS, изображения и любые другие упомянутые элементы, не загружены полностью, это измерение прекращает подсчет после загрузки всего содержимого.Этот показатель не включает никаких других показателей до этого момента, только время, необходимое для полной загрузки всего содержимого веб-страницы.

Измеряя и отслеживая все семь показателей производительности сайта Google Analytics, можно проанализировать более полную картину производительности системы, что позволит владельцу веб-сайта или аналитику выявить любые узкие места в производительности. Узкие места в производительности можно разделить на две большие категории: меры загрузки перед страницей и меры загрузки страницы.Узкие места загрузки страницы могут быть определены путем анализа приведенных выше измерений 1–4 и могут выходить за рамки контроля владельца веб-сайта; Узкие места при загрузке страницы можно определить путем анализа приведенных выше измерений 5–7, и владелец веб-сайта во всех случаях может контролировать факторы, составляющие эти измерения.

Измерения семи показателей производительности сайта объединяются для получения среднего времени загрузки страницы. Целевой диапазон для процесса предложения веб-страницы составляет две секунды или меньше от начала навигации (элемент 1) до полностью загруженной страницы (элемент 7.)

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

Рисунок 1. График среднего времени загрузки страницы Google Analytics

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

Рисунок 2: Различия во времени загрузки страницы в зависимости от браузера, страны и страницы

Источники:

Определения:

DOM или объектная модель документа — это кроссплатформенный и не зависящий от языка интерфейс прикладного программирования, который обрабатывает документ HTML, XHTML или XML как древовидную структуру, в которой каждый узел является объектом, представляющим часть документа.Объектами можно управлять программно, и любые видимые изменения, происходящие в результате, могут быть отражены в отображении документа.

Что важно при анализе скорости вашего сайта?

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

Существует довольно много инструментов, которые вы можете использовать для проверки скорости вашего сайта, наиболее популярным из которых, вероятно, является собственная страница Google Page Speed ​​Insights. Запуск этого инструмента дает вам 100 баллов по скорости для мобильных и настольных компьютеров: чем выше оценка, тем быстрее и, в конечном итоге, здоровее ваш веб-сайт.

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

Все хорошо и хорошо, чтобы исправить эти проблемы, я не говорю, что вы не должны, но я говорю, что вы не должны доверять этим инструментам, чтобы дать вам точное представление о том, что пользователь воспринимает как медленный сайт. . Причина? Поскольку эти инструменты смотрят на общее время, необходимое для загрузки вашего веб-сайта, что не является самым важным фактором, во время загрузки Document Object Model (DOM) .

Почему время DOM важнее?

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

В Google Analytics «Среднее время взаимодействия с документом» — это время, необходимое для первого взаимодействия пользователя с веб-сайтом, несмотря на то, что он загружен не полностью. Это наиболее важная метрика, поскольку, как только пользователь сможет взаимодействовать с вашим сайтом, вероятность его ухода с него значительно снизится.Следовательно, вам нужно убедиться, что время вашего DOM как можно меньше, особенно на ваших самых важных целевых страницах.

Как определить и улучшить тайминги DOM

Вы должны стремиться к тому, чтобы время интерактивного взаимодействия с документом составляло около 3,0–3,5 секунды, но первое, что вам нужно выяснить, это то, что время взаимодействия объектной модели документа является проблемой для вашего сайта.

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

Google Analytics

Очевидно, что GA необходим при анализе вашего DOM Timings, потому что он предоставляет вам данные о ваших фактических пользователях. Чтобы узнать время взаимодействия с документом, вам нужно пройти по этому пути:

  1. Поведение
  2. Скорость сайта
  3. Время страницы
  4. На вкладке Explorer выберите DOM Timings
  5. Измените раскрывающееся меню «По сравнению со средним значением по сайту» на «Средн. Время взаимодействия с документом (сек) »
  6. Упорядочить по просмотрам страниц
  7. Щелкните отдельные ссылки, чтобы узнать их время.

Плагин Chrome: время загрузки страницы:

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

Тест веб-страницы:

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

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

Таким образом, улучшение таймингов DOM — это самый важный аспект, на который нужно обращать внимание при анализе скорости страницы вашего веб-сайта, и это главный момент, о котором вы должны беспокоиться.Улучшение этого времени поможет вам сохранить ваши посещения и улучшить общий коэффициент конверсии. По сути, DOM = $$$$!

веб-производительности | MDN

Веб-производительность — это объективные измерения и восприятие пользователем времени загрузки и времени выполнения. Производительность в Интернете — это то, сколько времени требуется сайту, чтобы он загружался, стал интерактивным и отзывчивым, и насколько плавным становится контент во время взаимодействия с пользователем — плавно ли прокрутка? кнопки кликабельны? Быстро ли загружаются и отображаются всплывающие окна и плавно ли они анимируются? Производительность сети включает как объективные измерения, такие как время загрузки, количество кадров в секунду и время до перехода в интерактивный режим, так и субъективное восприятие того, сколько времени потребовалось для загрузки содержимого.

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

Существуют инструменты, API-интерфейсы и передовые методы, которые помогают нам измерять и улучшать веб-производительность. Мы освещаем их в этом разделе:

Производительность анимации и частота кадров
Анимация в Интернете может выполняться через окно SVGAnimationElement , .requestAnimationFrame , включая холст и WebGL_API , CSS анимацию , видео , анимированные гифки и даже анимированные PNG и другие типы изображений. Затраты на производительность анимации свойства CSS могут варьироваться от одного свойства к другому, а анимация дорогих свойств CSS может привести к задержке, поскольку браузер изо всех сил пытается достичь плавной частоты кадров.
Критический путь отрисовки
Критический путь отрисовки — это последовательность шагов, которые браузер выполняет для преобразования HTML, CSS и JavaScript в пиксели на экране.Оптимизация критического пути рендеринга улучшает производительность рендеринга. Критический путь рендеринга включает объектную модель документа (DOM), объектную модель CSS (CSSOM), дерево рендеринга и макет.
Производительность анимации CSS и JavaScript
Анимация имеет решающее значение для приятного взаимодействия с пользователем во многих приложениях. Существует множество способов реализации веб-анимации, например, CSS , переход /, анимация или анимация на основе JavaScript (с использованием Window.requestAnimationFrame ).В этой статье мы анализируем разницу в производительности между анимацией на основе CSS и на основе JavaScript.
Ленивая загрузка
Ленивая загрузка — это стратегия, позволяющая идентифицировать ресурсы как неблокирующие (некритические) и загружать их только при необходимости. Это способ сократить длину критического пути рендеринга, что приводит к сокращению времени загрузки страницы.
Время навигации и ресурсов
Время навигации — это метрики, измеряющие события навигации по документу браузера. Тайминги ресурсов — это подробные измерения времени в сети, относящиеся к загрузке ресурсов приложения.
Оптимизация производительности при запуске

Часто упускаемый из виду аспект разработки программного обеспечения приложений — даже среди тех, кто сосредоточен на оптимизации производительности — это производительность при запуске. Как долго ваше приложение запускается? Кажется, блокирует устройство или браузер пользователя во время загрузки приложения? Это заставляет пользователей беспокоиться о том, что ваше приложение вылетает из строя или что-то еще не так.Всегда полезно выделить время, чтобы убедиться, что ваше приложение запускается нормально. В этой статье представлены советы и предложения, которые помогут вам достичь этой цели как при написании нового приложения, так и при переносе приложения с другой платформы в Интернет.

Бюджеты производительности
Бюджеты производительности — это предел для предотвращения регрессов. Он может применяться к файлу, типу файла, всем файлам, загруженным на страницу, определенной метрике (например, времени до взаимодействия), пользовательской метрике (например.грамм. Time to Hero Element) или порог за период времени.
Основы производительности

Производительность означает эффективность. В контексте Open Web Apps в этом документе в общих чертах объясняется, что такое производительность, как платформа браузера помогает ее улучшить, а также какие инструменты и процессы вы можете использовать для ее тестирования и улучшения.

Мониторинг производительности: RUM против синтетического мониторинга
Синтетический мониторинг и Мониторинг реального пользователя (RUM) — это два подхода к мониторингу и анализу производительности сети.
Заполнение страницы: как работают браузеры
разработчик должен стремиться к достижению этих двух целей.
Рекомендуемое время веб-производительности: сколько времени — это слишком долго?
Нет четких установленных правил относительно того, что представляет собой медленный темп при загрузке страниц, но есть конкретные рекомендации для указания того, что контент будет загружаться (1 секунда), простоя (50 мс), анимация (16,7 с) и реакция на ввод пользователя ( От 50 до 200 мс).
Задержка
Задержка — это время, которое требуется для прохождения пакета данных от источника к месту назначения.Что касается оптимизации производительности, важно провести оптимизацию, чтобы уменьшить причины задержки и протестировать производительность сайта, эмулируя высокую задержку для оптимизатора для пользователей с паршивыми соединениями. В этой статье объясняется, что такое задержка, как она влияет на производительность, как измерить задержку и как ее уменьшить.
Использование dns-prefetch
DNS-prefetch — это попытка разрешить доменные имена до того, как будут запрошены ресурсы. Это может быть файл, загруженный позже, или ссылка, по которой пользователь пытается перейти.

Учебники для начинающих

Область обучения MDN Web Performance содержит современные учебные пособия по основам производительности. Начните здесь, если вы новичок в производительности:

Веб-производительность: краткий обзор
Обзор пути обучения веб-производительности. Начните свое путешествие здесь.
Что такое веб-производительность?
Эта статья начинает модуль с хорошего взгляда на то, что такое производительность на самом деле — это включает инструменты, метрики, API, сети и группы людей, которые нам нужно учитывать, думая о производительности, и как мы можем сделать производительность частью нашей рабочий процесс веб-разработки.
Как пользователи воспринимают производительность?

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

Основы веб-производительности
В дополнение к интерфейсным компонентам HTML, CSS, JavaScript и мультимедийным файлам, существуют функции, которые могут замедлить работу приложений, и функции, которые могут сделать приложения субъективно и объективно быстрее. Существует множество API-интерфейсов, инструментов разработчика, передовых и плохих практик, связанных с производительностью в Интернете. Здесь мы представим многие из этих функций на базовом уровне и дадим ссылки на более глубокие погружения для повышения эффективности по каждой теме.
Характеристики производительности HTML
Некоторые атрибуты и исходный порядок вашей разметки могут повлиять на производительность вашего веб-сайта. Сведя к минимуму количество узлов DOM, убедившись, что для включения контента, такого как стили, скрипты, мультимедиа и сторонние скрипты, используются наилучший порядок и атрибуты, вы можете значительно улучшить взаимодействие с пользователем. В этой статье подробно рассматривается, как можно использовать HTML для обеспечения максимальной производительности.
Мультимедиа: изображения и видео
Самым слабым плодом веб-производительности часто является оптимизация мультимедиа.Возможно обслуживание различных медиафайлов в зависимости от возможностей, размера и плотности пикселей каждого пользовательского агента. Дополнительные советы, такие как удаление звуковых дорожек из фоновых видеороликов, могут еще больше повысить производительность. В этой статье мы обсуждаем влияние видео-, аудио- и графического контента на производительность, а также методы, позволяющие минимизировать это влияние.
Характеристики производительности CSS
CSS может быть менее важным направлением оптимизации для повышения производительности, но есть некоторые функции CSS, которые влияют на производительность больше, чем другие.В этой статье мы рассмотрим некоторые свойства CSS, которые влияют на производительность, и предложим способы обработки стилей, чтобы не повлиять на производительность.
Рекомендации по производительности JavaScript
JavaScript, при правильном использовании, может обеспечить интерактивный и иммерсивный веб-опыт — или он может значительно снизить время загрузки, время рендеринга, производительность в приложении, время автономной работы и взаимодействие с пользователем. В этой статье описаны некоторые передовые практики JavaScript, которые следует учитывать, чтобы обеспечить максимальную производительность даже сложного контента.
Мобильная производительность
Поскольку доступ в Интернет на мобильных устройствах настолько популярен, и все мобильные платформы имеют полнофункциональные веб-браузеры, но, возможно, имеют ограниченную пропускную способность, процессор и время автономной работы, важно учитывать производительность вашего веб-контента на этих платформах. В этой статье рассматриваются особенности производительности мобильных устройств.
Рекомендации по производительности JavaScript
JavaScript при правильном использовании может обеспечить интерактивный и иммерсивный веб-опыт…. или это может значительно повлиять на время загрузки, время рендеринга, производительность приложения, время автономной работы и взаимодействие с пользователем. В этой статье описываются некоторые передовые практики JavaScript, которые могут обеспечить максимальную производительность даже сложного контента.
Мобильная производительность
Поскольку доступ в Интернет на мобильных устройствах настолько популярен, и все мобильные платформы имеют полнофункциональные веб-браузеры, но, возможно, имеют ограниченную пропускную способность, процессор и время автономной работы, важно учитывать производительность вашего веб-контента на этих платформах.В этой статье также рассматриваются вопросы производительности для мобильных устройств.
Производительность веб-шрифтов
Веб-шрифты — это часто упускаемый из виду аспект производительности. Веб-шрифты сейчас более заметны в веб-дизайне, чем когда-либо, но многие разработчики встраивают их из сторонних сервисов и ничего об этом не думают. В этой статье мы рассмотрим способы уменьшения размера файлов шрифтов с помощью эффективных форматов файлов и дополнительных настроек. Далее мы поговорим о том, как браузеры передают текст и как вы можете использовать функции CSS и JavaScript, чтобы ваши шрифты отображались быстро и с минимальным нарушением взаимодействия с пользователем.
Узкие места в производительности
Пропускная способность
Пропускная способность — это объем данных, измеряемый в мегабитах (МБ) или килобитах (КБ), которые можно отправлять в секунду. В этой статье объясняется роль пропускной способности в мультимедийных интернет-приложениях, способы ее измерения и способы оптимизации приложений, чтобы максимально использовать доступную пропускную способность
Роль TLS в производительности
TLS — или HTTPS, как мы его обычно называем — имеет решающее значение для создания безопасного и безопасного взаимодействия с пользователем.Хотя оборудование уменьшило негативное влияние TLS на производительность серверов, оно по-прежнему представляет собой значительную часть времени, которое мы тратим на ожидание подключения браузеров к серверам. В этой статье объясняется процесс установления связи TLS и предлагаются некоторые советы по сокращению этого времени, такие как сшивание OCSP, заголовки предварительной загрузки HSTS и потенциальная роль подсказок ресурсов в маскировке задержки TLS для третьих сторон.
Диаграммы показателей чтения
Инструменты разработчика предоставляют информацию о производительности, памяти и сетевых запросах.Знание того, как читать диаграммы водопада, деревья вызовов, трассировки, диаграммы пламени и распределения в инструментах разработчика вашего браузера, поможет вам понять диаграммы водопада и пламени в других инструментах производительности.
Альтернативные форматы мультимедиа
Когда дело доходит до изображений и видео, существует больше форматов, чем вы, вероятно, знаете. Некоторые из этих форматов могут продвинуть ваши высокооптимизированные мультимедийные страницы еще дальше, предлагая дополнительное уменьшение размера файла. В этом руководстве мы обсудим некоторые альтернативные форматы мультимедиа, как использовать их ответственно, чтобы не поддерживающие браузеры не остались незамеченными, а также некоторые расширенные рекомендации по перекодированию в них существующих ресурсов.
Анализ пакетов JavaScript
Несомненно, JavaScript — большая часть современной веб-разработки. Хотя вы всегда должны стремиться сократить объем JavaScript, который вы используете в своих приложениях, бывает сложно понять, с чего начать. В этом руководстве мы покажем вам, как анализировать пакеты сценариев вашего приложения, чтобы вы знали, какой вы используете, а также как определить, содержит ли ваше приложение повторяющиеся сценарии между пакетами.
Ленивая загрузка
Не всегда необходимо загружать все ресурсы веб-приложения при начальной загрузке страницы.Ленивая загрузка откладывает загрузку ресурсов на странице, таких как скрипты, изображения и т. Д., На более поздний момент времени, то есть когда эти ресурсы действительно необходимы.
Ленивая загрузка JavaScript с динамическим импортом
Когда разработчики слышат термин «отложенная загрузка», они сразу же думают о нижних изображениях, которые загружаются при прокрутке в область просмотра. Но знаете ли вы, что можно также отложить загрузку JavaScript? В этом руководстве мы поговорим о динамическом операторе import (), который является функцией современных браузеров, которая загружает модуль JavaScript по запросу.Конечно, поскольку эта функция доступна не везде, мы также покажем вам, как настроить инструменты для использования этой функции широко совместимым образом.
Управление доставкой ресурсов с помощью подсказок ресурсов
Браузеры часто лучше нас знают, когда дело доходит до приоритезации ресурсов и их доставки, однако они далеки от очевидности. Встроенные функции браузера позволяют нам подсказывать браузеру, когда ему следует подключиться к другому серверу, или предварительно загружать ресурс до того, как браузер узнает, что он когда-либо понадобится.При разумном использовании это может сделать быстрый опыт еще быстрее. В этой статье мы расскажем о встроенных функциях браузера, таких как rel = preconnect, rel = dns-prefetch, rel = prefetch и rel = preload, а также о том, как их использовать в ваших интересах.
Бюджеты производительности
Потребности в маркетинге, дизайне и продажах, а также опыт разработчиков, часто раздуваемая реклама, сторонние скрипты и другие функции, которые могут снизить производительность в Интернете. Чтобы помочь установить приоритеты, полезно установить бюджет производительности: набор ограничений, которые нельзя превышать на этапе разработки.В этой статье мы обсудим создание и соблюдение бюджета производительности.
Контрольный список для проверки веб-производительности
Контрольный список функций, которые следует учитывать при разработке приложений, со ссылками на руководства по реализации каждой функции, включая сервис-воркеров, диагностику проблем с производительностью, рекомендации по загрузке шрифтов, подсказки для клиентов, создание эффективных анимаций и т. Д.
Контрольный список мобильной производительности
Краткий контрольный список соображений производительности, влияющих на пользователей мобильной сети на портативных устройствах с батарейным питанием.

HTML

CSS

  • будет меняться
  • GPU против CPU
  • Измерительная схема
  • Рекомендации по загрузке шрифтов

JavaScript

API

Заголовки

Инструменты

Дополнительные показатели

  • Индекс скорости и индекс скорости восприятия

Лучшие Лрактики

показателей скорости страницы — FullStory Support

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

Какие показатели скорости страницы фиксирует FullStory?

В потоке событий для любого воспроизведения сеанса FullStory покажет три ключевых показателя для каждой посещенной страницы:

Первая насыщенная краска (FCP)

Событие First Contentful Paint относится к моменту, когда первый элемент из DOM появляется в браузере пользователя.

Здесь, в FullStory, мы считаем, что этот показатель наиболее тесно связан с восприятием пользователем страницы, которая будет «загружена», и мы используем FCP в качестве нашего собственного эталона скорости загрузки страницы.

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

Примечание. FCP исключает содержимое с iframe.

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

Подробнее об этой метрике читайте в документации для разработчиков Lighthouse.

DOMContentLoaded (DCL)

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

Более конкретно, DOMContentLoaded срабатывает, когда исходный HTML-документ загружен и проанализирован. Часто этот этап происходит до завершения загрузки таблиц стилей, изображений и подфреймов, поэтому событие DOMContentLoaded происходит за до , когда страница будет отрисована.

Таблицы стилей, шрифты и JavaScript

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

Подробнее об этой метрике читайте в документации для разработчиков Mozilla.

Загрузка страницы

Событие onload или «Загрузка страницы» срабатывает, когда вся страница и все зависимые от нее ресурсы завершили загрузку.

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

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

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

Дополнительные сведения о загрузке страницы см. В документации разработчика Mozilla.

Просмотр сети и файла HAR

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

Сетевое представление позволяет анализировать, что произошло во время загрузки страницы. Узнайте больше об использовании представления сети в FullStory.

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

Файл HAR — это стандартный формат для просмотра ресурсов, которые способствуют загрузке страницы в представлении «водопадная диаграмма». Файл HAR загружается в формате .json / .har и включает подробное время запроса, информацию о DNS, размеры активов и сведения о подключении к серверу.Помимо FullStory, вы можете визуализировать файлы .har с помощью инструментов разработчика Chrome (просто перетащите файл на пустую вкладку «Сеть» в своем браузере!) Или инструмента HAR Analyzer от Google.

Как мне искать сеансы с медленными страницами?

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

Есть два способа поиска сеансов с медленными страницами.Вы можете либо:

Поиск медленных страниц с помощью OmniSearch

Чтобы начать новый поиск, щелкните панель OmniSearch и найдите критерий «Загрузка страницы» в разделе «Производительность».

Щелкните «Загрузка страницы», чтобы начать новый поиск с критериями загрузки страницы.

Затем используйте раскрывающееся меню, чтобы выбрать метрику для поиска: First Contentful Paint, DOMContentLoaded или Page Load.

Затем обновите критерии для поиска сеансов, когда страница была не менее определенного количества секунд.

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

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

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

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

Этот метод запуска поиска особенно полезен, если вы видите что-то подозрительное во время сеанса и хотите быстро понять: «Как другие клиенты видели сеансы, в которых страницы загружались аналогично загрузке этой страницы?»

FullStory Page Speed ​​Metrics и профилировщик производительности Chrome

Если вы использовали профилировщик производительности Google Chrome, вы могли заметить, что данные в профилировщике производительности не соответствуют числам, которые вы видите в FullStory. Это связано с тем, что, когда вы выбираете «начать профилирование и перезагрузить страницу» в профилировщике производительности Chrome, показатели скорости страницы в Chrome берутся с момента нажатия кнопки, включая e.грамм. выгрузить обработчики с предыдущей страницы. Напротив, показатели скорости страницы FullStory, которые основаны на API производительности браузера (например), относятся к «navigationStart».

Для иллюстрации, если вы запускаете профилировщик производительности Chrome на странице и первая отрисовка содержимого (FCP) отображается как 851,8 мс при начальном значении навигации 299,31, вы заметите, что значение FCP в FullStory будет 552,49. Значение 552,49, полученное из API производительности браузера, как раз и является разницей между тем, что профилировщик производительности Chrome сообщил для FCP и начала навигации.

.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *