PWA - progressive web application. Это лучшее средство для борьбы с медленным интернетом. А также неплохой инструмент повышения лояльности клиента в коммерческих веб-приложениях (например интернет магазинах).
Большая часть людей пользуется 3G интернетом, с высокими пингами. Многие люди до сих пор контролируют свой трафик, особенно заграницей или в путешествии.
Интернет в России становится всё медленнее, что само по себе является ещё одним весомым фактом разрабатывать PWA приложения.
Правильно PWA приложение подчиняется некоторым правилам, одно из которых это ServiceWorker.
ServiceWorker это современный метод кеширования. Как правило представляет из себя JavaScript-файл (обычно ./sw.js) который регистрируется основным js-кодом приложения при помощи вызова процедуры navigator.serviceWorker.register('/sw.js')
Запускаясь в отдельном процессе и сохраняясь на диске пользователя, ServiceWorker начинает проксировать через себя трафик сайта.
Запросы могут быть кешированы через Cache API
При правильной настройке и кешировании основных файлов:
1. универсальный /index.html - точка входа
2. универсальный bundle.js и вспомогательный js файлы, например отвечающие за страницу или какой-то функционал приложения
3. универсальный style.css файл
Ваш пользователь будет всегда получать эти файлы локально, со своего браузера, даже в отсутствии сети интернет.
Для удобного развертывания sw.js файла существуют готовые утилиты, например google sw-precache и плагин к вебпак sw-precache-webpack-plugin. Также вы можете поиграть с hello world приложением, сделанным на preact, которое из коробки собирает PWA и показывает 100% по всем оценкам lighthouse
А теперь вернусь к вопросу топика, почему PWA это важно:
1. вы делаете свой сайт доступным даже для пользователей с медленным интернетом
2. ваш сайт становится значительно быстрее, что повышает лояльность клиента и увеличивает ваш трафик
3. вы значительно ослабляете нагрузку на ваши сервера, что позволяет делать highload-приложения с использованием минимальной серверной инфраструктуры
Что нужно обязательно заложить в архитектуру своего веб-приложения:
1. HTTPS - это позволит задействовать такие фишки http2, как например Server Push.
Грамотное использование Server Push ускоряет первоначальную загрузку приложения и снижает нагрузку на сервер, иногда в десятки раз. ServiceWorker работает только под HTTPS.
2. CDN с обязательным покрытием вашей целевой зоны и окружных зон, например России и Европы.
Многие пользователи в РФ и по всему миру вынуждены использовать VPN. Если ваши сервера расположены в РФ, а пользователь запрашивает их из Великобритании - есть шанс что он вынужден будет долго ждать ответа от сервера.
Ожидание более 3х секунд и 53% шанс что он нажмёт крестик на вкладке браузера. (по данным исследования Google Data, Aggregated, anonymized Google Analytics data from a sample of mWeb sites opted into sharing benchmark data, n=3.7K, Global, March 2016)
CDN позволит вам кешировать статические файлы и понизит нагрузку на сервер, также значительно повысив скорость отдачи.
3. Не отдавайте html-контент с динамическими данными. Вместо этого используйте пре-рендеринг или SSR (Server-Side Rendering), вместе с data-inline для CDN. Для динамических данных следует использовать исключительно API.
Чтобы понизить нагрузку на API, инлайним результат API в виде <script> и отдаём вместе с HTML.
Мне очень нравится подход команды разработчиков Instagram, их архитектура выглядит приблизительно так:
Request -> CDN (<- or) -> node.js server -> html page pre-rendering + api data inlined as <script>DATA=...</script>
Использование различных фреймворков вроде Django или CMS, таких как Magento должно быть исключительно в виде API. Иначе пользователь будет лишён скорости и вынужден будет ждать ответа на каждый запрос.
Рассмотрим пример, когда Вася Пупкин поднял свой сайт http://superpupersite.com на каком-нибудь Django и поставил впереди nginx.
Файлы js и css пропускаются через nginx и отдаются с Cache-Control: public, max-age=28800, но, толк от кеширования будет средний, ибо сценарий работы браузера будет идти следующим образом:
1. браузер устанавливает ip-адрес для superpupersite.com
2. браузер отправляет запрос handshake на сервер superpupersite.com
3. сервер отвечает и после установления "рукопожатия" браузер начинает проверку сертификата (при необходимости). Браузер держит keep-alive соединение с nginx. При 1000 активных клиентов это от 1000 и выше активных соединений.
4. после того как браузер убедился что сертификат действителен и рукопожатие совершено, браузер отправляет GET запрос на /.
5. nginx передаёт запрос Django (uwsgi), Django подключается к базе данных, проверяет куки, создаёт или открывает сессию, устанавливает новые куки при необходимости. Если база данных находится на отдельном сервере, то время ожидания соединения может увеличиться. Если на данном этапе база данных не отвечает - пользователь не получит никакого ответа вовсе, за исключением 503 или 502. Да и сам сервер может вдруг начать "ночной бекап" или какое-то другое действие, которое выведет его из строя на время.
6. прошло некоторое время, прежде чем питон выполнил программу, запустил шаблонизатор и собрал нам index.html, в которую вставлены стили и javascript файлы, а также разметка страницы.
7. nginx получил целиком текст страницы и отправил браузеру.
8. браузер в процессе получения начинает парсинг страницы и сбор ссылок для загрузки.
9. только на этом этапе его max-age=28800 сработает и браузер отдаст кеш (если он был). Как мы видим никакого выигрыша в скорости загрузки это не дало. Если кеша нет, тогда на каждую новую найденную ссылку, создаётся новый запрос к серверу, например GET /styles.css.
Неплохое PWA приложение с похожей архитектурой, могло бы выглядеть примерно таким образом:
Новый клиент:
1. браузер устанавливает ip-адрес для CDN superpupersite.com с поправкой - браузер с высокой вероятностью УЖЕ знает ip адрес для этой CDN (fastly, cloudflare и другие)
2. браузер отправляет запрос handshake на сервер superpupersite.com
3. сервер отвечает и после установления "рукопожатия" браузер начинает проверку сертификата (при необходимости). Браузер держит keep-alive соединение с CDN. Ваш сервер при этом возможно и вовсе отдыхает.
4. после того как браузер убедился что сертификат действителен и рукопожатие совершено, браузер отправляет GET запрос на /.
5. CDN сразу отвечает (вероятно в режиме Transfer-Encoding: chunked, на что не способен шаблонизатор) и посылает браузеру Server-Push со ссылками на sw.js, style.css, и bundle.js. В это время пользователь уже видит сайт и может с ним работать. Flash of unstyled content не происходит, благодаря critical css, вставленному прямо в содержимое html, до <body>
6. при помощи http2 все файлы из server-push разом загружаются параллельно с загрузкой основного html файла.
7. Полностью отрендерив страницу браузер сначала запрашивает основной js-контент, а затем делает запрос за sw.js.
8. CDN сразу же отдаёт статические файлы и вместе с sw.jd отдаётся список всех возможных css и js файлов, а также многочисленных изображений и шрифтов.
9. браузер фоном загружает все эти файлы и сохраняет их в Cache API.
10. наш js полностью загрузился и готов к работе, пользователь не заметил этого, ведь он еще не успел даже ознакомиться с контентом на странице.
11. js делает запрос к нужному серверу API и догружает динамические данные при необходимости
Клиент который уже посещал сайт:
1. браузер запускает sw.js для superpupersite.com
2. sw.js сразу же отдаёт пользователю отрендеренную страницу со всеми стилями, шрифтами и js-скриптами. В это время пользователь уже видит сайт и может с ним работать. Flash of unstyled content не происходит, благодаря тому что все стили уже загружены в браузер. Critical CSS не требуется.
3. браузер устанавливает ip-адрес для CDN ...
Немного про меня:
Специализируюсь на e-commerce системах с высокой нагрузкой. Также имею обширный опыт в SEO.
Готов делиться своими секретами, если кому-то на tjournal это интересно.
На этом пока всё. Лайк если было полезно.
Если есть какие-то вопросы задавайте в комментариях.
Комментарий недоступен
Выходит Гугл втирает какую-то дичь?
Комментарий недоступен
А посещалка у тебя откуда будет, разве не из гугла?
Комментарий недоступен
Возможно я просто неправильно изъяснился, речь идёт о коммерческом трафике. О каких цифрах идёт речь и что было источником трафика?
Если не изменяет память, то PWA это про нативочку от браузеров (моб/деск), так что это меньше про сайты, а больше про полезные приклады и сервисы
Это концепция reliable, fast, engaging веб приложений. Например TJournal это веб приложение. Подробнее тут https://developers.google.com/web/progressive-web-apps/
Не, это когда ты запускаешь приложуху с рабочего стола или с телефонного хомяка, а у тебя открывается браузерный экстеншн над сервисом с манифестом и прочим говном и маскируется под натив
Возможность добавить веб-приложение на Home screen это конечно одна из фишек PWA, но добавить можно также и любое другое веб-приложение
Комментарий недоступен
Ну вот пример из реального проекта, первый скриншот загрузка из sw.js, второй скриншот загрузка с отключенным sw.js (справедливости ради через http2 с server-push и cdn). Также в этом примере тестирование производится без троттлинга и со скоростным интернетом и скоростной пекарней. В реальности же такие тесты обычно производятся по другому.
Комментарий недоступен
Комментарий недоступен
А есть тут ребятки, скажем, готовые за небольшую благодарность рассказать мне по скайпу за фронтенд и вообще че куда двигать по скайпу на выходных? Знаю хтмл сиэсэс. Интересно жс, реакт и вот это все, но пока чет очень сложно дается
Комментарий недоступен
Отлично
Комментарий недоступен
Легче чем реакт, но опять же не понимаю зачем и для чего
Комментарий недоступен
в каком плане "сложно дается"?
выучил, но не можешь применять? Или очень тяжело учится?
Да не сложно вроде, просто не понятно как это на практике применяется по сути. В большей степени волнует то, что как писать так, чтобы не стыдно и чтобы это можно было переиспользовать без минимальных потерь
Комментарий недоступен