PWA

Куди дістає вебзастосунок у 2026 році — шістнадцять можливостей, платформа за платформою

PWA — це не одна технологія з одним рівнем підтримки. Це набір можливостей браузера, і кожен браузер реалізує свою підмножину. Тож питання, яке насправді має команда, — «чи можна зробити це вебзастосунком?» — не має однієї відповіді. Відповідь є для кожної можливості й кожної платформи. На iPhone відповідь ще й змінюється, щойно користувач додає сайт на домашній екран, бо частина можливостей існує лише для встановлених вебзастосунків. Кожен браузер на iOS використовує рушій WebKitWebKitрушій браузера SafariРушій браузера з відкритим кодом, на якому працює Safari. Сторінка, що працює в Chrome, може зламатися у WebKit, тому набори тестів проганяють браузерні маршрути й у ньому — Playwright для цього має власну збірку WebKit.Усі терміни від Apple, тож користувач iPhone не обійде цього, встановивши Chrome. Ось шістнадцять речей, які зазвичай потрібні застосунку, де кожна працює станом на жовтень 2026 року і що робити там, де ні. Наступні розділи посилаються на рядки за номерами.

Service worker: проксі, якого сторінка не бачить і не обійде

Усе, що PWA вміє, а звичайний сайт — ні, починається з одного механізму. Service worker — це скрипт, який браузер виконує окремо від сторінки й без доступу до неї. Після реєстрації він отримує подію fetch для кожного запиту сторінок у своїй області — HTML, скриптів, зображень, викликів APIAPIApplication Programming Interface — контракт між програмамиПравила, за якими одна програма звертається до іншої: які запити можна надіслати, у якому вигляді й що прийде у відповідь. Для того, хто звертається, це контракт — усе, що за ним, лишається чорною скринькою, і саме тому другий бік можна переписати, не зламавши вас.Докладніше в статті →Усі терміни. Для кожного він вирішує, що відповісти: щось із кешу, щось із мережі або щось, що збудує сам. Сторінка не може відрізнити одне від іншого. Область — це тека, у якій лежить файл воркера, тож воркер за адресою /sw.js керує всім сайтом, а за адресою /app/sw.js — лише /app/. Service worker працює лише через HTTPS, за винятком localhost під час розробки.

У воркера є життєвий цикл, і більшість проблем у продакшені походить саме з нього. Браузер перевіряє, чи є нова версія, під час кожної навігації на сторінку в області, а також під час подій на кшталт push, якщо не перевіряв протягом останніх 24 годин. Починаючи з Chrome 68, а також в інших сучасних браузерах, ця перевірка ігнорує HTTPHTTPHyperText Transfer Protocol — протокол вебуПротокол, яким спілкуються браузер і сервер: клієнт надсилає метод і адресу, сервер відповідає кодом стану й тілом. Між запитами він нічого не памʼятає — кожен запит стоїть сам по собі, тому все, що треба памʼятати, передається явно.Усі терміни-заголовки кешування для самого файлу воркера, хоча не для скриптів, які він імпортує. Якщо відрізняється бодай один байт, браузер завантажує й встановлює новий воркер. А тоді новий воркер чекає. Типово він бере керування лише тоді, коли жодною вкладкою вже не керує старий. До того старий воркер далі відповідає — зі старих кешів.

Продумайте шлях назад ще до першого воркера. Якщо до користувачів потрапив зламаний воркер, виправлення — задеплоїти воркер, який нічого не робить, — без обробника fetch, із skipWaiting() під час встановлення, — рівно за тією самою адресою. Тоді запити проходять так, ніби воркера немає. Перейменуйте файл — і зламаний воркер лишиться зареєстрованим поруч із новим і далі відповідатиме. Заголовок відповіді Clear-Site-Data: "storage" теж знімає реєстрацію воркерів, але він стирає все сховище сайту й підтримується не скрізь, тож це запасний варіант, а не план. І нарешті, пишіть воркер бібліотекою, а не руками. Workbox (7.4), Serwist, vite-plugin-pwa і service worker від Angular генерують список файлів для передкешування з результату збірки, тож список і хеші версій лишаються правильними, поки змінюється бандл.

Кеш і сховище: наскільки застарілою може бути відповідь і скільки вона проживе

Стратегію кешування обирають для кожного виду запитів, а не раз на весь сайт, і вибір зводиться до одного питання: наскільки застарілою може бути ця відповідь? Бандл JavaScript, у назві файлу якого є хеш його вмісту, ніколи не застаріває — нова версія отримує нову назву, — тож він може братися з кешу завжди. Баланс рахунку не має застарівати ніколи, тож він мусить приходити з мережі або не приходити зовсім. Більшість запитів — десь посередині. Три стратегії покривають більшість із них, і відрізняються вони тим, хто відповідає першим.

Записи потребують найбільшої уваги, бо офлайн-запис — це обіцянка. Звичний патерн — зберегти зміну локально, показати її як таку, що очікує, і надіслати, коли повернеться зв’язок. У Chrome і Edge Background Sync може надіслати її навіть після закриття застосунку (рядок 12). Скрізь інде повторне надсилання стається наступного разу, коли застосунок відкриють. Так чи інакше сервер може отримати той самий запис двічі — раз від спроби, що відвалилася за таймаутом, і раз від повтору, — тож кожен запис має нести ключ, який дозволяє серверу вважати повтор тим самим запитом. Операцію, що дає той самий результат, скільки б разів її не виконали, називають ідемпотентною (idempotentidempotentбезпечно повторитиОперація, що дає однаковий результат, скільки б разів її не виконали — раз чи пʼять. Саме це робить повтор безпечним, а оскільки будь-який мережевий виклик може бути повторений без вашого відома, альтернатива — списати з картки двічі.Усі терміни), і офлайн-записи безпечні лише тоді, коли вони такі.

Що браузер має право видалити

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

Встановлення: що означає «встановити» на чотирьох платформах

Друга половина PWA — вебманіфест: невеликий JSONJSONJavaScript Object Notation — текстовий формат данихТекстовий формат для передавання даних: пари «ключ — значення», списки, числа й рядки. Він народився в JavaScript, але сьогодні його читає будь-яка мова — і саме тому ним відповідає більшість API, а не чимось потужнішим.Усі терміни-файл, на який посилається кожна сторінка і який дає застосунку назву, іконки, стартову адресу й режим показу. Поставте display у standalone — і встановлений застосунок відкриється без адресного рядка й вкладок, а це й є більша частина того, що робить його схожим на застосунок, а не на закладку. Chrome пропонує встановлення, коли сайт працює через HTTPS, а в маніфесті є name чи short_name, іконки на 192 і 512 пікселів, start_url і значення display, — після того як користувач клацнув на сторінці й провів на ній близько 30 секунд. Починаючи з Chrome 108 на Android і 112 на десктопі, для встановлення з меню браузера service worker узагалі не потрібен; підказка встановлення його все ще шукає.

«Встановити» дає чотири різні результати. На Android Chrome створює WebAPK — справжній пакет Android, згенерований з маніфесту, — тож застосунок з’являється серед застосунків і в системних налаштуваннях і відкриває посилання зі своєї області замість браузера. На iPhone користувач додає сайт із меню «Поділитися». З iOS 26, з вересня 2025 року, кожен доданий так сайт типово відкривається як вебзастосунок — із маніфестом чи без. Вебзастосунок на iPhone має власні cookiescookieдані, які браузер надсилає назадНевеликий фрагмент даних, який сайт просить браузер зберегти й надсилати назад із кожним запитом до цього сайту, — так сервер пам’ятає, що ви увійшли. Оскільки браузер додає його автоматично, навіть до запиту, який спровокував інший сайт, cookie сесії потребує правильних прапорців і перевірки проти підробки запитів на сервері.Усі терміни і сховище, окремі від Safari: користувач, що увійшов на сайті, відкриває нову іконку й бачить, що не увійшов, тож перший екран після встановлення має бути входом, який не схожий на баґ. Chrome і Edge на десктопі встановлюють сайт у власне вікно. Safari на Mac, з версії 17, додає його в Dock. Firefox 143 у вересні 2025 року почав закріплювати сайти на панелі задач Windows.

Лише браузери на Chromium дають самій сторінці запропонувати встановлення (рядок 10). Вони генерують подію beforeinstallprompt, яку сторінка може притримати й відтворити зі своєї кнопки «Встановити» в слушний момент. Скрізь інде встановлення — це пункт меню, який користувач мусить знайти сам, тож продукт, якому потрібні встановлені користувачі, пише короткі інструкції для кожної платформи й показує їх тоді, коли користувач найімовірніше погодиться, — після другого візиту, а не на першому екрані. Стандартний спосіб для сторінки попросити вже на підході: 21 вересня 2026 року Chrome оголосив намір випустити Web Install API — navigator.install() і елемент <install> — у Chrome 156, спершу на десктопі. WebKit заявив, що проти, бо встановлення має починатися в інтерфейсі самого браузера, тож не плануйте під нього фічу для iPhone.

iPhone: що дозволяє Apple і як до цього дійшло

Рядки 8–11 і порожні клітинки iPhone у рядках 12–16 мають одну причину. На iOS кожен браузер — Safari, Chrome, Firefox, Edge — мусив використовувати рушій WebKit від Apple, тож те, що реалізує WebKit, — це те, що може веб на iPhone. Правило почало слабшати: з iOS 17.4 браузери в ЄС можуть використовувати власні рушії, а з iOS 26.2, з грудня 2025 року, — і браузери в Японії. Але, за власною заявою Apple 2024 року, вебзастосунки на домашньому екрані збудовано безпосередньо на WebKit, і на момент написання жоден великий браузер не постачає на iPhone власного рушія. Плануючи, виходьте з WebKit. Історія пояснює, чому команди раз у раз на цьому спотикаються:

Push на iPhone має три правила, крім «лише для встановлених» (рядок 8). Запит дозволу може з’явитися лише у відповідь на пряму дію, як-от натискання кнопки «Увімкнути сповіщення», — і ніколи під час завантаження сторінки. Кожен push мусить показати сповіщення, яке бачить користувач: WebKit відкликає підписку сайту, чий воркер отримав push і нічого не показав, тож тихого push для фонових оновлень у вебі немає (рядок 13). А з iOS 18.4 декларативний push дає серверу самому описати сповіщення, тож воно з’являється, навіть якщо воркер так і не запуститься. Лічильники працюють за тим самим принципом (рядок 9): встановлений застосунок може поставити число на своїй іконці, і система показує його разом з іншими сповіщеннями застосунку.

PWA, обгортка чи застосунок: питання магазинів

Перевага PWA, що переживає будь-яке порівняння, — дистрибуція. Немає черги рев’ю, акаунта в магазині, сертифіката, який треба поновлювати, і збірки, яку треба підписувати. Виправлення виходить із наступним деплоєм, а посилання — це весь процес встановлення. Для продукту, який знаходять пошуком або отримують посиланням, це різниця між «спробувати зараз» і «спершу щось встановити». Чого посилання не дає — це картки в магазині, де люди гортають застосунки, платіжної системи магазину й довіри, яку частина користувачів має лише до застосунків із магазину. Є чотири способи повернути частину цього, і в кожного своя пастка:

Пункт 4.2 правил Apple — та лінія, що вирішує останній рядок: застосунок має містити можливості, вміст та інтерфейс, що «підносять його над перепакованим сайтом», а той, що не корисний, не унікальний і не схожий на застосунок, у магазині не місце. Оболонка навколо вашого сайту без нічого нативного всередині — саме те, що це правило відхиляє. На Android навпаки: Trusted Web Activity — підтримуваний спосіб покласти сайт у Google Play, якщо Digital Asset Links на вашому сайті доводять, що застосунок і сайт належать одному розробникові. Саме рішення випливає з таблиці можливостей більше, ніж зі смаку:

П’ять кейсів і те, чого в кожному бракувало

Три з п’яти кейсів — про платформу під вебзастосунком: виробник браузера чи операційна система змінює правило, — а два — про вибір самої команди. Кожен задокументували ті, кого він стосувався.

Перший кейс показує, як поширюється проблема оновлення. Create React App 1.0, що вийшов 18 травня 2017 року, зробив кожен новий проєкт типово прогресивним вебзастосунком: service worker кешував усю збірку й віддавав її за принципом «спершу кеш». Через десять днів з’явився issue під назвою «Why was service worker merged into create react app?», і в понад 154 коментарях розробники описували те саме. Вони деплоїли, а їхні користувачі далі бачили старий сайт. Версія 2.0 від 1 жовтня 2018 року зробила service worker необов’язковим. Документація прямо назвала причину: офлайн-перші застосунки можуть ускладнити налагодження деплоїв, а користувачі бачать старіший вміст, доки не закриють усі відкриті вкладки, — «перезавантаження замало». У воркері нічого не було зламано. Бракувало процесу оновлення з розділу вище, а шаблон не може знати, коли вашим користувачам слід отримати нову версію.

Інші три кейси — про правила, якими команда не володіє. У березні 2020 року Safari почав видаляти все сховище сайту, записане скриптами, — IndexedDB, localStorage, реєстрації service worker і кеші — після семи днів користування Safari без візиту. Це було спрямовано проти трекерів, і застосунки на домашньому екрані стали винятком, але будь-який вебзастосунок, що тримав єдину копію чогось користувацького в браузері, її втратив. У лютому 2024 року бета-версії iOS 17.4 перетворили вебзастосунки на домашньому екрані в ЄС на ярлики, що відкривалися у вкладці Safari, — без власного вікна, push і лічильників; Apple послалася на Акт про цифрові ринки ЄС. Після хвилі обурення розробників і на тлі уваги Європейської комісії Apple скасувала зміну 1 березня. А браузери поступово зачиняють двері для недбалого push: Chrome 80 2020 року приглушив запит для сайтів, чиї запити користувачі зазвичай відхиляють, а з жовтня 2025 року Chrome забирає дозвіл на сповіщення в сайтів, які користувач більше не відвідує, зазначивши, що взаємодію отримує менше 1% сповіщень. Встановлені вебзастосунки на друге правило не підпадають. Усі три кажуть одне: вебзастосунок працює за правилами, які встановлює хтось інший, тож він тримає дані на власному сервері, має другий канал для всього критичного й заробляє кожен дозвіл у мить, коли той потрібен.

Де це вироджується

PWA відмовляє так, що з машини розробника цього не видно: там швидка мережа, браузер — Chrome, а вкладка завжди свіжа. Майже кожен збій — одне з цього:

• Немає процесу оновлення — випущене виправлення чекає за старим воркером, доки відкрита вкладка чи застосунок на домашньому екрані.
• Перейменований файл service worker, через який зламаний лишається зареєстрованим і далі відповідає.
• index.html без хешу, який віддають за принципом «спершу кеш», закріплюючи користувачів на одному релізі.
• Дані API з кешу, показані як актуальні, без часу отримання.
• Офлайн-записи, які повторюють без ключа ідемпотентності, — і одне замовлення стає двома.
• Єдина копія даних користувача у сховищі браузера, яке браузер має право видалити (рядок 2).
• Закешовані непрозорі відповіді, що ховають помилки й з’їдають квоту по сім мегабайтів за раз.
• Запит на сповіщення під час першого візиту — один раз відхилений і приглушений назавжди.
• Фіча, збудована на рядках 8–16, відсутність якої на iPhone виявили після затвердження дизайну.
• Обгортка для магазину без нічого нативного, відхилена за пунктом 4.2.

Чесна межа в тому, що PWA живе всередині браузера, а браузер належить комусь іншому. На Android і десктопі Chromium дає вебзастосунку майже все, що отримує застосунок, і розрив далі скорочується. На iPhone веб отримує те, що вирішить Apple, рішення встигало змінитися в обидва боки за один цикл бета-версій, а рушій під ним ви не обираєте. Це причина будувати PWA з розплющеними очима, а не причина її уникати. Для більшості продуктів, що живуть із того, що їх знаходять і поширюють, посилання, яке працює одразу, краще за застосунок, який спершу треба встановити, — якщо нічого суттєвого не залежить від можливості, якої одна з платформ не дає.

Практична перевірка займає годину. Випишіть кожну можливість, потрібну продукту, і знайдіть її рядок у таблиці вгорі. Відкрийте сайт на iPhone, додайте його на домашній екран і перевірте, що там працюють вхід, push і офлайн. Задеплойте помітну зміну, лишивши вкладку відкритою, і подивіться, коли вона доїде. Знайдіть назву файлу service worker і переконайтеся, що вже сьогодні за цією адресою можна задеплоїти заміну, яка нічого не робить. Пошукайте в правилах кешування щось персональне або щось непрозоре. Вимкніть мережу, зробіть зміну, двічі ввімкніть зв’язок і порахуйте, скільки разів її отримав сервер.

Коли це застосовувати

Пов’язані сторінки

• РозробкаJavaScriptJavaScript — мова програмування, яку виконує кожен браузер: один потік на сторінку, один стек викликів і черга для всього, що мусить чекати. Більшість того, що здається в ній довільним, випливає з цієї моделі або з рішення перших років мови, яке веб уже не може скасувати. Сторінка починається з дванадцяти несподіванок — кожна з правилом, що за нею стоїть, і виправленням; далі — цикл подій, де асинхронний код губить час і помилки, числа й посилання, область видимості, модулі й дерево залежностей і п’ять задокументованих кейсів.
• РозробкаReact NativeReact Native — це фреймворк, який виконує React-компоненти в рушії JavaScript на телефоні й перетворює їх на справжні в’ю iOS та Android, а не на вебсторінку. Через цей поділ вебкоманда може випустити застосунок, що відчувається нативним, — і через нього ж типовий збій тут — екран, який перестає відповідати, поки JavaScript зайнятий. Сторінка починається з шістнадцяти речей, які робить екран, і того, що рухається далі, коли потік JavaScript заблоковано; далі — нова архітектура, списки й зображення, Expo й оновлення «по повітрю», релізи до 0.87 і дедлайни магазинів на 2026 рік, що насправді спільне, п’ять задокументованих кейсів, зокрема повернення Shopify до нативу у вересні 2026 року, і те, де все це вироджується.
• РозробкаHTML та CSSHTML і CSS — це дві мови, з яких складається кожна вебсторінка: HTML каже, чим є кожна її частина, а CSS — як вона виглядає і де стоїть. Обидві зазвичай вважають простим шаром, і обидві працюють за правилами, достатньо точними, щоб майже на кожне «чому воно так виглядає» існувала точна відповідь. Сторінка починається з дванадцяти симптомів верстки, яка робить не те, що написано в коді, — кожен із правилом, що за ним стоїть, і виправленням; далі — що браузер робить із двома файлами, обіцянки HTML, каскад, бокс і розкладка, що коштує користувачеві, і п’ять задокументованих кейсів.