PWA продають як «мобільний додаток без App Store». Формулювання зручне, але воно пропускає головне: PWA — це набір браузерних технологій поверх вашого сайту, а не окремий продукт. Якщо сайт під ними повільний, без карти сайту й без розмітки, PWA нічого не врятує. Якщо сайт нормальний — PWA додає кілька конкретних речей, і про них краще знати до того, як платити за розробку.
Нижче — розбір механізмів: що саме змінюється технічно, звідки береться користь і де межа, за якою користі немає.
Що таке PWA технічно
Три складові, без яких браузер не вважатиме сайт застосунком:
- HTTPS — обов'язкова умова, інакше service worker не зареєструється;
- web app manifest — файл, який описує назву, іконки, стартову адресу й режим відображення (
standalone— це той самий «відкривається без адресного рядка»); - service worker — скрипт, який стоїть між сторінкою і мережею та вміє віддавати збережені копії файлів, коли мережі немає або вона повільна.
Усе. Ніякої упаковки, підпису сертифікатом, ревʼю модератора. Сайт лишається сайтом — просто браузер отримує право показати його як застосунок.
У нашій практиці маніфест підключений і на бойових проєктах: у SaaS-платформи для рерайту описів товарів PWA-маніфест працює, при TTFB 220,6 мс і 141 КБ HTML на головній (наш вимір, 31.07.2026). Це, до речі, показує порядок роботи: спершу швидка віддача сторінки, потім маніфест поверх неї.
Чим PWA справді відрізняється від нативного додатку
Реліз виходить того ж дня
Нативний білд треба зібрати, підписати, відправити на ревʼю і дочекатися публікації — окремо в App Store, окремо в Google Play. У PWA нового релізу як події не існує: ви викотили сайт, service worker підтягнув оновлену версію при наступному відкритті. Виправлення помилки в чекауті доїжджає до користувача годинами, а не тижнями.
Звідси й арифметика вартості, без вигаданих відсотків: одна кодова база замість двох нативних плюс відсутність циклу релізів у сторах. Скільки саме це зекономить у вашому випадку — залежить від того, що ви взагалі збиралися робити в додатку.
Встановлення відбувається з вашого ж сайту
Людина вже на сторінці товару. Щоб поставити нативний додаток, їй треба вийти в стор, знайти вас серед схожих назв, дочекатися завантаження й авторизуватися заново. Щоб поставити PWA — натиснути «Додати на головний екран». Кількість кроків між наміром і встановленням різна, і це реальна різниця в механіці, а не в рекламному слогані.
Важлива поправка: в Safari на iOS браузер не показує автоматичного запрошення встановити. Користувач має сам відкрити меню «Поділитися» і вибрати «На екран Home». Тобто на iPhone встановлення відбувається лише тоді, коли ви прямо пояснили людині, що це можливо, і показали як.
Push-сповіщення працюють, але не однаково скрізь
На Android web push давно доступний у звичайній вкладці браузера. На iOS та iPadOS Apple додала Web Push у 16.4 — і тільки для вебзастосунків, доданих на головний екран. Тобто на iPhone push отримають виключно ті, хто спершу встановив PWA. Це документована обмеженість платформи, а не питання якості розробки, і планувати комунікацію треба з нею.
Чого PWA не дає
Механізм мобільної частки трафіку працює так: Google індексує сайти за мобільною версією, і більша частина візитів із пошуку та соцмереж приходить зі смартфонів. Якщо на мобільному ламається фільтр або кнопка «Купити» ховається під клавіатурою — цей трафік не конвертується, хоч він уже оплачений рекламою чи витраченим на SEO часом. Мобільна робота не приводить нових людей, вона припиняє втрачати вже приведених.
Чесна межа цього механізму: наявність мобільного viewport і маніфесту — це необхідний мінімум, а не доказ зручності. Ми міряємо їх ззовні; чи легко пройти ваш чекаут великим пальцем однієї руки — перевіряється тільки на живих сесіях. І в B2B-каталогах частина закупівельників справді працює з десктопа, там пріоритет мобільної версії нижчий — це чесніше сказати, ніж продавати мобільну оптимізацію як універсальний пріоритет.
Так само зі швидкістю. Швидкість не робить пропозицію привабливою: якщо ціна вища за ринок або товару немає в наявності, сайт із відгуком 200 мс просто швидше покаже людині причину піти. Швидкість прибирає технічну втрату, попиту вона не створює.
І окремо: PWA не зʼявляється в пошуку по App Store, не отримує місця в добірках стору й не дає доступу до частини системних API. Якщо ваш сценарій — фонова геолокація кур'єра, робота з Bluetooth-обладнанням або складна робота з камерою, дивіться в бік нативного.
Пастка, через яку PWA може коштувати вам пошукового трафіку
Найдорожча помилка тут — не бюджет, а архітектура. «Застосункове» відчуття часто досягають тим, що сайт роблять SPA: сервер віддає порожню оболонку, а весь контент збирається на клієнті скриптами. Для живої людини з увімкненим JavaScript усе гарно. Для краулерів і AI-агентів — ні: більшість із них читає те, що прийшло в HTML одразу, і бачить порожню сторінку.
У нашому вимірі 31.07.2026 сайт клініки естетичної медицини віддає різні відповіді залежно від User-Agent: браузеру — SPA-оболонку на 3,0 КБ, у якій немає ні H1, ні meta description; пошуковому боту — повністю пререндерений HTML на 126 КБ (24 КБ у gzip) за 145 мс до першого байта. Це і є правильне рішення для SPA: пререндер для ботів, окремо від клієнтського рендеру. Без нього сайт із маніфестом та service worker'ом виглядав би для пошуку як порожня сторінка.
Механізм видимості в AI-пошуку той самий, просто вітрина нова: якщо асистент не зміг прочитати ваш HTML, він процитує когось іншого. Закривається це пререндером, чистою семантикою, FAQ-розміткою і файлом llms.txt.
Чесна межа: ніхто, включно з нами, не може обіцяти згадку у відповіді AI-асистента — у вендорів немає ні гарантій, ні прозорих правил відбору. Обсяг переходів з асистентів поки що малий порівняно з класичним пошуком. Це робота на випередження з невідомою віддачею, і ми говоримо про неї саме так.
Спершу база, потім PWA
Найчастіша ситуація, яку ми бачимо на замірах: магазин хоче PWA, маючи невирішені речі рівнем нижче.
Магазин доставки солодощів (наш вимір, 31.07.2026): TTFB 402,9 мс — швидкий серед OpenCart-магазинів партії, пʼять способів онлайн-оплати. При цьому /sitemap.xml віддає HTTP 200 з тілом на 0 байт, на головній нуль блоків JSON-LD, нуль тегів <h1>, meta description на 46 символів, а аналітики немає жодної — ні GTM, ні GA, ні пікселя.
Магазин опалювального обладнання (той самий вимір): 3 565 карток товару, TTFB 524,8 мс, чотири способи оплати з безготівковим рахунком для ФОП і ТОВ з ПДВ — окремий сегмент, який без цієї опції не купує взагалі. І знову порожній sitemap та нуль структурованих даних.
Для порівняння — як виглядає прибрана база: у виробника негорючих стінових панелей 164 URL у карті сайту, з них 164 унікальні, нуль дублів, TTFB 244 мс на головній і вісім типів структурованих даних.
Поки sitemap порожній, а конверсії не міряються, встановлюваний ярлик на робочому столі не змінить нічого — просто не буде чим підтвердити, змінив чи ні.
Як перевірити свій сайт за півгодини
Без підрядника й без бюджету:
- Відкрийте сайт у Chrome на десктопі, DevTools → вкладка Application. Розділ Manifest покаже, чи є маніфест і чи всі поля заповнені; розділ Service Workers — чи зареєстрований воркер.
- Там же Lighthouse → категорія Performance і чекбокс Mobile. Дивіться LCP і TBT, а не загальний бал.
- Перевірте, що віддається без JavaScript:
curl -A "Googlebot" https://ваш-сайт/сторінка-товару | grep -c "<h1". Нуль — контент збирається на клієнті, потрібен пререндер або серверний рендер. - Відкрийте
ваш-сайт/sitemap.xmlі подивіться на розмір відповіді. Порожнє тіло при статусі 200 — Google не отримує карти сайту взагалі. - На iPhone пройдіть повний шлях: знайти товар, додати в кошик, оплатити. Однією рукою, у транспорті. Те, що зламається, і є вашим списком робіт.
- Подивіться в GA4 частку мобільних сесій і конверсію окремо для мобільних та десктопу. Якщо аналітики немає — це задача номер один, до будь-якого PWA.
Пункти 3 і 4 виконуються одним рядком у терміналі, пункт 1 — вбудованими інструментами Chrome. Підрядник для цього не потрібен.
Коли PWA доречний
Аргументи «за»: висока частка повторних покупок (є кому встановлювати), значна частка мобільного трафіку за вашим GA4, потреба в каналі сповіщень поза email, каталог, який люди гортають довго й хочуть відкривати швидко.
Аргументи «проти»: разові покупки без повернень, аудиторія переважно з десктопа, вимога системних API, яких у вебі немає, і — найчастіше — невиправлена база: швидкість, розмітка, карта сайту, аналітика.
Наскільки PWA вплине саме на ваші продажі, залежить від ніші, частки мобільного трафіку і поточного стану сайту. Чесна відповідь до заміру — «залежить», і будь-який відсоток, названий до аудиту, вигаданий.
Питання, які варто поставити
Чи замінює PWA нативний додаток? Для сценаріїв «каталог — кошик — оплата — сповіщення» вебплатформа закриває задачу. Для роботи з обладнанням, фоновою геолокацією чи важкою графікою — ні.
Чи працює на iPhone? Так, із поправками: встановлення тільки вручну через меню «Поділитися», push — від iOS 16.4 і лише для встановленого на головний екран застосунку.
Скільки коштує підтримка? Оновлення контенту виходять разом із сайтом. Окремо тримати доведеться логіку кешування в service worker — це та частина, яку найчастіше пишуть один раз і забувають, а потім користувачі місяцями бачать стару версію сторінки.
З чого починати? З заміру. Спершу цифри поточного стану, потім список робіт, і лише потім рішення про PWA.
Коротко
PWA — це маніфест, service worker і HTTPS поверх вашого сайту. Він прибирає цикл релізів у сторах, скорочує шлях до встановлення й відкриває push (на iOS — з обмеженнями Apple). Він не робить повільний сайт швидким, не створює попиту й не гарантує місця у видачі. І якщо його роблять через SPA без пререндеру, він може відібрати пошуковий трафік — рівно те, чого ви не хотіли.
Порядок робіт, який ми вважаємо правильним: швидкість віддачі → коректний sitemap і структуровані дані → аналітика → мобільний UX → і тільки потім PWA.
Якщо хочете почати з заміру, а не з припущень — напишіть на hello@lionex.com.ua або залиште заявку. Ми віддамо цифри поточного стану сайту й список того, що дасть ефект першим.
