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

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

W3C работал над этим с помощью новых Event Timing и Element Timing API и определил несколько новых показателей Web Vital для описания различных способов, которыми низкая производительность может повлиять на веб-страницу. Google даже собирается использовать эти жизненно важные веб-метрики в качестве фактора ранжирования в поиске!

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

1. Самая большая содержательная краска (LCP)

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

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

Веб-страницы, которые отображают только фрейм пользовательского интерфейса в основном документе и загружают контент асинхронно, будут иметь низкие оценки LCP. Забавный факт, недавно мы проверили эффективность поиска Google в Интернете, и они встроили почти все содержимое в исходный документ!

Узнайте больше о самой большой Contentful Paint

2. Совокупный сдвиг макета (CLS)

Непослушные веб-страницы, которые постоянно перемещаются, рисуют новый контент и смещают то, что вы пытались прочитать, имеют много Сдвиг макета. Сдвиг макета происходит всякий раз, когда новые элементы, добавленные на страницу, перемещают размещение других элементов. Как рекламный рендеринг поверх абзаца, который вы хотели прочитать. Глядя на вас The New York Times.

Совокупное смещение макета (CLS) – это сумма всех сдвигов макета на странице. Когда много асинхронного контента, происходит много смен макета и высокий CLS.

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

Подробнее о накопительном смещении макета.

3. Задержка первого ввода (FID)

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

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

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

Подробнее о задержке первого ввода

Измерение ваших веб-показателей

Теперь, когда мы знаем концепцию этих жизненно важных показателей, как их измерить? Все они основаны на черновой спецификации Element Timing API, которая еще не принята должным образом. Chrome (и другие браузеры на основе Blink) поддерживают это уже сегодня, поэтому вы можете начать собирать эти показатели для некоторых ваших пользователей.

try {
    new PerformanceObserver(entryList => {
      entryList.getEntries().forEach(console.log)
    }).observe({ type: "layout-shift", buffered: true });

    new PerformanceObserver(entryList => {
      entryList.getEntries().forEach(console.log)
    }).observe({ type: "largest-contentful-paint", buffered: true });

    new PerformanceObserver(entryList => {
      entryList.getEntries().forEach(console.log)
    }).observe({ type: "first-input", buffered: true });
}
catch(e) { /* API is not supported */ }

Измерение каждого из этих типов имеет свои особенности и особые условия. Например, чтобы обработать "layout-shift", нам нужно суммировать все значения, которые мы получаем, потому что мы измеряем кумулятивный сдвиг макета. Мы также должны учитывать, было ли смещение макета вызвано пользовательским вводом, который является одним из настраиваемых свойств, прикрепленных к этой записи.

let cumulativeLayoutShift = 0;
function handleLayoutShift(entry) {
  if (!entry.hadRecentInput) {
    cumulativeLayoutShift += entry.value;
  }
}

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

Или Request Metrics может сделать это за вас! Показатели запросов — это самый быстрый, простой и самый дешевый способ понять реальную эффективность работы пользователей в Интернете. Он может собирать эти показатели вместе с кучей других полезных данных и выделять из них то, что действительно важно. Все всего за 10 долларов в месяц.

Это намного проще, чем самому гоняться за этими движущимися API.

Пойдем быстро.

Первоначально опубликовано на https://davidwalsh.name 21 сентября 2020 г.