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

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

Зараз ми, як раз, працюємо над покарщенням цього показника. Це комплесна проблема, але так, вона в тому числі включає в себе витікаючі наслідки 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 ситуація : )