PWA

Progressive Web App, прогрессивное веб-приложение

PWA — это веб-сайт, который благодаря манифесту и сервис-воркеру работает как нативное приложение: ставится на главный экран, открывается офлайн и грузится почти мгновенно.

Технически PWA держится на двух вещах. Манифест (manifest.json) описывает иконку, название и режим запуска, чтобы браузер предложил «установить» сайт на экран телефона. Сервис-воркер — фоновый скрипт, который кэширует файлы и отдаёт страницу даже без интернета.

Для SEO прямого бонуса от статуса PWA нет, поиск не ранжирует сайт выше просто за манифест. Но косвенный эффект ощутимый: кэширование разгоняет повторные загрузки, улучшает Core Web Vitals и удерживает мобильного пользователя. А скорость и поведенческие в мобильной выдаче решают многое.

Суть
сайт-приложение

Веб-сайт ведёт себя как нативное приложение

Как
service worker

Кэш, офлайн-режим и иконка на домашнем экране

Эффект
+скорость, +удержание

Повторные заходы грузятся мгновенно из кэша

Скорость PWA напрямую влияет на Core Web Vitals
Пример

Магазин обернул сайт в PWA: иконка на экране, работа офлайн, пуши о скидках. Повторные заходы выросли на 40 %, а мгновенная загрузка из кэша подтянула Core Web Vitals.

Сервис-воркер удобен для пользователя, но коварен для индексации: если он начнёт отдавать роботу закэшированную или урезанную версию страницы, в индекс попадёт устаревший контент. Робот Яндекса и Googlebot сервис-воркеры не исполняют — они краулят исходный ответ сервера, поэтому критично, чтобы первый HTML с сервера уже содержал весь контент и метатеги, без дорисовки скриптом после установки воркера. Проверять это нужно инструментом «Переобход» и просмотром кэша в Вебмастере, а в Google — через «Проверку URL» с рендером.

Главная ловушка PWA на JS-фреймворках — клиентский рендеринг (CSR): контент собирается в браузере, а серверный ответ почти пустой. Для mobile-first индексации это риск недополучить текст в индекс, поэтому ставьте SSR или пререндер. Сам по себе сервис-воркер не улучшает TTFB первого визита — он ускоряет повторные заходы из кэша; именно эта разница между «холодной» и «тёплой» загрузкой и подтягивает Core Web Vitals по возвращающимся пользователям.

Окупается технология там, где люди возвращаются регулярно: сервисы, личные кабинеты, доставка, медиа с постоянной аудиторией. Для сайта услуг с редкими визитами затраты на поддержку фонового скрипта себя не окупают. Установку на экран делают единицы посетителей, а кэш добавляет проблем при обновлениях.

Ограничения зависят от системы: на устройствах Apple часть возможностей урезана, push-уведомления работают с оговорками, а установка требует отдельных действий пользователя. Отдельная ловушка — устаревший кэш: при неверной настройке люди неделями видят старую версию страницы. На ранжирование сама технология не влияет, работает только скорость, которую она даёт.

Частые вопросы

Кому подходит такое приложение?

Сервисам с повторными визитами: доставке, личным кабинетам, медиа с постоянной аудиторией. Для сайта услуг с редкими посещениями поддержка фонового скрипта обходится дороже, чем даёт пользы.

Влияет ли технология на позиции?

Напрямую нет. Косвенно помогает скорость повторных визитов за счёт кэширования. Поисковые системы оценивают обычные показатели страницы, а установка на экран телефона в ранжировании не участвует.

Работает ли всё это на устройствах Apple?

Частично: установка доступна, но часть возможностей ограничена, а уведомления работают с оговорками и требуют отдельного разрешения. Перед внедрением проверяют сценарии именно на этих устройствах.

Почему пользователи видят старую версию сайта?

Из-за настроек кэширования в фоновом скрипте. Нужна стратегия обновления с версионированием файлов и проверкой свежести, иначе люди неделями работают со старой версией страницы.

Спросите нейросети про «PWA»

Отвечает DeepSeek