Service Worker для агресивного кешування даних сайта

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

Мій досвід використання SW зводиться до налаштування sw-toolbox від гугла, що є надстройкою над SW для спрощення опису правил кешування.

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

Я по нерозумінню увімкнув агресивне кешування всіх зображень, навіть тих що зберігаються в S3 і є user-generated контентом. Ефект був двояким. З одного боку було прикольно, що сайт включно з контентом можно було читати офлайн, проте розмір кеша настільки був великим, що досягав 1 гігабайта. Деякі користувачі помітили це і були не дуже задоволеними. Я перевірив який максимальний розмір кеша дозволяють тримати сучасні браузери і виявилося, що Chrome може займати до 80% диску девайса, ліміт Safari сягає приблизно 1 гігабайт, ліміт Firefox – 50% диска. Тож мені видається, що гарантовано можно отримати для сайту десь від 200 мегобайт до 1 гігабайту диска користувача.

Що можно кешувати? Давай подумаємо з чого складається сайт, спрощено:

• HTML
• CSS
• JS
• API дані
• Зображення, відео, аудіо

HTML, CSS, JS безперечно перші кандидати, котрих треба класти в кеш. API дані складніше, треба аналізувати кожен ендпоінт та зрозуміти з якою частотою оновлюються дані в цьому ендпоінті. Проблеми можуть виникнути з контентом, який редагується або видаляється. З даними користувача більш-менш зрозуміло. Якщо ми маємо REST-ендпоінти ресурсів, то запити POST, PUT, PATCH, DELETE до ресурсу якось змінюють його, тому можно одразу видалити цей ресурс з кешу щоб браузер міг підтянути нову версію. Складніше з ресурсами, котрі знаходяться у спільному користуванні. Мабуть, найкращим варіантом (з моєї точки зору) для таких ресурсів буде кешування на невеликий проміжок часу, наприклад 1 хвилина.

Зображення, відео, аудіо, особливо якщо це контент генеруємий користувачами, не треба включати в кеш. І зробити для таких ресурсів спеціальне відображення. На стороні HTML/JS відслідковувати подію error та показувати Не вдалося завантажити зображення або відео. Повторити?.

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