Создание PWA веб приложений

Что такое Progressive Web Apps (PWA)

Progressive Web Apps (PWA) — это веб‑приложения, которые используют стандартные веб‑технологии (HTML, CSS, JavaScript), но при этом ведут себя как нативные приложения на устройствах. Они объединяют лучшие стороны сайтов и мобильных приложений.

Основные характеристики

• Установка на устройство Пользователь может «установить» сайт как приложение: оно получает собственную иконку на рабочем столе или в меню приложений.

• Работа офлайн С помощью Service Workers PWA могут кэшировать данные и работать даже без подключения к интернету.

• Нативный интерфейс Запускаются в отдельном окне без браузерных элементов, создавая ощущение полноценного приложения.

• Кроссплатформенность Один код работает на разных устройствах и ОС (Windows, Android, iOS, macOS).

• Автоматические обновления Обновляются так же, как сайты — без необходимости скачивать новые версии из магазина.

Преимущества

• Для бизнеса: дешевле, чем разработка отдельных приложений для iOS и Android.

• Для пользователей: удобный доступ, меньше места на устройстве, возможность работы офлайн.

• Для разработчиков: единый код, простота поддержки и масштабирования.

Ключевые элементы PWA

Файл manifest.webmanifest используется в Progressive Web Apps (PWA).

Что это значит

• Это Web App Manifest — JSON‑файл, который описывает параметры веб‑приложения.

• Он сообщает браузеру, как сайт должен вести себя при установке на устройство: название, иконки, цвет темы, ориентация экрана и т.д.

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

Ключевые моменты

• Тип приложений: Progressive Web Apps (PWA).

• Формат: JSON с MIME‑типом application/manifest+json.

• Назначение: превращает сайт в «почти нативное» приложение — с иконкой, полноэкранным режимом, возможностью работать офлайн.

Почему браузер автоматически создал «приложение» из веб-страницы

Современные браузеры (особенно Chrome, Edge и др.) могут предлагать установить сайт как PWA — Progressive Web App.
Если сайт соответствует определенным условиям, браузер автоматически показывает кнопку «Установить приложение» или даже устанавливает его сам (в некоторых системах).

💡 Условия, по которым браузер решает, что сайт — это приложение:

1. Наличие manifest.json — специального файла с описанием приложения:

   { "name": "My App", "start_url": "/", "display": "standalone", "icons": [...] } 

2. Поддержка HTTPS — сайт должен работать по защищенному протоколу.

3. Service Worker — скрипт, который управляет кэшем и сетевыми запросами (например, для офлайн-режима).

4. Сайт ведет себя как приложение (например, без видимой адресной строки, с иконкой и собственной оболочкой).

В результате браузер создает из страницы изолированное приложение (WebApp), запускаемое отдельно от вкладок.

Как проверить, что AJAX-запросы идут из приложения, а не из обычной вкладки браузера

Есть несколько способов различить эти случаи — от простых до продвинутых.

1. Проверить заголовки запроса (User-Agent, Referer)

• PWA (установленное приложение) обычно не имеет Referer (или имеет его как null).

• У обычной вкладки будет Referer с URL страницы.

На сервере (PHP-пример):

if (empty($_SERVER['HTTP_REFERER'])) { echo "Probably PWA or standalone app"; } else { echo "Browser tab: " . $_SERVER['HTTP_REFERER']; } 

2. Проверить контекст на стороне клиента

На JS можно определить, открыт ли сайт как PWA:

if (window.matchMedia('(display-mode: standalone)').matches) { console.log('Running as installed PWA'); } else { console.log('Running in browser tab'); } 

Можно передавать это в AJAX-запрос:

fetch('/api/check', { method: 'POST', headers: { 'X-From-PWA': window.matchMedia('(display-mode: standalone)').matches ? 'yes' : 'no' } }); 

3. Использовать разные origin или scope в manifest.json

PWA может иметь отдельный scope, например /app/, тогда все AJAX-запросы из него будут иметь соответствующий Origin и Referer.

4. Проверить наличие Service Worker

Если запросы обрабатываются через Service Worker, можно смотреть:

• В DevTools → Application → Service Workers

• В консоли или сети: если запрос идет «from ServiceWorker», значит это PWA.

Кратко:

Если приложение не использует Service Worker, то поведение с кэшированием работает по-другому —
и действительно может сбивать с толку, особенно у PWA, созданных «автоматически» браузером.

Разберем подробно:

Что происходит, если Service Worker отсутствует

Когда ты устанавливаешь сайт как приложение (PWA или просто «ярлык» через Chrome → "Добавить на рабочий стол"),
браузер делает следующее:

1. Создает отдельный контейнер (WebApp) с минимальной оболочкой.

2. Открывает сайт в режиме display-mode: standalone — без адресной строки.

3. Продолжает использовать обычное кэширование браузера — то есть:

   • HTTP кэш (Cache-Control, ETag, Last-Modified);

   • кэширование DNS и ресурсов (JS, CSS, изображений);

   • локальные данные (localStorage, IndexedDB, cookies).

То есть в этом случае обновления зависят не от Service Worker, а от стандартных правил HTTP-кэширования.

Почему все равно может казаться, что скрипты «не обновляются»

Есть несколько причин:

1. Об этом говорит сайт https://intellect.icu . HTTP-заголовки разрешают кэш

Проверь, что сервер не отправляет слишком «долгий» кэш.
Например, это плохой пример:

Cache-Control: public, max-age=31536000 

Это заставляет браузер хранить JS-файлы целый год.

Лучше:

Cache-Control: no-cache 

или:

Cache-Control: max-age=0, must-revalidate 

2. Файл тот же URL — браузер не перезапрашивает

Браузер может подумать, что main.js не изменился,
и брать его из локального кэша (особенно в standalone-режиме).

Решение — добавить версионирование:

3. PWA (или standalone) хранит кэш дольше, чем вкладка

Chrome и Edge часто агрессивнее кэшируют ресурсы в режиме приложения,
чтобы запуск был моментальным.
В этом случае обновления подтягиваются только после принудительной проверки (Ctrl+F5)
или при изменении заголовков.

4. Offline Cache / AppData (Windows)

Если пользователь установил приложение через Chrome,
файлы могут сохраняться в системной папке вроде:

%LOCALAPPDATA%\Google\Chrome\User Data\Default\Web Applications\ 

Иногда Chrome берет оттуда статичные ресурсы (старые версии JS).
Удаление приложения или его данных решает проблему.

Как проверить, откуда грузятся скрипты

1. Открой DevTools → Network.

2. Обнови страницу внутри приложения (Ctrl+R).

3. Посмотри на колонку Size или Status:

   • from disk cache / from memory cache → старый кэш.

   • 200 OK → файл реально загружен с сервера.

Также можно очистить кэш конкретного домена:

chrome://settings/clearBrowserData 

или для конкретного сайта:

chrome://inspect/#apps 

Вывод оп кешированию

Если у пользователя установлено приложениемно на сайте удали тег с manifest.json, то приложэение продолжит запускаться?

Это важный нюанс поведения установленных PWA (Progressive Web Apps).

Короткий ответ

Да, приложение продолжит запускаться,
даже если ты удалишь тег с сайта.

Вот несколько надежных способов на JavaScript определить, что пользователь открыл установленное приложение (PWA),
даже если manifest.json больше не существует на сайте.

1. Проверка режима отображения (display-mode)

Самый надежный и простой способ — через window.matchMedia:

if (window.matchMedia('(display-mode: standalone)').matches) { 
    console.log(' Запущено как установленное приложение (PWA)'); 
} else {
    console.log(' Открыто во вкладке браузера');
 } 

Это работает даже без manifest.json,
потому что браузер запоминает display-mode при установке приложения.

2. Проверка по navigator.standalone (для iOS/Safari)

Safari на iOS использует свой флаг:

if (window.navigator.standalone) { 
    console.log('Установленное приложение на iOS'); 
} 

Этот флаг есть только в Safari (не в Chrome/Edge).

3. Комбинированный универсальный вариант

Чтобы поддержать все платформы:

function isRunningAsApp() {
    return ( window.matchMedia('(display-mode: standalone)').matches || window.navigator.standalone === true ); 
} 

if (isRunningAsApp()) { 
console.log('Приложение запущено в standalone режиме');
 } else { 
console.log(' Обычная вкладка браузера');
 } 

4. Проверка через document.referrer (дополнительно)

Установленные приложения часто не имеют Referer,
в отличие от обычных вкладок:

if (!document.referrer) {
 console.log('Вероятно, запущено как отдельное приложение');
 } else { console.log('Открыто с другой страницы или вкладки'); 
} 

Можно использовать это как дополнительный сигнал.

5. Проверка источника загрузки (через window.location)

Иногда установленное приложение может иметь специальный start_url
(например, /app/ или /home.html), отличный от обычного сайта.

Можно сделать так:

if (window.location.pathname.startsWith('/app')) { console.log(' Приложение запущено с app-пути'); } 

Это удобно, если при установке ты задавал start_url в manifest.json.

Бонус: отправить на сервер факт, что запущено как PWA

Можно добавить в твой AJAX-код:

fetch('/api/ping', { method: 'POST', headers: { 'X-From-PWA': isRunningAsApp() ? 'true' : 'false' } }); 

Тогда на сервере (PHP, например) ты сможешь различать:

if ($_SERVER['HTTP_X_FROM_PWA'] === 'true') { // код для приложения } 

Проверить в DevTools

Если хочешь убедиться, что условие работает:

• Открой приложение (установленное).

• Открой DevTools → Console.

• Вставь код из п.1.

• Должно показать "Запущено как установленное приложение (PWA)".

Рассмотрим подробне удобство start_url в manifest.json.

Давай подробно разберем, что такое start_url в manifest.json,
и почему он важен — особенно если ты работаешь с установленным приложением (PWA).

Что такое start_url

start_url — это путь (URL), с которого запускается установленное веб-приложение (PWA).

Он задается в файле manifest.json, например:

{ "name": "My Cool App", "start_url": "/app/home.html", "display": "standalone", "icons": [ { "src": "/icons/icon192.png", "sizes": "192x192", "type": "image/png" } ] } 

Что делает start_url

Когда пользователь устанавливает сайт как приложение, браузер:

• сохраняет это значение (/app/home.html);

• и потом всегда открывает приложение именно с этого URL,
  даже если пользователь нажимает на ярлык, а не на ссылку.

То есть — это «точка входа» твоего приложения.

Пример

Допустим, твой сайт:

https://example.com/ 

а в manifest.json ты прописал:

"start_url": "/dashboard" 

Теперь:

• при открытии приложения из меню/ярлыка браузер запустит:
  https://example.com/dashboard

• но если пользователь просто откроет сайт вручную, то он увидит https://example.com/

То есть это позволяет разделить поведение между:

• сайтом для обычных посетителей;

• и приложением для установленных пользователей.

Почему это удобно

Потому что ты можешь:

• направить приложение на другой интерфейс (/app/, /panel/, /offline.html);

• использовать разные версии сайта;

• или показывать другой JS-файл / другой layout,
  специально для установленных пользователей.

Пример использования

Ты можешь использовать start_url совместно с JS-проверкой:

if (window.matchMedia('(display-mode: standalone)').matches) { console.log('App started from', window.location.href); } 

И если window.location.pathname совпадает со значением из start_url,
значит, пользователь запустил установленное приложение, а не просто открыл сайт.

Кратко:

Если в manifest.json не указан параметр start_url?

Давай разберем — что происходит, если в manifest.json не указан параметр start_url.

Короткий ответ

Если в manifest.json нет поля "start_url",
то браузер по умолчанию использует URL страницы,
с которой пользователь установил приложение.

Подробное объяснение

Когда пользователь нажимает «Установить приложение» (или «Добавить на рабочий стол»),
браузер смотрит:

«С какой страницы я сейчас устанавливаюсь?»

Если в manifest.json нет start_url, то он просто сохраняет текущий адрес
и делает его точкой запуска.

Пример 1 — без start_url

manifest.json:

{ "name": "MyApp", "display": "standalone" } 

Пользователь установил сайт с:

https://example.com/index.html 

После установки приложение всегда будет запускаться с

https://example.com/index.html 

Пример 2 — с подстраницей

Если пользователь установил приложение из другой страницы, например:

https://example.com/app/dashboard 

Тогда при запуске приложения оно всегда будет открываться именно на этом URL,
даже если ты потом изменишь структуру сайта.

Возможные проблемы

1. Непредсказуемое поведение
   Если разные пользователи устанавливают приложение с разных страниц,
   у каждого будет своя «точка входа».
   Один будет попадать на /, другой — на /shop/, третий — на /app/dashboard.

2. Проблемы при обновлении
   Если ты меняешь маршруты или удаляешь ту страницу,
   с которой приложение было установлено, —
   у пользователя может появиться ошибка 404 при запуске.

3. Нельзя централизованно управлять стартом приложения,
   потому что URL зависит от того, где пользователь находился во время установки.

Рекомендация

Лучше всегда указывать start_url явно, например:

{ "name": "MyApp", "short_name": "App", "start_url": "/app/", "display": "standalone", "background_color": "#ffffff", "theme_color": "#2196f3", "icons": [ { "src": "/icons/192.png", "sizes": "192x192", "type": "image/png" }, { "src": "/icons/512.png", "sizes": "512x512", "type": "image/png" } ] } 

Так ты контролируешь, откуда приложение стартует у всех пользователей,
и можешь специально подготовить интерфейс под display-mode: standalone.

Итого:

Короткий ответ

Нет функциональной разницы между:

Будет ли работать такое приложение запущенное через явлык пользователем если сайт-сервер недоступен или у пользователя отключен интернет?