Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Як з якісним моніторингом досягти показників перформансу сайту на рівні 95+

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Усім привіт, я Богдан Кладковий, Delivery Manager в компанії АМО. Продовжую ділитися крутими порадами, як покращити показники Google Core Web Vitals на прикладі сайту Amomama. Цього разу ми з Анною Шкульовою, QA Automation, вирішили трохи поговорити про моніторинг показників з Google. А саме: як за допомогою моніторинга показників перформансу ми перестали хвилюватися, який вплив на них має та чи інша фіча.

Ми перестали чекати фідбеку з польових даних (field data) аж до 28 днів, та майже в реальному часі спостерігаємо і моментально реагуємо на ті чи інші фактори, які впливають на наш перформанс.

Нагадаю, Amomama — цілком ‘органічний’ продукт, і одним з основних джерел трафіку в нас є Google. Отже, нам необхідно постійно «тримати руку на пульсі», щоб наші показники завжди залишалися зеленими.

В цій статті ми поділимося технологією, яку використовуємо для моніторингу та покроковим налаштуванням саме імітації польових даних.

Для комфортного споживання матеріалу підготували для вас зміст:

  • Що таке lab та field data.
  • Інструменти вимірювання та моніторингу Google Core Web Vitals, їх переваги та недоліки.
  • Що ми обрали для себе і як це використовуємо.
  • Налаштування нашої системи моніторингу.
  • Як ми вимірюємо field data в реальному часі та її налаштування.
  • Висновки.

Що таке lab та field data

А поки, нагадаймо собі, що Google вважає лабораторними даними (надалі — lab data), а що — польовими (field data). Якщо дуже коротко, то під лабораторними даними Google має на увазі результати прогону виключно під конкретний девайс та під перший екран, тобто під перший viewport. Наприклад, Lighthouse за замовчуванням робить прогін на Moto G4 з повільним 4G.

Але з виходом нового Google Chrome v.103, компанія також презентувала нову версію Lighthouse, з ним можна вимірювати лабораторні дані не тільки для першого екрану, а й лабораторно імітувати field data, хоча під капотом цієї імітації є ще доволі сирий Lighthouse user flows. Але це вже дуже допомагає при тестуванні Core Web Vitals, про це трохи згодом.

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

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

Оскільки польові дані ґрунтуються на відвідуваннях реальних користувачів, вони зображають фактичні пристрої, мережеві умови та географічне розташування ваших користувачів. Що дуже важко підтримувати та передбачити за допомогою лабораторних вимірів, дані по яких були зібрані в контрольованому середовищі із заздалегідь визначеними параметрами пристрою та мережі.

Впливати на польові дані досить важко, оскільки в нас не один сайт і не одна локація, на яких переважна більшість користувачів мають несучасні мобільні пристрої, застарілі версії браузерів, а ще й бонусом — погане інтернет-зʼєднання (fast 3G або slow 3G).

Але ми не можемо вимкнути або заблокувати наш сайт для таких локацій, тому що наша основна задача — надавати нашим користувачам якісний та цікавий контент для будь-якої локації та інтернет-зʼєднання. Отже, для розвитку та підтримки основного сайту та таких локацій ми почали створювати чіткий та якісний моніторинг польових даних, який би допоміг нам для кожного користувача швидко та безперебійно надавати сайт для споживання розважального контенту.

Інструменти вимірювання та моніторингу Google Core Web Vitals, їх переваги та недоліки

Спочатку поговоримо про те, з чого ми починали і як дійшли до еталонного рішення в нашому випадку.

Класифікуймо інструменти для вимірювання і відстеження польових та лабораторних даних, які пропонує сам Google:

PageSpeed Insights — потужний інструмент, який дозволяє одразу переглядати польові та лабораторні дані по конкретному посиланню та по джерелу (origin), що є його величезним плюсом.

Водночас хотілось би зазначити деякі його недоліки:

  • потрібно постійно проглядати польові дані (з затримкою), і за потреби вести мануально репорт, наприклад в exel. Дуже незручно;
  • немає іcторичних даних, а тільки актуальний стан за ключовими метриками.

Field data:

Lab data:

Chrome UX Report(CrUX) — це загальнодоступний набір даних про реальний користувацький досвід на сайтах. Він вимірює польові показники всіх основних гуглових метрик.

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

Базується цей репортинг на даних з BigQuery. Набір даних CrUX на BigQuery включає детальні дані про Core Web Vitals для всіх ключових показників, і доступний у вигляді щомісячних репортів на рівні джерела (origin). Щоб згенерувати репорт по сайту, можна скористатися цим посиланням.

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

Переваги:

  • надає чітку картину по Core Web Vitals за місяць та минулі періоди;
  • можливість створювати гнучкі репорти;
  • комфортна та зрозуміла робота через Data Studio;
  • автоматизація вивантаження репортів.

Недоліки:

  • репорти за минулий місяць зʼявляються тільки на другий вівторок наступного місяця;
  • якщо тягнути дані з BigQuery напряму, то це досить немалі витрати.
  • повільне реагування на зміни показників в ту чи іншу сторону.

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

Можливість ретроспективно переглядати зміни показників — реально круто.

А сам звіт CrUX виглядає наступним чином:

Search Console допомагає визначити групи сторінок на нашому сайті, які потребують уваги, на основі реальних (польових) даних з CrUX.

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

Одразу ясно, в якій зоні знаходиться сайт (зелена, жовта чи червона) і як, власне, це впливає на SEO. Наприклад:

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

Зайшовши в Search Console чітко зрозуміло, який стан справ :)

Переваги:

  • чіткість та прозорість;
  • без зайвих слів та тексту зрозуміло, яка ситуація з Core Web Vitals по сайту.

Недоліки:

  • щоб графік оновився до актуального стану по документації, потрібно чекати до 28 днів, але з досвіду можна сказати, що це займає до 2 тижнів;
  • дані приходять із затримкою в 2 дні, PageSpeed Insights дає трохи свіжіші дані;
  • для розробки, пошуку нових зон розвитку перформансу та оперативного реагування на проблеми Search Console, на жаль, нам не підходить.

Chrome Dev Tools та Web Vitals extension — тут навіть зупинятися не будемо, це must-have до використання під час розробки, швидкого тестування того чи іншого URL, локалізації та відтворення багів, повʼязаних з перформансом.

Але, проаналізувавши всі інструменти, які пропонує нам Google, ми не знайшли рішення, яке б допомогло нам швидко реагувати на проблеми та моніторити польові дані в реальному часі без довгого очікування, як ми це називаємо, «ще не настоялось».

Хоча ми навіть намагалися використовувати PageSpeedInsight API та виводити метрики в Grafana за допомогою Prometheus Exporter for Google Pagespeed Online Metrics, але користуючись цією API, ми зрозуміли, що це — багонута історія, яка не надає нам бажаного результату, тому вирішили обрати для себе інше рішення...

Що ми обрали для себе і як його використовуємо

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

Sitespeed — це набір інструментів з відкритим вихідним кодом, який дозволяє легко контролювати і вимірювати перформанс вашого сайту.

Нам дуже сподобалося позиціонування розробників цього чудового інструменту:

«Вимірювання продуктивності не повинно бути складним: ви повинні мати можливість повністю контролювати свої показники, володіти власними даними, і ви повинні мати можливість робити це, не платячи за це великі гроші. Ось чому ми створили sitespeed.io.»

А оскільки наша команда дуже поважає open-source, то ми просто не змогли пройти повз!

Крім цього, значними плюсами цього інструменту є:

  • швидка інсталяція (ви можете обирати підняти docker-контейнер чи встановити за допомогою npm; детальніше можна подивитися в документації);
  • можливість конфігурувати запуск безліччю способів, починаючи від браузера чи девайсу (мобайл чи десктоп), закінчуючи типом конекшена (3g, 3gfast і т.д.);
  • можливість взаємодіяти зі сторінкою (кліки, скрол і т.д.) та знімати метрики під час цього (це дуже важливо, адже один клік на якомусь дропдаун меню може суттєво погіршити метрики);
  • можливість налаштувати перфоманс дашборд, на якій зручно спостерігати за змінами метрик (детальніше можна почитати тут);
  • Також sitespeed постійно оновлюється, і розробники дуже оперативно реагують на нові зміни. Наприклад, коли гугл увів нові тестові метрики, то менше ніж за тиждень був новий реліз sitespeed, який включав ці метрики.

Звичайно мінуси також присутні, і, думаю, найбільший з них — це потреба запросити спеціаліста, який зможе налаштувати всю цю інфраструктуру та підтримувати її. Також в певний час ви можете просто потонути в кількості нової інформації та репортах, які будуть на вас сипатися.

Як саме ми організували моніторинг даних

Отже, ми визначилися, що sitespeed дуже гнучкий інструмент з купою цікавих можливостей. Тому розберімо, як саме ми налаштували процес тестування з його допомогою. І, якщо дуже спростити, то у нас є два типи перевірок: лабораторні дані на вибраних посиланнях та польові дані для вибраних постів.

Почнемо з того, як ми перевіряємо лабораторні дані. Невелике попередження: далі буде багато технічної інформації

Лабораторні дані

Тут ми тестуємо посилання в режимі first-view, тобто відкриваємо посилання та знімаємо метрики за допомогою sitespeed на першому view port-i. В результаті отримуємо папку з репортом.

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

Найперше, що ми бачимо — головна сторінка. Тут зібрані середні значення метрик, які нас цікавлять (їх вигляд та список можна конфігурувати, детальніше про це написано тут, але нас влаштувала конфігурація цієї сторінки «з коробки»).

До речі, тут ви бачите чотири червоні метрики з приставкою coach (coach overall score, coach performance score, coach privacy score і coach best practice score). Це внутрішня оцінка самого sitespeed ваших показників. З приємного: сам sitespeed в репорті відписує, що треба зробити, щоб ці показники покращити, але про це — за пару абзаців.

Також для кожної протестованої сторінки є детальний репорт. Тут ми бачимо конкретне посилання, яке тестуємо (на скриншоті — головна сторінка сайту news.amomama.com) і значення метрик саме для цієї сторінки, кількість ітерацій (All runs), на яких були зняті дані, і вибране середнє значення для кожного показника (в прикладі ми запускали тести тільки один раз, дефолтне налаштування sitespeed — три ітерації). Але найцікавіше ховається у вкладках video, filmstrip і coach.

Як можна здогадатися, на вкладці відео у нас відео. Його корисність в тому, що окрім сторінки там ще динамічно відображаються деякі візуальні метрики.

Так ми можемо відслідкувати момент, коли певна метрика погіршилася, і які дії на сторінці до цього привели.

Ще більше інформації по зміні показників в певний момент часу ховається у вкладці filmstrip. Тут лежать всі скріншоти, на яких відбулися певні зміни (не обов’язково візуальні). Також під скріншотами можна побачити зміни метрик.

З нашого списку залишилася тільки вкладка Coach. Трохи вище згадувалось про показники coach overall score, coach performance score, coach privacy score та coach best practice score і те, що вони у нас червоні. Так от, саме в цій вкладці ви знайдете детальну інструкцію що вам треба зробити, щоб покращити ці значення.

Добре, з репортом по верхах розібралися, але ж як його нарешті отримати? Для цього достатньо мати встановлений докер та запустити команду:

docker run --rm -v "$(pwd):/sitespeed.io" sitespeedio/sitespeed.io:[SITESPEED_VERSION] [URL_FOR_TEST]

Або варіант з додатковими опціями, який ми використовуємо у себе:

docker run --rm -v "$(pwd):/sitespeed.io" sitespeedio/sitespeed.io:[SITESPEED_VERSION] --config [PATH_TO_CONFIG_FILE].json --outputFolder [PATH_TO_FOLDER_WITH_REPORTS] [PATH_TO_FILE_WITH_URLS_FOR_TEST].txt

Де: SITESPEED_VERSION — версія sitespeed, за допомогою якої тестуємо; PATH_TO_CONFIG_FILE — конфіг-файл, в якому зберігаємо кількість ітерацій, браузер, тип девайсу і тд; PATH_TO_FOLDER_WITH_REPORTS — шлях до папки, в якій зберігаємо репорти, які потім будемо вивантажувати на s3, PATH_TO_FILE_WITH_URLS_FOR_TEST — шлях до файлу, в якому вказані всі посилання, які ми хочемо протестувати.

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

Польові дані для вибраних постів

Логіка цих тестів трохи складніша. По-перше, тут ми тестуємо тільки пости, адже це сторінки з найбільшою кількістю різноманітних елементів, які впливають на перформанс (реклама, ембеди, картинки і т.д.). І, найголовніше, — це основні сторінки, які цікавлять наших користувачів, на них йде 99.9% нашого трафіку, отже саме показники на цих сторінках і формують загальну картину перфомансу нашого сайту.

По-друге, тут ми використовуємо тестовий сценарій (скріпт), який повністю імітує дії користувача: відкриває сторінку, клікає на попапи, плавно скролить текст з затримками.

Для написання скріптів sitespeed надає три опції:

  • за допомогою їх власного врапера для JavaScript,
  • використовуючи JavaScript,
  • Selenium для NodeJS.

Як ви могли зрозуміти, від JavaScript нікуди не втекти. Для себе ми обрали врапер, бо, по-перше, наші основні автотести написані на JAVA, тому варіант з Selenium для NodeJS відпав. По-друге, врапер досить зручний, не потрібно самому описувати всі кліки, очікування тощо на JavaScript, за нас це вже зробили. По-третє, є зрозуміла дока, що максимально спрощує написання скриптів.

Нижче є приклад тесту, який відкриває потрібну сторінку (посилання ми передаємо в консольній команді), чекаємо, поки з’явиться поп-ап, погоджуємося на кукі і повільно скролимо сторінку до самого низу (тут ключове слово «повільно», адже реальний користувач на проскролює сторінку миттєво, а читає текст).

module.exports = async function (context, commands) {
//команда, яка дає зрозуміти sitespeed, що з цього моменту потрібно знімати метрики
  await commands.measure.start();
//відкриваємо посилання
  await commands.navigate(context.options.site);
// чекаємо і клікаємо на поп ап
  await commands.wait.byXpath( '//div[contains(@class, "qc-cmp2-summary-buttons")]', 12000);
  await commands.click.bySelector( '//div[contains(@class, "qc-cmp2-summary-buttons")]', 12000 ); 
//тут починається блок зі скролом
   try {
//дізнаємося висоту статті в пікселях
    var pixelToScroll = await commands.js.run( "return document.querySelector('div[data-io-article-url]').offsetHeight");
    do {
      await commands.scroll.byPixels(0, 100);
      await commands.wait.byTime(500);
      pixelToScroll = pixelToScroll - 100;
    } while (pixelToScroll > 100);
  } catch (e) {
    context.log.error('Could not scroll to read also');
  }
//завершуємо збір метрик
  return commands.measure.stop();
};

Щоб все це запустити, використовую команду:

docker run --rm -v "$(pwd):/sitespeed.io" sitespeedio/sitespeed.io:[SITESPEED_VERSION] --config [PATH_TO_CONFIG_FILE].json --browsertime.site=[URL_FOR_TEST] --outputFolder [PATH_TO_FOLDER_WITH_REPORTS] [PATH_TO_TEST_SCRIPT].js --multi

Де: SITESPEED_VERSION — версія sitespeed, за допомогою якої тестуємо, PATH_TO_CONFIG_FILE — конфіг-файл, в якому зберігаємо кількість ітерацій, браузер, тип девайсу і тд; PATH_TO_FOLDER_WITH_REPORTS — шлях до папки, в якій зберігаємо репорти, які потім будемо вивантажувати на s3, URL_FOR_TEST — посилання на пост, який тестуємо, PATH_TO_TEST_SCRIPT — шлях до тестового скрипта. Також тут ми бачимо ще один конфігураційний параметр --multi, який дає зрозуміти сайтспіду, що ми запускаємо тестовий сценарій.

Як можна було помітити, скролимо ми ну дуже повільно (по 100 пікселів кожні 500 мілісекунд до самого низу статті, а вони у нас чималенькі). Перевірка одного посту у нас займає в середньому дві з половиною хвилини. Як можна здогадатися, перевіряємо ми не одне посилання.

То навіщо нам ці тести, може, досить швидкої перевірки first view, але просто з більшою кількістю посилань? Але ні.

Досить довгий час наш показник CLS не підіймався вище жовтої зони. З технічної сторони ми перепробували багато варіантів, які були описані в нашій першій статті, але не могли досягти того результату, який би нас влаштував.

Після того, як ми почали запускати наші перші тести зі скролом, помітили на скріншотах, що показник CLS «стрибає» на одному конкретному елементі — рекламному відеоплеєрі. Цієї зміни на першому скріншоті не видно, адже відеоплеєр знаходиться нижче.

Досить довгий час ми спілкувалися з нашими партнерами, що надають нам цей плеєр, адже за всіма іншими параметрами він нас влаштовував і ми сподівалися, що вони зможуть зменшити вплив на CLS зі свого боку. І якраз таки довести, що проблема саме на його боці, а не на нашому, нам допомогли моніторинг і репорти sitespeed з даними з user timing api.

Інші налаштування sitespeed

У нас є два типи тестів. Перший — лабораторні дані (статична перевірка сторінок), другий — динамічний скрипт, який імітує реальну поведінку користувача. Але це ж явно ще не все. Окрім цього, є різні девайси, є користувачі з поганим інтернетом — і все це впливає на кінцевий показник загального перфомансу сайту, а значить, на них теж необхідно звертати увагу. І знову приходить на допомогу sitespeed з можливістю конфігурувати тести.

Отже, ми відслідковуємо показники для десктопу та мобайлу. Тести на десктопі запускаються по дефолту, а щоб запустити тести для Moto G4, на якому перевіряє мобайл перфоманс Google, достатньо до основної команди додати ключик --mobile (тест запуститься в Chrome, браузері за замовчуванням).

Також, як було згадано вище, наш сайт відвідують користувачі з різним інтернет-з’єднанням, а це теж впливає на кінцевий показник, який ми потім бачимо в гуглі.

Тому тести для різних конекшенів (для себе ми обрали тести на native, fast 3g та slow 4g) також повинні бути. В принципі, нічого космічного вигадувати не доведеться, бо сам sitespeed дає можливість конфігурувати різні конекшени. Для цього є інструмент Throttle (є досить детальна офіційна дока, тому не буду детально описувати налаштування та команди).

А тепер порахуймо: один сайт, два типи тестів, кожен з яких запускається на двох девайсах і на трьох типах конекшену. Виходить, тільки за один запуск тестів ви отримаєте 12 гарних і дуже об’ємних звітів, які потрібно проаналізувати.

І це я мовчу, що цей пак треба запустити набагато більше, ніж один раз, щоб мати повну картину і відслідковувати зміни на сайті в режимі реального часу. Як же ми вирішили цю проблему? На допомогу прийшла графана, з її гарними та зрозумілими графіками.

Для цього ми написали GitHub екшенси, які за тригером запускають тести кожні дві години та надсилають всі зібрані дані в InfluxDB («з коробки» sitespeed вміє надсилати дані в Graphite та InfluxDB), та створили дашбоард в графані, щоб в результаті отримати ось такі красиві графіки:

В принципі, щоб швидше отримати такий результат, можна використати json-файл з конфігураціями, який є в офіційному репозиторії sitespeed. А далі вже в конфігураціях Grafana доналаштувати вигляд бордів так, як вам буде зручніше.

Окей, ми побачили купу незрозумілих графіків, якихось параметрів і метрик. І тут з’являється досить логічне питання: як нам це допоможе? На наступному малюнку той самий борд, але вже з вибраним одним параметром — TTFB.

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

І тут ми підходимо до ще однієї задачі, яку нам допомагає вирішувати sitespeed. Тестування перформансу до моменту, як ми все виллємо на прод.

Як ми використовуємо sitespeed, окрім моніторингу

Постійне відслідковування метрик на проді — це завжди добре, але що робити з новими задачами, які потенційно впливають на перфоманс? Етап з виливанням на прод і очікуванням, поки воно «настоїться», ми вже пройшли. Так, ми зменшили період очікування цих даних, але все одно звучить непривабливо.

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

Так ми дійшли до запуску перфоманс тестів на пул реквестах.

Отже, після комунікації з тестувальниками та розробниками, ми для себе обрали наступний флоу. Є задача, яка потенційно вплине на показники, щоб не чекати змін в моніторингу і реагувати на них, є можливість запустити тести прямо у себе на пул реквесті. Для цього ми використовуємо GitHub action, який запускається, якщо поставити відповідну лейбу на пр-і. Чому саме лейба? Все досить просто: не всі задачі впливають на перфоманс, а запускати тести там, де це не потрібно — це затратно і створює величезну кількість репортів.

Ось приклад екшенсу, за допомогою якого ми запускаємо тести:

name: sitespeed.io

on:
  workflow_dispatch:
  pull_request:
    types: [ labeled ]

jobs:
  run-sitespeed-desktop:
    if: github.event.label.name == 'Run Performance'
    runs-on:

    steps:
//робимо чекаут на відповідну гілку розробки
      - name: code checkout
        uses: actions/checkout@v2

//запускаємо локальну збірку проекту
      - name: Build Front
        run: ./bootstrap-loc.sh

//запуск тестів для first view перевірки
      - name: running test for desktop (static)
        run: |
          docker run --add-host amomama.loc:172.17.0.1 -v "$(pwd):/sitespeed.io" --network=host \
          sitespeedio/sitespeed.io:25.3.2 --config [CONFIG_FILE].json 
          --outputFolder [REPORT_FOLDER] [URLS_FOR_TEST].txt \
//перформанс бюджет
          --budget.configPath [BUDGET_FILE].json

//вивантажуємо репорт на s3
      - name: Upload reports on S3
        id: report-sitespeed
        uses: shallwefootball/s3-upload-action@master
        with:
          aws_key_id: ${{ secrets.S3_ACCESS_KEY }}
          aws_secret_access_key: ${{ secrets.S3_SECRET_KEY}}
          aws_bucket: ${{ secrets.S3_BUCKET_NAME }}
          source_dir: 'results'
        if: always()

//додаємо коментар в пул реквесті з посиланням на звіт
      - name: Add Comment With Report
        uses: peter-evans/create-or-update-comment@v1
        with:
          issue-number: ${{github.event.pull_request.number}}
          body: |
            [Performance desktop static report (common)](index.html)
          if: always()

      - name: Down
        run: |
          docker stop media-portal-nginx amomama.com
          docker rm media-portal-nginx amomama.com
        if: always()

Як ми бачимо, збираємо проєкт локально, запускаємо тести на цій збірці, відписуємо ось такий коментар:

Також, ви могли помітити, що в команді запуску sitespeed з’явився ще один параметр --budget.configPath. Детальніше про перфоманс бюджет можна почитати ось тут, але якщо коротко, то це json файл, в якому ви вказали метрики, які вас цікавлять, і порогові значення, які ці метрики не мають перевищувати.

Насправді наш бюджет-файл досить простий і виглядає ось так:

{
  "budget": {
    "googleWebVitals": {
      "firstContentfulPaint": 1800,
      "largestContentfulPaint": 2500,
      "totalBlockingTime": 200,
      "cumulativeLayoutShift": 0.1,
      "timeToFirstByte": 800
    }
  }
}

Якщо після тестування хоча б один з показників перевищив це значення, то наш білд автоматично фейлиться, про що ми відписуємо у пул реквесті.

А навіщо вивантажувати репорт на s3? Для зручності. Так, ми можемо завантажити папку з репортом з артефактів екшенсу, але для цього треба знайти потрібну джобу, знайти артефакти, завантажити їх собі на комп’ютер і тільки після того можна побачити звіт. Погодьтеся, це не так зручно, як просто відкрити свій пул реквест, побачити посилання і перейти за ним.

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

Висновок

Отже, коли ми вже познайомилися з купою різних інструментів, за допомогою яких є можливість вимірювати та моніторити Google Core Web Vitals, можна зробити висновок, що всі вони мають дуже потужний та розширений функціонал. Звісно кожен обирає для себе своє еталонне рішення під свої потреби.

Як ви вже зрозуміли, кожен з цих інструментів цінний для бізнесу. Звичайно, для себе ми особливо відзначаємо sitespeed, який відкрив для нас дуже багато дверей та став трампліном для стрімкого розвитку нашого продукту. Своєю чергою, ми завдяки цьому можемо і далі постачати якісний розважальний контент швидко, користувачам з будь-якої локації та будь-яким інтернет-з’єднанням.

Буде цікаво послухати вашу думку в коментарях з приводу описаних інструментів для вимірювання та моніторингу перформансу.

Дякуємо!

👍ПодобаєтьсяСподобалось10
До обраногоВ обраному11
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я когда-то сделал вот такой сервис — pagehealth.me .
Вводишь интересующий тебя урл и каждый день (либо через вебхук) получаешь данные по Lighthouse Metrics и Chrome User Experience Reports.

Потом на графиках легче понять из-за чего именно те или иные метрики начали проседать или наоборот.

95% CoreWebVitals, web.dev/vitals Для розуміння, все що більше 90% це вже великий успіх для більшості проектів

Гарна стаття, добре описані кейси використання sitespeed. Доречі, з останнього свіжого, вчора Grafana презентувала свій інструмент для CWV моніторингу Faro. Загалом, він вміє збирати основні показники швидкості, можна збирати фронтові логи (особливо важливо в проектах де складна UI архітектура з великою інваріативністю). Загалом почитати можна тут grafana.com/...​pplication-observability

Тут дока для тих хто закоче підняти локально і потикати демку =) github.com/...​ro-web-sdk/tree/main/demo

Дуже змістовна та корисна стяття, дякую!

Підписатись на коментарі