search

HTTPArchive / almanac.httparchive.org

HTTP Archive's annual "State of the Web" report made by the web community
https://almanac.httparchive.org
Apache License 2.0
613 stars 175 forks source link

Transform Almanac to a PWA #75

Open AymenLoukil opened 5 years ago

AymenLoukil commented 5 years ago

It would be nice that Almanac website shupports PWA capabilities for performance and offline support..Etc. I'll make a try on it.

AymenLoukil commented 5 years ago

PL #76

rviscomi commented 5 years ago

Nice idea! I see you've already drafted a PR but I'd like to discuss the features you have in mind before committing anything to the codebase.

Being a mostly static website, I can definitely imagine offline support being an important feature. How do we ensure that all of the contents are preloaded and not just pages/resources users have already loaded? And how do we ensure that preload is done performantly?

Add to homescreen would be useful as well. I'm not sure that we need to prompt users to do this, though, as mobile browsers have native UI for that, right?

AymenLoukil commented 5 years ago

Nice idea! I see you've already drafted a PR but I'd like to discuss the features you have in mind before committing anything to the codebase.

Ok :)

Being a mostly static website, I can definitely imagine offline support being an important feature. How do we ensure that all of the contents are preloaded and not just pages/resources users have already loaded? And how do we ensure that preload is done performantly?

The Service Worker will cache files and paths we precise. So no need to load the resources by the user for preloading/caching them. Another benefit of that, may be we will use a library for generating graphs (3d.js for example), we could also cache the JS files to improve to performance.

Add to homescreen would be useful as well. I'm not sure that we need to prompt users to do this, though, as mobile browsers have native UI for that, right?>

A2HS depends on the browser and is not always native. An UI element should be created / updated to show/hide the prompt. Some infos : https://developers.google.com/web/fundamentals/app-install-banners/

rviscomi commented 5 years ago

Sounds good. Have you looked into using Workbox to generate the SW code? I'm not sure how that might work when we don't have static HTML files but @jeffposnick would be able to answer that.

Can we defer on A2HS for now?

AymenLoukil commented 5 years ago

Yeah i tried Workbox but it was a struggle to make it works on localhost. I added CSP then tried self host but didn't work...exceptions, errors, violations 😢

I'm not sure how that might work when we don't have static HTML files but @jeffposnick would be able to answer that.

SW will fetch the given routes and resources and cache them so we should be able to render them when "offline". Would also love to hear from @jeffposnick :)

Ok for A2HS.

jeffposnick commented 5 years ago

In general, the ideal approach for adding in a service worker to a "content" site is to have the service worker mimic the templating/routing rules used during either the static generation or SSR (depending on whether the site is pre-generated or rendered on the fly).

There's more background in this "Beyond SPAs: alternative architectures for your PWA", and in particular, the "Worst Case Scenarios" section lists some gotchas/things to avoid.

While it's possible to just add in Workbox and get some level of offline support, like a custom offline page, that might not be worth the overhead.

I'm afraid that I'm not familiar with the architecture/CMS for the Almanac site. What is being used under the hood? The amount of work that it would take to have a clean Workbox integration varies a lot based on that 😄

rviscomi commented 5 years ago

We use SSR. Here's the routing logic and templates, for example.

The main contents of the Almanac are the chapter pages, which we don't have yet (for obvious reasons) but they would be routed/rendered something like this:

jeffposnick commented 5 years ago

Given that the routing logic is implemented in Python, it would be somewhat of a manual process to translate that into something that a JavaScript-based service worker could make use of. It doesn't seem like that would be too bad for the current set of rules, which are pretty straightforward, but I do worry about maintainability and things gtting out of sync when changes are made to the Python backend.

The templating end of things might be easier, though, as it looks similar enough to what Nunjucks supports. I've had decent luck doing that sort of templating inside of a service work for my personal blog (which uses 11ty as the static generation process, so there's no backend server to coordinate with).

rviscomi commented 3 years ago

Going through old open issues. @tunetheweb I wonder if the challenges mentioned in https://github.com/HTTPArchive/almanac.httparchive.org/issues/75#issuecomment-510183357 are less of an issue now that we're generating the sitemap, so we'd be able to enumerate all of the chapters at build-time. Is there still interest in adding PWA support? If not we can close this issue. cc @AymenLoukil

tunetheweb commented 3 years ago

My vote is to close this. There's a few use cases for Service Workers:

Offline support. To me that's best served by the ebook PDF. That's 22MB per year so prefetching that level of content is a bit rude, and only having the chapters without the content is a bit meaningless. Of course we could just cache previously browsed content for the offline version (I really wish browsers would do this by default!) but question the value of that compared to ebook, and also need to handle images and sheets embeds.

Having an installable home screen icon. However with Chrome insisting on offline support to surface this and above complexities with offline not sure it's worth it. And IMHO it's a bit wishful thinking to think there's much demand for having our content as an app, compared to the complexity.

Potential Performance gains by having better control over the cache. However we've a very performant site as it is so not sure there's much to gain her for the complexity.

Just as a demo of some of the stuff in PWA chapter.. While I like using the site as a show case of some of the things we talk about in the Web Almanac, I don't think that's enough reason to do this.

I also personally think Service Workers are overly complex, difficult to support and you should have a good reason to use them. And not sure we do to be honest - especially as, unlike most sites, we have ebook versions of our content.