Настройка заголовков и кеша не спасает медленной скорости интернета.
Клиент будет делать запрос на сервер и ждать, когда загрузиться html и всё остальное.
В SW иначе, первым делом достаются данные из кеша SW, а потом остальное Тем самым время Time to Interactive сводится к минимуму, т.к. не зависит от сети.
Как итог показываем, что приложение работает, но проблема ответа в скорости сети (так себя ведут мобильные приложения)
Кажется статья слишком стара для текущего года (2018 на дворе как никак), имеется Docker для настройки окружения + знания по настройке поможет на работе, где контейнерах и микросервисы.
Ну и между прочим тот же VirtualBox не нужен, в WindowStore есть Ubuntu, которая предоставляет возможности по используванию Linux.
ну у Вас же не всегда открыт тот ресурс, за которым Вы следите?
В т.ч. я упомянул в примере сервис (Tinder) с чатами.
На мой взгляд web-push будет здесь полезным.
Спасибо большое!
При редактировании статьи выносил общие части, чтобы кода было меньше. В итоге, не тот кусок оставил.
Для справки: свойство keys нужно для отправки данных с payload, если же вам нужно просто пропушить клиенты без передачи данных, то keys не нужен.
А как же приложения с чатами (Tinder) или те же медийные ресурсы (Tproger и Meduza)?
через них удобно узнавать про новый контент, особенно когда нет приложения/регистрации/подписок на рассылки. Разве нет?
Это уже проблема приложения, а не SW. Как я выше писал в своей статье, наша задача не просто не показывать «динозаврика», а показать своего «динозаврика» в стиле нашего приложения и была «наша» кнопка «обновить».
как я понимаю из вашего контекста, данная задача мало связана с SW.
Если мы говорим о SPA, то подобную задачу можно решить через тот же redux и управлением данными через store, то есть вы сами контролируете, какой листинг вы открыли и если есть данные в store, то запрос можно не делать, а брать данные прямиком из хранилища.
Да, в курсе про такие операции)
Это очень классная вещь)
Я хотел начать с базовых вещей, а далее, в последующих статьях хочется погрузиться в те же пуши, фоновые операции и в другие интересные вещи)
1. Про поддержку браузеров.
Как я знаю поддержка в таких браузерах как Safari или Edge находится в разработке.
Поэтому данная технология довольно-таки перспективна на мой взгляд.
Ровно как и часть крупных приложений уже начинают использовать их на проде (twitter, tinder, pinterest, smashingmagazine).
2 и 3
-5% -5% +25% — как сказал Артём Белов: “… сначала забирает, а потом добавляет с лихвой...”
По поводу прокси, пушей и как настроить общение между воркером и веб-страницей ещё будет статья. Тут идея была расписать базовые стратегии для кэширования и как их использовать, по сути “на пальцах“.
Касательно, выставить заголовки и т.п.
Базовые средства оптимизации никто не отменяет)
Кешировать надо все, что только возможно (с умом естественно), просто SW может помочь сделать приложение более отзывчивым и ускорить его отображение пользователю.
По поводу оффлайна:
А всё ли надо засовывать в оффлайн? На мой взгляд нужно лишь класть критичные файлы (css, js, html) и правильно обрабатывать ситуацию, когда нет доступа к сети, оставляя пользователя в приложении, а не заставляя его ждать минуту и в итоге показать Динозаврика.
Клиент будет делать запрос на сервер и ждать, когда загрузиться html и всё остальное.
В SW иначе, первым делом достаются данные из кеша SW, а потом остальное Тем самым время Time to Interactive сводится к минимуму, т.к. не зависит от сети.
Как итог показываем, что приложение работает, но проблема ответа в скорости сети (так себя ведут мобильные приложения)
Ну и между прочим тот же VirtualBox не нужен, в WindowStore есть Ubuntu, которая предоставляет возможности по используванию Linux.
Возьму на заметку
В т.ч. я упомянул в примере сервис (Tinder) с чатами.
На мой взгляд web-push будет здесь полезным.
При редактировании статьи выносил общие части, чтобы кода было меньше. В итоге, не тот кусок оставил.
Для справки: свойство keys нужно для отправки данных с payload, если же вам нужно просто пропушить клиенты без передачи данных, то keys не нужен.
через них удобно узнавать про новый контент, особенно когда нет приложения/регистрации/подписок на рассылки. Разве нет?
Хотелось наоборот избавиться от рутинных фраз и сделать материал более живым.
Да, PWA это про SW, но SW — это не про PWA.
> как по мне, так это не проблема, а вполне понятное, чёткое и однозначное информирование о том что интернета пока нет, займись чем-то другим!
Как я вижу в плане дизайна приложения был допущена ошибка, что пользователь явно не показал, что вы в Offline. По мне это решается довольно просто:
Это уже проблема приложения, а не SW. Как я выше писал в своей статье, наша задача не просто не показывать «динозаврика», а показать своего «динозаврика» в стиле нашего приложения и была «наша» кнопка «обновить».
Если мы говорим о SPA, то подобную задачу можно решить через тот же redux и управлением данными через store, то есть вы сами контролируете, какой листинг вы открыли и если есть данные в store, то запрос можно не делать, а брать данные прямиком из хранилища.
habrahabr.ru/company/2gis/blog/345552/#comment_10586162
О каких именно проблемах вы говорите? Поддержки сейчас нет в Safari — это правда, но как минимум SW в разработке для Safari и Edge.
Как говориться, подписывайтесь, ставьте лайки и комментируйте)))
Это очень классная вещь)
Я хотел начать с базовых вещей, а далее, в последующих статьях хочется погрузиться в те же пуши, фоновые операции и в другие интересные вещи)
Как я знаю поддержка в таких браузерах как Safari или Edge находится в разработке.
Поэтому данная технология довольно-таки перспективна на мой взгляд.
Ровно как и часть крупных приложений уже начинают использовать их на проде (twitter, tinder, pinterest, smashingmagazine).
2 и 3
-5% -5% +25% — как сказал Артём Белов: “… сначала забирает, а потом добавляет с лихвой...”
По поводу прокси, пушей и как настроить общение между воркером и веб-страницей ещё будет статья. Тут идея была расписать базовые стратегии для кэширования и как их использовать, по сути “на пальцах“.
Касательно, выставить заголовки и т.п.
Базовые средства оптимизации никто не отменяет)
Кешировать надо все, что только возможно (с умом естественно), просто SW может помочь сделать приложение более отзывчивым и ускорить его отображение пользователю.
По поводу оффлайна:
А всё ли надо засовывать в оффлайн? На мой взгляд нужно лишь класть критичные файлы (css, js, html) и правильно обрабатывать ситуацию, когда нет доступа к сети, оставляя пользователя в приложении, а не заставляя его ждать минуту и в итоге показать Динозаврика.