Можно ли создать прогрессивное веб-приложение без рендеринга на стороне клиента?

Сайт моей компании в основном обрабатывается сервером (мы используем структурированные фрагменты страниц), но мы хотели бы изучите создание прогрессивного веб-приложения.

Имеет ли смысл создавать прогрессивное веб-приложение, реализуя кэширование Service Worker для страниц, отображаемых сервером? В качестве альтернативы, следует ли нам рассмотреть возможность перехода к рендерингу на стороне клиента?

Обратите внимание, что мы хотели бы сделать как можно больше рендеринга на сервере, поскольку мы поддерживаем множество очень медленных устройств.


person owencm    schedule 17.02.2016    source источник


Ответы (2)


Да, сервис-воркеры определенно не ограничены рендерингом на стороне клиента.

Вы можете кэшировать все, что хотите. Например, этот плагин WordPress кэширует содержимое WordPress.

person Marco Castelluccio    schedule 18.02.2016

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

Я бы посоветовал вам сначала подумать об этом с точки зрения того, как вы хотите работать с вашим динамическим контентом, как в сети, так и в автономном режиме. Прочитав оффлайн-поваренную книгу Джейка Арчибальда, вы получите хороший обзор различных стратегий, которые можно реализовать. .

После того как вы определились со стратегией кэширования динамического контента, следующим шагом будет ее реализация. Подход «золотой стандарт» заключается в использовании App Shell + архитектура с динамическим содержимым, но может потребоваться некоторый рефакторинг, чтобы перевести существующее приложение на эту архитектуру, особенно если исходный HTML-код, возвращаемый сервером, содержит динамические/персонализированные элементы.

Если рефакторинг является слишком сложной задачей или если рендеринг только на сервере является жестким требованием, вы все равно можете использовать кэширование сервис-воркера, но вы, вероятно, в конечном итоге будете рассматривать свою будущую оболочку, как если бы это был динамический контент. . Это означает, что чистая стратегия «сначала кеш» может быть не «безопасной», а кэшированием. /сетевая гонка может работать или, по крайней мере, сеть , возвращаясь к кешу.

Используя обе эти стратегии, вы получите веб-приложение, которое будет работать в автономном режиме, но вы, вероятно, в конечном итоге будете кэшировать дублированные данные (например, если /page1 и /page2 имеют общую структуру HTML, вы в конечном итоге будете кэшировать это дважды ). Вы также получите удар по производительности и потреблению полосы пропускания, поскольку вам придется выходить в сеть чаще, чем с помощью App Shell, но это можно несколько смягчить с помощью правильных заголовков кэширования браузера HTTP. (О чем вы должны подумать в любом случае, для браузеров, в которых отсутствует поддержка сервис-воркеров.)

person Jeff Posnick    schedule 23.02.2016
comment
С точки зрения производительности, что быстрее и эффективнее для клиента? Прогрессивное веб-приложение с кешированной оболочкой приложения, использующее исключительно внешний интерфейс JavaScipt с рендерингом на стороне клиента или рендерингом на стороне сервера с «кешем и сетевой гонкой»? Кроме того, если бы вы использовали рендеринг на стороне сервера с «Кэшем и сетевой гонкой», вы могли бы получить много кэшированных страниц и много страниц вообще не кэшированных, какое решение здесь? - person Muhammad Rehan Saeed; 23.06.2017
comment
Это зависит. Но см. jeffy.info/ 24.01.2017/ - person Jeff Posnick; 23.06.2017