Такі бізнес вимоги (прев’ю картинка зверху статті), нічого не поробиш)
Але ми для комфорту користувача в цьому кейсі робимо все можливо, преконекти, оптимальні типи розширень зображення, cloudfront, сервіс воркер кешування і тому подібне.
Я з вами погоджуюся, забивати на UX та фокусуватися виключно на Core Web Vitals ні в якому разі не можна, тому ми працюємо з двох сторін)

Ну не зовсім, UI дуже важлива частина нашого продукту, але так, не кожен день ми вносимо зміни в дизайн)
Якщо ви питаєте про тестування під час розробки, то все занадто банально — звичайне локальне тестування за допомогою DevTools, в крайньому випадку — на реальних девайсах (декількох типів) перевірити)
А якщо про тестування перед виливкою в продакшин, ось тут цікавіше, у нас для цього є ціла система різноманітних автомейшин тестів, які в тому числі і по UI складовій пробігються (на жаль, детально тут не розповім що там і як працює під капотом, бо у нас цим QA займаються), але система робоча і дуже корисна)

Ух, можу собі тільки уявити (як людина якій тільки інколи доводиться перевіряти через браузерстек на парочці девайсах якусь фічу), як це боляче в масштабах десятка девайсів та ще й з перформанс складовою, що ж тут можу сказати — добре що цей проект позаду XD ))

Ми якось писали статтю на цю тему, деякі деталі змінилися з того часу, але загальна концепція залишилася, тому, якщо цікаво, велком — dou.ua/forums/topic/40578 : )

Якщо ще залишаться питання, з великим задоволенням обговорю)

Дисклеймер: інформація може здатися «занадто базовою», але розпишу щоб на всіх рівнях було зрозуміло, а там, якщо будуть якісь конкретніші запитання, залюбки розкрию тему в цьому напрямку)

Перше що потрібно зрозуміти, збирати метрики можна двома способами: польові дані, або лабораторні. Якщо коротко — польові, це статистика реальних показників юзерів, які збирає Google, а лабораторні — це показники на конкретній машині/девайсі/пристрої на якому їх перевіряють (тобто якщо ви захочете заміряти LCP на своєму сайті за допомогою свого лептопа — це буде лабораторний замір, бо він покаже результат з вашим інтернетом, з вашимми показниками ноуту, тощо, тобто локальне середовище).
Більш детально тут — web.dev/...​nd-field-data-differences

Зупинимося саме на першому (польових даних), так як це більш показові та реальні дані, а саме, як користувач бачить ваш сайт.
1. Якщо потрібні актуальні дані, прямо зараз (дані збираються за останні 28 днів) — pagespeed.web.dev (треба дивитися саме саму верхню табличку, вона про реальних юзерів, нижче йдуть лабораторні заміри Google)
2. Якщо цікавлять зміни за історичний період, з розбивкою на місяці, ось офіційний ресурс для цього developer.chrome.com/docs/crux/dashboard вставляєте в поле потрібну url і клікаєте «Go» (також, по посиланню, нижче можна почитати як зручно додати прямо в адресну стрічку цей інструмент)
3. Якщо цікавить поденна статистика, то тут треба буде трошки забруднити руки, але воно того варте, бо по цих даних можна вирахвати, практично, день, коли щось пішло не так (або так : ) ) - CrUX History API, детальніше тут developer.chrome.com/docs/crux/history-api.
Як обробляти, це вже справа кожного, можна через Looker Studio (колишні Google Data Studio), а можна реалізувати свою обробку даних, з красивими графічками та під ваші цілі (особисто ми в команді використовуємо своє рішення для обробки, що дає нам можливість фокусуватися на потрібних для нас даних)

Можете мою попередню статтю почитати (dou.ua/forums/topic/41197), там як раз про покращення досвіду користувача в дуже цікавий спосіб)

—_—
Так, весь інший час цим і займаємося ; )

Так, ви абсолютно праві, це гарне уточнення, щоб було зрозуміло звідки воно взяте, дякую!
Бо я його побачив занадто пізно, вже після того, як відмучався з методом проб та помилок))

Саме цікаве та іронічне, що воно було в мене прямо під носом, на тому скріні що я додав (про зміни в 112 хромі, абзац та параграф) , трошки нижче, як раз було про це написано)) ось оригінал: chromium.googlesource.com/...​_changelog/2023_04_lcp.md

Тому дякую що вказали на це, бо я забув уточнити)

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

Але погоджуюсь, якби ми не мали впевненості в кількості лінків, варто було б розглянути штучний максимум закешованих даних і чи точно воно того варте : )

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

Якщо ж ми говоримо про сервіс воркери, то вони ніяк не впливають на цей показник (в нашому випадку).

Так, дійсно, не бачив такої проблеми, тут кейс з offline-first, у нас просто не зустрічався. А робота з SW вона така, підступна, завжди є якісь «підводні камені» : )

Перепрошую?) Щось не зрозумів що саме маєте на увазі)

Дякую, дуже приємно що сподобалось! : )

Кешування з SW таке, згідний, хочеться відразу і все в нього засунути ; )

Хм, а на якому саме етапі виникла проблема з POST запитами, на запиті чи на відповіді? Бо ми ми робили POST запити та зберігали в кеш відповідь, наче проблем не було.
О це ви крутий шлях джедая обрали — кешувати і тягнути з indexedDB : ) Взагалі indexedDB воркерам потрібен для зберігання невеликих значень (рідка кейси) та глобальних змінних (часта історія) (таких як хеш для інвалідації, або версійність), тому, думаю, у Вас і виникли проблеми з кешування туди)

Згідний на всі 100%, будь яке кешування за допомогою SW дає сайту +1000 до крутого UX ! : )

Ви праві, дякую!

Я знав що в різних скоупах можна реєструвати багато SW, але в статті так написав спираючись на наш сумний досвід реалізації двох SW (в різних папках), які вели себе непрогнозовано, та конфліктували. На той момент не знайшли нормальної інформації як їх дружити та в чому може бути проблема. Але, раз навіть Google користується такою можливістю, значить треба провести додатковий ресьорч на цю тему (хоча на даний момент і не дуже актуально, так як ми використовуємо для менеджменту багатьох SW Workbox, а в ньому доволі просто все красиво організувати, але ніколи не пізно дізнатись більше! :) ), дякую!)

Чи бачили Ви реалізацію багатьох Service Worker’ів, на реальному сайті (навіть в різних скоупах)?

Два з трьох посилань — це лендінги і я думаю ми всі розуміємо чому вони не використовують подібних технологій. Третє — вікіпедія, на якій є тільки текст+лінки+маленькі картинки.

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

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

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

Я не казав нічого про однозначне добро)
Ми з вами живемо в світі в якому неможливо уявити веб-сайт який не робить фонові запити (google analytics, Facebook Pixel і цей список можна продовжувати дуже довго) і все це, раз ми вже перейшли в розділ «холіварства» і філософії, робиться заради користувача та покращення його взаємодії з ресурсом. Невже Ви можете уявити сучасний, швидкий, зручний та красивий сайт який не робить фонові запити «без відома» користувача? Я б подивився :)

1. Чимось (в даному випадку завантаженням пари data-джейсонок у фоні) приходиться жертвувати заради крутого UX, ми розцінили це, як невелику плату за такий досвід : )
2. Якщо такий плагін від браузерів і побачить світ, я думаю це буде удар не тільки для нас, а і для Next.js у якого є схожа концепція «Route prefetching», да і в принципі по всім фронтовим фреймворкам які використовують схожі технології, а таких немало.
3. Також тут варто розуміти, навіть якщо юзер і заблокує (плагіном чи власною розробкою для браузера) всі подібні запити, він просто не отримає безшовного переходу і все, нічого критичного не станеться. Тому як на мене це Win-Win ситуація : )