Люди говорят, что сайты JAMstack быстрые — давайте узнаем почему, посмотрев на реальные показатели производительности! Мы рассмотрим общие метрики, такие как время до первого байта ( TTFB ) и другие, а затем сравним данные по широкому разделу сайтов, чтобы увидеть, как сравниваются различные способы разделения этих сайтов.
Во-первых, я хотел бы представить небольшой анализ, чтобы дать некоторую справочную информацию. Согласно отчету о показателях HTTPArchive при загрузке страницы, пользователи ждут в среднем 6,7 секунд чтобы увидеть основной контент.
First Contentful Paint (FCP) — измеряет точку, в которой текст или графика впервые отображаются на экране.
Если речь идет о взаимодействии со страницей (Время до Интерактив), пользователи ждут еще дольше. Среднее время для интерактивной работы составляет 9,3 секунды .
Time to Interactive (TTI) — время, когда пользователь может взаимодействовать со страницей без задержки.
Содержание статьи
Состояние реальной производительности веб-пользователя
Приведенные выше данные взяты из лабораторного мониторинга и не полностью отражают реальный опыт пользователя. Данные реальных пользователей, взятые из отчета Chrome User Experience Report (CrUX), показывают еще более широкую картину.
Я буду использовать данные, полученные от пользователей мобильных устройств. В частности, мы будем использовать такие метрики, как:
Время до первого байта
TTFB представляет время, которое браузер ожидает получения первых байтов ответа от сервера. TTFB длится от 200 мс до 1 секунды для пользователей по всему миру. Достаточно много времени, чтобы получить первые куски страницы.
Первая содержательная краска
FCP происходит через 2,5 секунды для 23% просмотров страниц по всему миру.
Первая задержка ввода
Метрики FID показывают, как быстро веб-страницы реагируют на ввод пользователя (например, щелчок, прокрутка и т. Д.).
CrUX не имеет данных TTI из-за различных ограничений, но имеет FID что еще лучше может отражать интерактивность страниц. Более 75% опыта пользователей мобильных устройств имеют задержку ввода на 50 мс, и пользователи не испытывали никакого рывка.
Вы можете использовать запросы ниже и играть с ними на этом сайте ,
Данные за июль 2019 г.
[
{
"date": "2019_07_01",
"timestamp": "1561939200000",
"client": "desktop",
"fastTTFB": "27.33",
"avgTTFB": "46.24",
"slowTTFB": "26.43",
"fastFCP": "48.99",
"avgFCP": "33.17",
"slowFCP": "17.84",
"fastFID": "95.78",
"avgFID": "2.79",
"slowFID": "1.43"
},
{
"date": "2019_07_01",
"timestamp": "1561939200000",
"client": "mobile",
"fastTTFB": "23.61",
"avgTTFB": "46.49",
"slowTTFB": "29.89",
"fastFCP": "38.58",
"avgFCP": "38.28",
"slowFCP": "23.14",
"fastFID": "75.13",
"avgFID": "17.95",
"slowFID": "6.92"
}
]
BigQuery
#standardSQL
ВЫБРАТЬ
REGEXP_REPLACE (ггггмм, '(\ d {4}) (\ d {2})', '\ 1 _ \ 2_01') AS дата,
UNIX_DATE (CAST (REGEXP_REPLACE (ггггмм, '(\ d {4}) (\ d {2})', '\ 1 - \ 2-01') в качестве даты)) * 1000 * 60 * 60 * 24 AS отметка времени,
Клиент IF (device = 'desktop', 'desktop', 'mobile'),
ROUND (SUM (fast_fcp) * 100 / (SUM (fast_fcp) + SUM (avg_fcp) + SUM (slow_fcp)), 2) AS fastFCP,
ROUND (SUM (avg_fcp) * 100 / (SUM (fast_fcp) + SUM (avg_fcp) + SUM (slow_fcp)), 2) AS avgFCP,
ROUND (SUM (slow_fcp) * 100 / (SUM (fast_fcp) + SUM (avg_fcp) + SUM (slow_fcp)), 2) AS slowFCP,
ROUND (SUM (fast_fid) * 100 / (SUM (fast_fid) + SUM (avg_fid) + SUM (slow_fid)), 2) AS fastFID,
ROUND (SUM (avg_fid) * 100 / (SUM (fast_fid) + SUM (avg_fid) + SUM (slow_fid)), 2) AS avgFID,
ROUND (SUM (slow_fid) * 100 / (SUM (fast_fid) + SUM (avg_fid) + SUM (slow_fid)), 2) AS slowFID
ИЗ
`Хром-УБ-report.materialized.device_summary`
ГДЕ
ггггмм = '201907'
ГРУППА ПО
свидание,
метка времени,
клиент
СОРТИРОВАТЬ ПО
дата DESC,
Клиент
Состояние систем управления контентом ( CMS ) производительность
CMS s должны стать нашими спасителями, помогая нам создавать более быстрые сайты. Но, глядя на данные, дело не в этом. Текущее состояние производительности CMS во всем мире не так велико.
с июля 2019 года
[
{
"freq": "1548851",
"fast": "0.1951",
"avg": "0.4062",
"slow": "0.3987"
}
]
[
{
"freq": "1548851",
"fast": "0.1951",
"avg": "0.4062",
"slow": "0.3987"
}
]
BigQuery
#standardSQL
ВЫБРАТЬ
COUNT (различного происхождения) AS freq,
ROUND (SUM (ЕСЛИ (ttfb.start < 200, ttfb.density, 0)) / SUM(ttfb.density), 4) AS fastTTFB,
ROUND(SUM(IF(ttfb.start > = 200 И ttfb.start < 1000, ttfb.density, 0)) / SUM(ttfb.density), 4) AS avgTTFB,
ROUND(SUM(IF(ttfb.start > = 1000, ttfb.density, 0)) / SUM (ttfb.density), 4) AS slowTTFB
ИЗ
`Хром-UX-report.all.201907`,
UNNEST (экспериментальный. Time_to_first_byte.histogram.bin) AS ttfb
ПРИСОЕДИНИТЬСЯ (
ВЫБРАТЬ
URL,
приложение
ИЗ
`httparchive.technologies.2019_07_01_mobile`
ГДЕ
категория = 'CMS'
)
ON CONCAT (origin, '/') = url
СОРТИРОВАТЬ ПО
частота DESC
И вот результаты FCP :
По крайней мере Результаты FID немного лучше:
с июля 2019 года
[
{
"freq": "546415",
"fastFCP": "0.2873",
"avgFCP": "0.4187",
"slowFCP": "0.2941",
"fastFID": "0.8275",
"avgFID": "0.1183",
"slowFID": "0.0543"
}
]
[
{
"freq": "546415",
"fastFCP": "0.2873",
"avgFCP": "0.4187",
"slowFCP": "0.2941",
"fastFID": "0.8275",
"avgFID": "0.1183",
"slowFID": "0.0543"
}
] BigQuery
#standardSQL
ВЫБРАТЬ
COUNT (различного происхождения) AS freq,
ROUND (SUM (IF (fcp.start < 1000, fcp.density, 0)) / SUM(fcp.density), 4) AS fastFCP,
ROUND(SUM(IF(fcp.start > = 1000 AND fcp.start < 2500, fcp.density, 0)) / SUM(fcp.density), 4) AS avgFCP,
ROUND(SUM(IF(fcp.start > = 2500, fcp.density, 0)) / SUM (fcp.density), 4) AS slowFCP,
ROUND (SUM (IF (fid.start < 50, fid.density, 0)) / SUM(fid.density), 4) AS fastFID,
ROUND(SUM(IF(fid.start > = 50 AND fid.start < 250, fid.density, 0)) / SUM(fid.density), 4) AS avgFID,
ROUND(SUM(IF(fid.start > = 250, fid.density, 0)) / SUM (fid.density), 4) AS slowFID
ИЗ
`Хром-UX-report.all.201907`,
UNNEST (first_contentful_paint.histogram.bin) AS fcp,
UNNEST (эксперимент.ф.р._процесса.histogram.bin) AS fid
ПРИСОЕДИНИТЬСЯ (
ВЫБРАТЬ
URL,
приложение
ИЗ
`httparchive.technologies.2019_07_01_mobile`
ГДЕ
категория = 'CMS'
)
ON CONCAT (origin, '/') = url
СОРТИРОВАТЬ ПО
частота DESC
Как видите, сайты, созданные с помощью CMS, работают не намного лучше, чем общая производительность сайтов в Интернете.
Вы можете найти распределение производительности по различным CMS на в этом обсуждении на форуме HTTPArchive.
Веб-сайты электронной коммерции, хороший пример сайтов, которые, как правило, построены на CMS имеют очень плохую статистику для просмотров страниц:
- ~ 40% — 1 секунда для TTFB
- ~ 30% — более 1,5 секунды для FCP
- ~ 12% — отставание от взаимодействия страниц.
Я сталкивался с клиентами, которые запрашивали поддержку IE 10- IE 11, потому что трафик этих пользователей составлял 1%, что равнялось миллионам долларов дохода. Пожалуйста, рассчитайте свои потери в случае, если 1% пользователей уйдут немедленно и не вернутся из-за плохой работы. Если пользователи недовольны, бизнес тоже будет несчастлив.
Чтобы получить более подробную информацию о том, как производительность сети соотносится с доходами, посмотрите WPO Stats. Это список примеров из реальных компаний и их успехов после повышения производительности.
JAMstack помогает повысить производительность сети
С помощью JAMstack разработчики выполняют как можно меньше рендеринга на клиенте, вместо этого используя серверную инфраструктуру для большинства вещей. Не говоря уже о том, что большинство рабочих процессов JAMstack отлично справляются с развертыванием и помогают с масштабируемостью, помимо прочих преимуществ. Содержимое хранится статически на хостах статических файлов и предоставляется пользователям через CDN .
Прочтите Матье Дионн «Новичок в JAMstack? Все, что нужно знать, чтобы начать работу», чтобы узнать, как лучше познакомиться с JAMstack.
У меня было два года опыта работы с одной из популярных CMS для электронной коммерции, и у нас было много проблем с развертыванием, производительностью, масштабируемостью. Команда будет проводить дни и чинить их. Это не то, что хотят клиенты. Такого рода большие проблемы решает JAMstack.
Глядя на данные CrUX, производительность сайтов JAMstack выглядит действительно солидно. Следующие значения основаны на сайтах, обслуживаемых Netlify и GitHub. На форуме по архиву HTTP HTTP обсуждается, где вы можете участвовать, чтобы сделать данные более точными.
Вот результаты для TTFB :
Данные за июль 2019 г.
[
{
"n": "7627",
"fastTTFB": "0.377",
"avgTTFB": "0.5032",
"slowTTFB": "0.1198"
}
]
BigQuery
#standardSQL
ВЫБРАТЬ
COUNT (различного происхождения) AS n,
ROUND (SUM (ЕСЛИ (ttfb.start < 200, ttfb.density, 0)) / SUM(ttfb.density), 4) AS fastTTFB,
ROUND(SUM(IF(ttfb.start > = 200 И ttfb.start < 1000, ttfb.density, 0)) / SUM(ttfb.density), 4) AS avgTTFB,
ROUND(SUM(IF(ttfb.start > = 1000, ttfb.density, 0)) / SUM (ttfb.density), 4) AS slowTTFB
ИЗ
`Хром-UX-report.all.201907`,
UNNEST (экспериментальный. Time_to_first_byte.histogram.bin) AS ttfb
ПРИСОЕДИНИТЬСЯ
(ВЫБЕРИТЕ url, REGEXP_EXTRACT (LOWER (CONCAT (respOtherHeaders, resp_x_powered_by, resp_via, resp_server)),
'(Netlify | х-GitHub-запрос)')
AS платформа
FROM `httparchive.summary_requests.2019_07_01_mobile`)
НА
CONCAT (origin, '/') = url
ГДЕ
Платформа НЕ НУЛЬ
СОРТИРОВАТЬ ПО
n DESC
Вот как FCP вытряхнул:
давайте посмотрим на FID :
Данные за июль 2019 г.
[
{
"n": "4136",
"fastFCP": "0.5552",
"avgFCP": "0.3126",
"slowFCP": "0.1323",
"fastFID": "0.9263",
"avgFID": "0.0497",
"slowFID": "0.024"
}
]
BigQuery
#standardSQL
ВЫБРАТЬ
COUNT (различного происхождения) AS n,
ROUND (SUM (IF (fcp.start < 1000, fcp.density, 0)) / SUM(fcp.density), 4) AS fastFCP,
ROUND(SUM(IF(fcp.start > = 1000 AND fcp.start < 2500, fcp.density, 0)) / SUM(fcp.density), 4) AS avgFCP,
ROUND(SUM(IF(fcp.start > = 2500, fcp.density, 0)) / SUM (fcp.density), 4) AS slowFCP,
ROUND (SUM (IF (fid.start < 50, fid.density, 0)) / SUM(fid.density), 4) AS fastFID,
ROUND(SUM(IF(fid.start > = 50 AND fid.start < 250, fid.density, 0)) / SUM(fid.density), 4) AS avgFID,
ROUND(SUM(IF(fid.start > = 250, fid.density, 0)) / SUM (fid.density), 4) AS slowFID
ИЗ
`Хром-UX-report.all.201907`,
UNNEST (first_contentful_paint.histogram.bin) AS fcp,
UNNEST (эксперимент.ф.р._процесса.histogram.bin) AS fid
ПРИСОЕДИНИТЬСЯ
(ВЫБЕРИТЕ url, REGEXP_EXTRACT (LOWER (CONCAT (respOtherHeaders, resp_x_powered_by, resp_via, resp_server)),
'(Netlify | х-GitHub-запрос)')
AS платформа
FROM `httparchive.summary_requests.2019_07_01_mobile`)
НА
CONCAT (origin, '/') = url
ГДЕ
Платформа НЕ НУЛЬ
СОРТИРОВАТЬ ПО
n DESC
Цифры показывают, что производительность сайтов JAMstack является лучшей. Цифры практически одинаковы для мобильных и настольных компьютеров, что еще более удивительно!
Некоторые основные моменты от технических лидеров
Позвольте мне показать вам пару примеров от некоторых известных людей в отрасли:
Из 468 миллионов запросов в @HTTPArchive 48% не были обслужены из CDN. Я визуализировал, где они подавались снизу. Многие из них были просьбами к третьим лицам. Клиент, запрашивающий их, находился в Редвуд-Сити, штат Калифорния. Задержка имеет значение. #WebPerf pic.twitter.com/0F7nFa1QgM
— Пол Кальвано (@paulcalvano) 29 августа 2019 года
Сайты JAMstack, как правило, CDN -хостинг и смягчают TTFB . Поскольку хостинг файлов обрабатывается инфраструктурами, такими как Amazon Web Services или аналогичными, производительность всех сайтов может быть улучшена за одно исправление.
Еще одно реальное исследование говорит о том, что лучше предоставлять статический HTML для лучшего FCP .
Какое время лучше для первого осмысленного рисования?
① необработанный HTML-файл объемом 8,5 МБ с полным текстом каждого из моих 27506 твитов
client клиент предоставил React-сайт с ровно одним твитом(Спойлер: @____lighthouse сообщает, что HTML выигрывает 8,5 МБ примерно на 200 мс)
— Зак Лезерман (@zachleat) 6 сентября 2019 года
Вот сравнение всех результатов, показанных выше вместе:
JAMstack повышает производительность сети благодаря статически обслуживающие страницы с CDN с. Это важно, потому что быстрый бэкэнд, который занимает много времени, чтобы добраться до пользователей, будет медленным, и аналогично, медленный бэкэнд, который быстро достигает пользователей, также будет медленным.
JAMstack еще не выиграл гонку перфектов, потому что количество сайтов, созданных с его помощью, не так велико, как, например, для CMS, но намерение выиграть его действительно велико.
Добавление этих показателей к бюджету производительности может быть одним из способов убедиться, что вы обеспечиваете хорошую производительность в своем рабочем процессе. Что-то вроде:
- TTFB : 200 мс
- FCP : 1с
- FID : 50 мс
Проведите это с умом 🙂
Примечание редактора: Артем Денисов из Stackbit, который представляет собой сервис, который чрезвычайно помогает вращать сайты JAMstack и предоставляет новые инструменты для сглаживания некоторых ребер рабочего процесса с помощью JAMstack сайты и контент. Артем сказал, что хотел бы поблагодарить Рика Вискоми, Роба Остина и Алексея Куликова за помощь в рецензировании статьи.
Загрузка...
