Меню
Разработка

PWA и ускорение сайта: что это даёт и чего не даёт

Быстрый сайт, который можно поставить на экран телефона и открывать почти мгновенно. С честными границами: на iPhone возможности таких приложений ограничены системой.

PWA — это сайт, который ведёт себя как приложение: ставится на экран телефона, быстро открывается повторно, умеет показывать уже загруженное без интернета. Для бизнеса это способ получить часть удобства приложения, не оплачивая его разработку и не воюя за установки в магазинах. Границы стоит знать заранее. На Android такие приложения работают почти полноценно, на iPhone — с ограничениями: установка не очевидна пользователю, а push-уведомления работают только для добавленного на экран приложения, поэтому строить на них главный канал связи рискованно. В магазины приложений PWA не попадает. Зато содержимое остаётся обычными страницами сайта и участвует в поиске — у нативного приложения этого нет. И отдельно: если задача — просто ускорить сайт, переписывать его целиком нужно далеко не всегда. Чаще время съедают несжатые картинки, десяток сторонних скриптов и медленный сервер — начинаем с замера, а не с переделки.

Какие задачи решаем

С какими проблемами приходят клиенты

🐢

Сайт грузится 5-10 секунд

Классический WordPress/Bitrix с плагинами, тяжёлым JS. Google понижает в выдаче за плохой Core Web Vitals.

📱

На мобильном всё лагает

INP >500ms — кнопки нажимаются с задержкой, скролл рывками, формы отправляются с секундной задержкой. Пользователи уходят.

🔌

Без интернета — белый экран

Нет офлайн-кеша, PWA-функционала. Клиент в метро, в отеле, в пробке — не может пользоваться сайтом.

📉

Люди уходят, не дождавшись

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

🎯

Не индексируется JavaScript-контент

SPA без SSR/SSG — Googlebot видит пустую страницу. Половина контента вне индекса.

📊

Нельзя измерить и улучшить

Что тормозит? Какая метрика в красной зоне? Нет данных — не понятно что чинить. Идёт по кругу.

Что включает услуга

Полный пакет работ

Разработка на выбранном фреймворке

Next.js (React), Nuxt (Vue), Astro (mostly static), Remix, SvelteKit. Подбираем под задачи и команду поддержки.

Core Web Vitals 95+

LCP <1.2сек, INP <100ms, CLS <0.05 на всех ключевых страницах. Замеры на реальных устройствах через CrUX.

SSR / SSG / ISR

Server-Side Rendering или Static Site Generation с Incremental Regeneration. Googlebot видит полный HTML с первого запроса.

PWA функционал (опц.)

Service Worker для офлайн-работы, установка на устройство, push-уведомления, home screen icon. Мобильное приложение без App Store.

Mobile-first

Основная часть трафика сегодня мобильная. Оптимизация под iOS и Android: касания, viewport, кнопки в зоне большого пальца, гибкая типографика.

SEO-оптимизация

Правильная schema, мета, sitemap, robots. Динамическая ре-генерация страниц через ISR — контент всегда свежий для Googlebot.

Headless CMS

Контент редактируется в удобной админке (Strapi, Sanity, Payload, Contentful), фронт получает через API — гибкость и скорость одновременно.

Real User Metrics

Замеры Core Web Vitals у реальных пользователей (не только Lighthouse). Дашборд с трендами скорости, INP, ошибок.

Цена

Сколько это стоит

PWA и ускорение сайта

после брифа зависит от задачи

Это надстройка над сайтом, а не отдельный продукт: сначала смотрим, что у вас есть и что тормозит. Иногда нужного эффекта добиваемся оптимизацией существующего сайта — без разработки заново.

Если речь о новом сайте на современном фронтенде, ориентир — цены разработки с /prices: от 150 000 ₽ за проект по брифу и от 350 000 ₽ за корпоративный сайт.

От чего зависит цена

  • Переделываем существующий сайт или делаем новый
  • Нужна ли работа офлайн и установка на устройство
  • Объём каталога и число интеграций
  • Насколько запущена текущая скорость

На iPhone возможности таких приложений ограничены системой — об этом ниже, до начала работы.

Честно о границах

Кому подходит эта услуга

Подходит, если

  • Большая часть посетителей с телефонов, и сайт заметно тормозит именно у них
  • Нужны повторные визиты и быстрый доступ, но бюджет нативного приложения не оправдан
  • Скорость уже стоит денег: люди уходят, не дождавшись загрузки каталога

Мы не подойдём, если

  • Нужны возможности, которые доступны только нативному приложению: сложная работа с устройством, фоновые задачи, магазины приложений как канал продаж
  • Аудитория преимущественно на iPhone и ключевое требование — push-уведомления как главный канал
  • Проблема не в скорости, а в том, что на сайт никто не приходит: тогда сначала нужен трафик, а не переделка
Почему мы

Почему выбирают именно нас

⚡

Скорость — наша религия

Каждый килобайт JS проходит проверку. Каждое изображение — WebP + lazy load. Core Web Vitals 95+ везде.

🔬

Real User Monitoring

Замеряем скорость у реальных пользователей, не только через Lighthouse. Находим и чиним медленные страницы.

🚀

Правильный стек под задачу

Astro для статики, Next.js для динамики, Remix для форм. Не «мы делаем только Next.js».

🎯

SEO с первого запроса

SSR/SSG — Googlebot получает полный HTML сразу. Не «через 30 секунд когда JS отработает».

Этапы работы

Как мы работаем

1

Бриф и выбор стека

1-2 недели

Обсуждаем задачи, аудиторию, интеграции, команду поддержки. Определяем оптимальный фреймворк (Next/Nuxt/Astro/Remix).

2

Архитектура

2 недели

Проектируем структуру данных, API, роутинг, кеширование. Выбор Headless CMS и хостинга.

3

Дизайн и UX

3-4 недели

Финальный дизайн с учётом mobile-first, thumb-zone, скорости взаимодействия. Прототипы всех типов страниц.

4

Разработка

6-12 недель

Frontend + Backend + интеграции. TDD подход, автоматизированные тесты каждой фичи.

5

Оптимизация скорости

2 недели

Финальная оптимизация: bundle size, lazy loading, prefetching, CDN, кеширование. Замеры на реальных устройствах.

6

QA и запуск

2 недели

Кросс-браузерное тестирование, Lighthouse audit на всех страницах, PWA-проверка, load testing.

Что PWA может и чего не может

Формулировка «почти нативное приложение без бюджета на разработку» верна лишь отчасти. Границы стоит знать до старта.

ВозможностьКак есть на самом деле
Иконка на экране телефонаРаботает и на Android, и на iOS, но на iPhone установка не так очевидна для пользователя: её нужно подсказывать
Работа без интернетаРаботает: ранее открытое содержимое и каталог можно показать из кеша
Push-уведомленияНа Android работают давно. На iPhone — с ограничениями и только для добавленного на экран приложения, поэтому строить на них основную коммуникацию рискованно
Быстрый повторный входЗдесь и есть основной выигрыш: повторные открытия действительно ощутимо быстрее
Магазины приложенийВ App Store и Google Play такое приложение не попадает: если нужен магазин как канал, нужно нативное
Индексация в поискеПреимущество перед нативным: содержимое остаётся обычными страницами сайта и участвует в выдаче

Что на самом деле влияет на скорость

Переписывать сайт на новом фреймворке ради скорости стоит далеко не всегда: чаще всего время съедают вещи попроще.

  • Тяжёлые несжатые изображения — самая частая причина, и исправляется быстрее всего
  • Десяток сторонних скриптов: чаты, аналитика, пиксели, виджеты. Каждый добавляет задержку, а половина из них давно не нужна
  • Шрифты, которые грузятся до отрисовки текста
  • Медленный ответ сервера: дешёвый хостинг и запросы к базе без кеширования
  • Реклама и баннеры, из-за которых страница прыгает под пальцем — формально это не скорость, но раздражает сильнее всего

Как понять, окупилось ли

  • Скорость загрузки у реальных посетителей, а не в тестовом прогоне на офисном интернете
  • Доля ушедших с первого экрана на мобильных — до и после
  • Путь до заявки: сколько людей доходит от каталога до формы
  • Повторные визиты с мобильных: ради них обычно всё и затевается
  • Обращения из поиска: если после переделки они падают, значит, что-то потерялось при переезде
Принципы

Наши принципы работы

⚡

Меряем у реальных посетителей

Не в тестовом прогоне на офисном интернете, а по данным живых визитов с телефонов: там видно настоящую картину.

📱

Mobile-first, всегда

Проектируем под мобильный, потом адаптируем под десктоп. Не наоборот.

🎯

Только нужный код

Никаких больших библиотек ради одной функции. Tree-shaking, code splitting, dynamic imports.

🔍

SEO не пострадает от JS

SSR/SSG/ISR — Googlebot получает полный HTML. Не «через 30 секунд когда React отработает».

FAQ

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

PWA vs нативное приложение?

PWA — это сайт с UX приложения: устанавливается на телефон, работает офлайн, шлёт push-уведомления. Плюсы: не нужен App Store (нет 30% комиссии Apple/Google), обновления моментальные, разработка в 3-5 раз дешевле нативного, единая кодовая база на iOS/Android/десктоп. Минусы: нет доступа к некоторым нативным API (например, Bluetooth). Для 80% бизнесов PWA закрывает задачи.

Next.js vs Nuxt vs Astro?

Next.js — React, самая большая экосистема, лучше для сложных приложений с интерактивом. Nuxt — Vue, чуть проще для команд знающих Vue. Astro — MPA (много маленьких страниц), идеален для контентных сайтов, статики, документации, блогов — максимальная скорость. Выбираем на этапе брифа под задачи и команду поддержки.

Что если моя команда не знает React?

Три варианта: (1) обучим вашу команду за 2-4 недели во время разработки, (2) поставим Nuxt/Vue если команда знает Vue, (3) поставим Astro с минимумом JS — там достаточно знать HTML/CSS + чуть-чуть JavaScript. Обычно после запуска клиент нанимает одного React-разработчика на поддержку.

Сколько стоит хостинг?

Зависит от того, что за сайт. Статический сайт можно держать почти бесплатно на бесплатных тарифах хостингов. Сайту с серверным рендерингом нужен сервер — это обычно несколько тысяч рублей в месяц. Для высокой нагрузки считаем отдельно. Точные цифры назовём под ваш проект, когда будет понятен объём.

Как быть с SEO при JavaScript-рендеринге?

Мы всегда делаем SSR (Server-Side Rendering) или SSG (Static Site Generation) — Googlebot получает полный HTML с первого запроса. Никакого «SPA белый экран для поисковика». Дополнительно: schema.org разметка, sitemap.xml, hreflang для мультиязычности, canonical URLs. После запуска проверяем в Search Console, как робот видит страницы, — именно на этом шаге обычно всплывают проблемы рендеринга.

Работаете с существующим WordPress?

Да, два варианта. (1) Headless WordPress: оставляем WP как CMS для контент-редакторов, но фронт полностью переписываем на Next.js/Astro — получаем скорость PWA и удобство WP админки. (2) Постепенная миграция: переписываем страницы по кластерам, начиная с самых важных (главная, категории с большим трафиком). SEO не страдает — правильные редиректы.

PWA работает на iPhone?

Да, но с ограничениями vs Android. На iOS PWA умеет: устанавливаться на home screen, работать офлайн, кешировать данные. НЕ умеет: push-уведомления в full-mode (только когда PWA открыта), доступ к некоторым API. С iOS 17+ поддержка выросла — Apple явно движется в сторону PWA под давлением ЕС.

Бесплатная консультация 30 минут

Расскажите про задачу — ответим в течение 1 рабочего дня.

Обсудить проект