Лекция
Привет, Вы узнаете о том , что такое pwa-приложения, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое pwa-приложения , настоятельно рекомендую прочитать все из категории Выполнение скриптов на стороне клиента JavaScript, jqvery, JS фреймворки (Frontend).
Progressive Web Apps (PWA) — это веб‑приложения, которые используют стандартные веб‑технологии (HTML, CSS, JavaScript), но при этом ведут себя как нативные приложения на устройствах. Они объединяют лучшие стороны сайтов и мобильных приложений.
Установка на устройство Пользователь может «установить» сайт как приложение: оно получает собственную иконку на рабочем столе или в меню приложений.
Работа офлайн С помощью Service Workers PWA могут кэшировать данные и работать даже без подключения к интернету.
Нативный интерфейс Запускаются в отдельном окне без браузерных элементов, создавая ощущение полноценного приложения.
Кроссплатформенность Один код работает на разных устройствах и ОС (Windows, Android, iOS, macOS).
Автоматические обновления Обновляются так же, как сайты — без необходимости скачивать новые версии из магазина.
Для бизнеса: дешевле, чем разработка отдельных приложений для iOS и Android.
Для пользователей: удобный доступ, меньше места на устройстве, возможность работы офлайн.
Для разработчиков: единый код, простота поддержки и масштабирования.
| Элемент | Назначение |
|---|---|
| manifest.webmanifest | JSON‑файл с настройками (название, иконки, цвет темы, стартовый URL). |
| Service Worker | Скрипт для кэширования, офлайн‑режима и push‑уведомлений. |
| HTTPS | Обязательное условие для безопасности и работы Service Workers. |
| Responsive Design | Адаптация интерфейса под разные устройства. |
| Критерий | Progressive Web App (PWA) | Режим киоск |
|---|---|---|
| Назначение | Сделать сайт похожим на нативное приложение, доступным для установки на устройство | Ограничить устройство до работы только с одним приложением/сайтом |
| Файл манифеста | manifest.webmanifest описывает название, иконки, цвета, стартовый URL | Обычно не используется; настройка идет через ОС или сторонние приложения |
| Установка | Устанавливается пользователем добровольно (иконка на рабочем столе, меню приложений) | Администратор включает режим, и устройство запускает только выбранное приложение |
| Гибкость | Можно запускать как обычный сайт или как приложение | Жесткое ограничение: пользователь не может выйти за пределы выбранного приложения |
| Офлайн‑режим | Поддерживается через Service Worker | Зависит от приложения, но сам режим киоск не добавляет офлайн‑функций |
| Безопасность | Требует HTTPS, можно добавить push‑уведомления и кэширование | Основная цель — физическая и логическая защита: исключить доступ к другим функциям устройства |
| Применение | Удобно для сайтов, которые хотят быть «как приложение» (магазины, сервисы, новостные порталы) | Используется в публичных терминалах, интерактивных стойках, точках самообслуживания |
PWA — это про удобство и универсальность: сайт превращается в приложение.
Киоск‑режим — это про контроль и ограничение: устройство работает только в одном приложении, чтобы исключить лишние действия пользователя.
Это Web App Manifest — JSON‑файл, который описывает параметры веб‑приложения.
Он сообщает браузеру, как сайт должен вести себя при установке на устройство: название, иконки, цвет темы, ориентация экрана и т.д.
Наличие такого файла — обязательное условие для того, чтобы сайт можно было установить как приложение на смартфон или компьютер.
Тип приложений: Progressive Web Apps (PWA).
Формат: JSON с MIME‑типом application/manifest+json.
Назначение: превращает сайт в «почти нативное» приложение — с иконкой, полноэкранным режимом, возможностью работать офлайн.
Современные браузеры (особенно Chrome, Edge и др.) могут предлагать установить сайт как PWA — Progressive Web App.
Если сайт соответствует определенным условиям, браузер автоматически показывает кнопку «Установить приложение» или даже устанавливает его сам (в некоторых системах).
Наличие manifest.json — специального файла с описанием приложения:
{ "name": "My App", "start_url": "/", "display": "standalone", "icons": [...] }
Поддержка HTTPS — сайт должен работать по защищенному протоколу.
Service Worker — скрипт, который управляет кэшем и сетевыми запросами (например, для офлайн-режима).
Сайт ведет себя как приложение (например, без видимой адресной строки, с иконкой и собственной оболочкой).
В результате браузер создает из страницы изолированное приложение (WebApp), запускаемое отдельно от вкладок.
Есть несколько способов различить эти случаи — от простых до продвинутых.
PWA (установленное приложение) обычно не имеет Referer (или имеет его как null).
У обычной вкладки будет Referer с URL страницы.
На сервере (PHP-пример):
if (empty($_SERVER['HTTP_REFERER'])) { echo "Probably PWA or standalone app"; } else { echo "Browser tab: " . $_SERVER['HTTP_REFERER']; }
На 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' } });
PWA может иметь отдельный scope, например /app/, тогда все AJAX-запросы из него будут иметь соответствующий Origin и Referer.
Если запросы обрабатываются через Service Worker, можно смотреть:
В DevTools → Application → Service Workers
В консоли или сети: если запрос идет «from ServiceWorker», значит это PWA.
| Признак | Обычная вкладка | Установленное PWA |
|---|---|---|
| Referer | Есть | Часто null |
| display-mode | browser | standalone |
| Service Worker | Может отсутствовать | Почти всегда есть |
| Отображение | Вкладка с адресной строкой | Отдельное окно |
| User-Agent | Обычный браузер | Тот же, но без Referer |
Одна из ключевых особенностей PWA (Progressive Web App) — кэширование.
Действительно, если пользователь установил сайт как приложение, то браузер может использовать старую версию скриптов даже после обновлений сайта.
Разберем подробно, почему это происходит и как это контролировать.
Когда сайт становится PWA, в нем появляется Service Worker — это фоновый скрипт, который:
перехватывает все сетевые запросы,
может кэшировать HTML, JS, CSS, изображения и API-ответы,
возвращает кэшированные данные вместо загрузки с сервера.
Поэтому, если твой сайт обновился, но у пользователя уже установлен Service Worker с кэшированными версиями —
он будет видеть старые файлы (например, старый main.js), пока Service Worker не обновится.
Service Worker обновляется не мгновенно, а по определенным правилам:
Браузер проверяет, изменился ли service-worker.js (по контенту или ETag).
Если файл другой — создается «новая версия» Service Worker.
Новая версия устанавливается, но не активируется, пока пользователь не:
закроет все вкладки/окна приложения,
или не перезапустит PWA.
Только потом кэш обновляется.
Это значит, что обновления могут задерживаться на несколько часов или даже дней.
Вот как это делают на практике:
Добавляй номер версии в имена файлов:
или добавляй query-параметр:
Браузер считает это новым URL, поэтому кэш не используется.
В service-worker.js можно задать стратегию:
self.addEventListener('fetch', event => { event.respondWith( caches.open('my-cache-v3').then(cache => { return fetch(event.request).then(response => { cache.put(event.request, response.clone()); return response; }).catch(() => cache.match(event.request)); }) ); });
Обрати внимание на my-cache-v3 — когда ты изменяешь версию (v3 → v4), старый кэш будет сброшен.
В service-worker.js нужно добавить:
self.skipWaiting(); self.clients.claim();
Это заставит новый SW активироваться сразу, не дожидаясь закрытия старого.
Но будь осторожен — если в момент обновления пользователь что-то делает,
может произойти конфликт старых и новых кэшей (например, ошибки JS).
Можно сделать автоматическую проверку:
navigator.serviceWorker.getRegistration().then(reg => { if (reg) { reg.update(); // принудительная проверка новой версии } });
| Поведение | Причина | Решение |
|---|---|---|
| Скрипты не обновляются | Кэш Service Worker | Версионирование или update() |
| Сайт загружается офлайн | PWA кэширует все ресурсы | Настроить кэш стратегию |
| Пользователь видит старую версию | SW не активировался | skipWaiting(), clients.claim() |
Если приложение не использует Service Worker, то поведение с кэшированием работает по-другому —
и действительно может сбивать с толку, особенно у PWA, созданных «автоматически» браузером.
Разберем подробно:
Когда ты устанавливаешь сайт как приложение (PWA или просто «ярлык» через Chrome → "Добавить на рабочий стол"),
браузер делает следующее:
Создает отдельный контейнер (WebApp) с минимальной оболочкой.
Открывает сайт в режиме display-mode: standalone — без адресной строки.
Продолжает использовать обычное кэширование браузера — то есть:
HTTP кэш (Cache-Control, ETag, Last-Modified);
кэширование DNS и ресурсов (JS, CSS, изображений);
локальные данные (localStorage, IndexedDB, cookies).
То есть в этом случае обновления зависят не от Service Worker, а от стандартных правил HTTP-кэширования.
Есть несколько причин:
Проверь, что сервер не отправляет слишком «долгий» кэш.
Например, это плохой пример:
Cache-Control: public, max-age=31536000
Это заставляет браузер хранить JS-файлы целый год.
Лучше:
Cache-Control: no-cache
или:
Cache-Control: max-age=0, must-revalidate
Браузер может подумать, что main.js не изменился,
и брать его из локального кэша (особенно в standalone-режиме).
Решение — добавить версионирование:
Chrome и Edge часто агрессивнее кэшируют ресурсы в режиме приложения,
чтобы запуск был моментальным.
В этом случае обновления подтягиваются только после принудительной проверки (Ctrl+F5)
или при изменении заголовков.
Если пользователь установил приложение через Chrome,
файлы могут сохраняться в системной папке вроде:
%LOCALAPPDATA%\Google\Chrome\User Data\Default\Web Applications\
Иногда Chrome берет оттуда статичные ресурсы (старые версии JS).
Удаление приложения или его данных решает проблему.
Открой DevTools → Network.
Обнови страницу внутри приложения (Ctrl+R).
Посмотри на колонку Size или Status:
from disk cache / from memory cache → старый кэш.
200 OK → файл реально загружен с сервера.
Также можно очистить кэш конкретного домена:
chrome://settings/clearBrowserData
или для конкретного сайта:
chrome://inspect/#apps
| Ситуация | Что кэширует | Как обновить |
|---|---|---|
| Без Service Worker | Обычный HTTP-кэш браузера | Изменить заголовки или URL |
| С Service Worker | Программный кэш в JS | Обновить SW и версию кэша |
| Установленное PWA | Может хранить дольше | Очистка кэша или версия в URL |
Это важный нюанс поведения установленных PWA (Progressive Web Apps).
Да, приложение продолжит запускаться,
даже если ты удалишь тег с сайта.
Но:
Браузер больше не сможет обновлять информацию о приложении (иконку, имя, цвет темы, поведение и т.д.).
Когда пользователь устанавливает PWA (или «добавляет сайт на рабочий стол»), браузер:
Загружает manifest.json;
Сохраняет его содержимое в своем внутреннем хранилище (в профиле пользователя);
Создает системную «оболочку» для запуска приложения (.desktop, ярлык, иконка и т.п.);
Больше не зависит от наличия manifest.json на сервере при старте.
То есть после установки все уже локально:
Иконки — скопированы в систему;
Название — сохранено;
URL запуска (start_url) — записан;
Отображение (display-mode: standalone) — зафиксировано.
| Поведение | Результат |
|---|---|
| Приложение уже установлено | ✅ Продолжит работать |
| Пользователь откроет сайт в браузере | ❌ Кнопка «Установить» исчезнет |
| Переустановка | ❌ Невозможна — нет manifest.json |
| Обновление имени, иконки и т.п. | ❌ Не произойдет, браузер не сможет проверить |
| Удаление сайта и повторная установка | ⚠️ Невозможна без манифеста |
Установи сайт как приложение (через Chrome → ⋮ → «Установить приложение»).
После установки удали manifest.json или тег
Перезапусти приложение — оно откроется, потому что данные сохранены локально.
Открой тот же сайт во вкладке браузера — кнопки установки больше не будет.
Если в manifest.json раньше был start_url, то именно по нему приложение всегда открывается — даже если на сайте теперь другой код или структура.
Если сайт недоступен, приложение покажет ошибку соединения (нет Service Worker — нет офлайн-режима).
Chrome, Edge, Opera и другие Chromium-браузеры ведут себя одинаково.
Firefox — чуть иначе: он вообще слабо поддерживает PWA и может не запускать без манифеста после перезагрузки профиля.
| Действие | Поведение приложения |
|---|---|
| Удалить | Работает, но без обновлений |
| Удалить сам manifest.json | Работает, но не переустанавливается |
| Изменить manifest.json | Изменения не подхватятся до переустановки |
| Очистить данные сайта (AppData / Storage) | Приложение перестанет работать |
Вот несколько надежных способов на JavaScript определить, что пользователь открыл установленное приложение (PWA),
даже если manifest.json больше не существует на сайте.
Самый надежный и простой способ — через window.matchMedia:
if (window.matchMedia('(display-mode: standalone)').matches) {
console.log(' Запущено как установленное приложение (PWA)');
} else {
console.log(' Открыто во вкладке браузера');
}
Это работает даже без manifest.json,
потому что браузер запоминает display-mode при установке приложения.
Safari на iOS использует свой флаг:
if (window.navigator.standalone) {
console.log('Установленное приложение на iOS');
}
Этот флаг есть только в Safari (не в Chrome/Edge).
Чтобы поддержать все платформы:
function isRunningAsApp() {
return ( window.matchMedia('(display-mode: standalone)').matches || window.navigator.standalone === true );
}
if (isRunningAsApp()) {
console.log('Приложение запущено в standalone режиме');
} else {
console.log(' Обычная вкладка браузера');
}
Установленные приложения часто не имеют Referer,
в отличие от обычных вкладок:
if (!document.referrer) {
console.log('Вероятно, запущено как отдельное приложение');
} else { console.log('Открыто с другой страницы или вкладки');
}
Можно использовать это как дополнительный сигнал.
Иногда установленное приложение может иметь специальный start_url
(например, /app/ или /home.html), отличный от обычного сайта.
Можно сделать так:
if (window.location.pathname.startsWith('/app')) { console.log(' Приложение запущено с app-пути'); }
Это удобно, если при установке ты задавал start_url в manifest.json.
Можно добавить в твой AJAX-код:
fetch('/api/ping', { method: 'POST', headers: { 'X-From-PWA': isRunningAsApp() ? 'true' : 'false' } });
Тогда на сервере (PHP, например) ты сможешь различать:
if ($_SERVER['HTTP_X_FROM_PWA'] === 'true') { // код для приложения }
Если хочешь убедиться, что условие работает:
Открой приложение (установленное).
Открой DevTools → Console.
Вставь код из п.1.
Должно показать "Запущено как установленное приложение (PWA)".
Давай подробно разберем, что такое start_url в manifest.json,
и почему он важен — особенно если ты работаешь с установленным приложением (PWA).
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" } ] }
Когда пользователь устанавливает сайт как приложение, браузер:
сохраняет это значение (/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,
значит, пользователь запустил установленное приложение, а не просто открыл сайт.
Кратко:
| Свойство | Назначение |
|---|---|
| start_url | URL, с которого приложение запускается после установки |
| Работает где | В Chrome, Edge, Opera, Android WebView |
| Что делает | Определяет «точку входа» для PWA |
| Можно использовать для | Разделения логики сайта и приложения |
Давай разберем — что происходит, если в manifest.json не указан параметр start_url.
Короткий ответ
Если в manifest.json нет поля "start_url",
то браузер по умолчанию использует URL страницы,
с которой пользователь установил приложение.
Когда пользователь нажимает «Установить приложение» (или «Добавить на рабочий стол»),
браузер смотрит:
«С какой страницы я сейчас устанавливаюсь?»
Если в manifest.json нет start_url, то он просто сохраняет текущий адрес
и делает его точкой запуска.
{ "name": "MyApp", "display": "standalone" }
https://example.com/index.html
После установки приложение всегда будет запускаться с
https://example.com/index.html
Если пользователь установил приложение из другой страницы, например:
https://example.com/app/dashboard
Тогда при запуске приложения оно всегда будет открываться именно на этом URL,
даже если ты потом изменишь структуру сайта.
Непредсказуемое поведение
Если разные пользователи устанавливают приложение с разных страниц,
у каждого будет своя «точка входа».
Один будет попадать на /, другой — на /shop/, третий — на /app/dashboard.
Проблемы при обновлении
Если ты меняешь маршруты или удаляешь ту страницу,
с которой приложение было установлено, —
у пользователя может появиться ошибка 404 при запуске.
Нельзя централизованно управлять стартом приложения,
потому что 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.
| Сценарий | Что произойдет |
|---|---|
| start_url указан | Приложение всегда запускается с этого адреса |
| start_url не указан | Приложение запускается с того адреса, где было установлено |
| Страница была удалена | ❌ Приложение перестает работать (ошибка 404) |
| Рекомендация | ✅ Всегда явно указывать start_url |
и
Нет функциональной разницы между:
и
Оба варианта абсолютно равнозначны для браузера.
Главное, чтобы:
файл имел корректный MIME-тип (application/manifest+json);
и содержал валидный JSON.
Браузеру все равно, как называется файл —
manifest.json, manifest.webmanifest, или даже myapp.manifest.
Он ориентируется на:
rel="manifest" — это сигнал, что это PWA-манифест;
правильный MIME-тип (HTTP-заголовок);
корректный JSON-синтаксис.
Расширение .webmanifest — это новый рекомендуемый стандарт от W3C и Google Chrome.
Его ввели, чтобы:
отличать PWA-манифест от обычных JSON-файлов (например, config.json);
позволить серверам правильно выставлять MIME-тип по расширению.
Спецификация:
https://www.w3.org/TR/appmanifest/
Браузеры ожидают, что сервер отдает файл с типом:
Content-Type: application/manifest+json
Если сервер отдает application/json, Chrome и Edge все равно его примут,
но могут показать предупреждение в DevTools.
Если отдается что-то вроде text/plain — манифест игнорируется.
Открой в браузере свой manifest.webmanifest и посмотри в DevTools → Network → Headers.
В заголовках должно быть:
content-type: application/manifest+json
Если видишь application/json, это не критично, но можно поправить в .htaccess:
AddType application/manifest+json .webmanifest
| Критерий | .json | .webmanifest |
|---|---|---|
| Работает в браузерах | ✅ Да | ✅ Да |
| Рекомендуется стандартом | ⚠️ Нет | ✅ Да |
| Требует MIME-типа application/manifest+json | ✅ Желательно | ✅ Обязательно |
| Различие в функциональности | ❌ Нет | ❌ Нет |
| Зачем использовать .webmanifest | Для ясности и совместимости с будущими стандартами |
Используй:
и на сервере пропиши MIME-тип:
Так будет идеально по стандартам и без предупреждений в Chrome.
Это самое уязвимое место PWA, если оно не использует Service Worker.
Разберем четко, что произойдет.
Пользователь установил сайт как приложение (через ярлык).
Сайт теперь запускается в отдельном окне (display-mode: standalone).Что будет, если:
сервер недоступен (ошибка 500, 404, хост не отвечает),
или нет интернета?
Приложение не запустится.
Браузер при запуске такого ярлыка просто пытается загрузить тот же URL (из start_url или страницы установки).
Если:
сервер не отвечает,
нет подключения к сети,
или страница не загружена из кэша,
то пользователь увидит стандартную ошибку браузера:
“Нет подключения к Интернету”
“This site can’t be reached”
“ERR_INTERNET_DISCONNECTED”
Даже если приложение установлено, оно не автономное, если нет Service Worker.
Без Service Worker браузер не имеет права использовать кэшированные версии произвольно.
Он обращается напрямую к сети, и если сервер недоступен — все падает.
Service Worker же — это как «прокси в браузере», который может сказать:
«Сети нет? Тогда вот тебе сохраненная страница из кэша».
| Механизм | Что делает | Поможет офлайн? |
|---|---|---|
| manifest.json / webmanifest | Только описывает метаданные (имя, иконку, цвет и т.п.) | ❌ Нет |
| Добавление на рабочий стол | Создает ярлык и окно | ❌ Нет |
| HTTP Cache | Может держать ресурсы в памяти, но не гарантированно | ⚠️ Только если недавно открывал и не очистил кэш |
Браузерный кэш может «случайно» сохранить ресурсы,
и приложение может один раз открыться офлайн — но это не надежно.
Нужно добавить Service Worker, который:
Устанавливается при первом запуске.
Кэширует нужные файлы (index.html, main.js, style.css, картинки и т.п.).
При следующем запуске:
если интернет есть — загружает свежие файлы;
если нет — берет их из кэша.
Минимальный пример:
// service-worker.js
self.addEventListener('install', event => { event.waitUntil( caches.open('my-cache-v1').then(cache => { return cache.addAll([ '/', // главная страница '/index.html', '/style.css', '/main.js', '/icon.png' ]); }) ); }); self.addEventListener('fetch', event => { event.respondWith( fetch(event.request).catch(() => caches.match(event.request)) ); });
И подключение в HTML:
После этого:
Приложение сможет запускаться даже без сети,
показывать кешированные файлы или офлайн-страницу.
| Условие | Будет работать офлайн? |
|---|---|
| Без Service Worker | ❌ Нет |
| С Service Worker и кешем | ✅ Да |
| Сайт впервые открыт, но не кэширован | ❌ Нет |
| Сайт уже посещен, но сервер недоступен | ⚠️ Иногда (если повезет с HTTP-кэшем) |
Хочешь, я покажу пример Service Worker, который делает офлайн-режим с кастомной страницей "Вы офлайн",
чтобы пользователь видел красивое сообщение вместо ошибки браузера?
Да, это хороший момент — разберем подробно.
В manifest.json поле start_url задает URL, с которого будет запускаться установленное приложение.
"." в URL — это относительный путь, который указывает на текущую директорию файла манифеста.
То есть браузер будет запускать приложение с того же каталога, где лежит manifest.json.
Пример структуры:
Если в manifest.json указано:
И файл manifest.json лежит в корне /, то . → /
То есть приложение будет запускаться с /index.html (или /, в зависимости от сервера).
Если файл лежит в /app/manifest.json, то . → /app/.
Валидно. JSON-спецификация PWA позволяет использовать относительные пути.
Главное, чтобы при разрешении относительно местоположения манифеста получилось корректное URL.
В зависимости от расположения манифеста результат может быть разным.
Если manifest.json в корне → . = /
Если manifest.json в поддиректории /app/ → . = /app/
Лучше явно указывать путь относительно корня сайта для однозначности:
или
Совместимость с браузерами
Chrome, Edge, Opera корректно интерпретируют ".".
Safari (iOS) также работает, но иногда лучше использовать абсолютный путь для надежности.
| start_url | Что означает | Рекомендация |
|---|---|---|
| "." | Текущая директория манифеста | ✅ Работает, но относительный путь зависит от расположения файла |
| "/" | Корень сайта | ✅ Однозначно и безопасно |
| "/app/" | Поддиректория /app/ | ✅ Контролируемое поведение для PWA |
Исследование, описанное в статье про pwa-приложения, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое pwa-приложения и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Выполнение скриптов на стороне клиента JavaScript, jqvery, JS фреймворки (Frontend)
Комментарии