Should we change to a static site?

[tunetheweb]

@HTTPArchive/developers , another question for you.

This question has come up (again) with some chats with you and so I'm opening this issue for discussion.

Note: this has been discussed before in #634 and we closed this issue. I've decided to open a new issue, rather than reopen that last one, as that last one got a little sidetracked on other GitHub issues.

The Web Almanac is basically a static site, but has a full Flask-based Python engine using Jinja2 templates to display these pages. Some have suggested we should move to a purely static site, or alternative static site generators (e.g. 11yy or some other Jamstack), which would potentially simplify our site, potentially lead to a performance boost and also potentially lead to other hosting opportunities (e.g. hosting directly on GitHub).

From my point of view, I can see the arguments for and against, which I've tried to summarise below:

On the one hand, I would say it has the following areas for potential improvement:

• There is indeed a (slight) performance issue for the first run of the site as the Python server is launched. This is noticeable when you run Lighthouse for a little used page, and then rerun Lighthouse and get a better score. We still score over around 90 for most of our pages, which is still a very good score and it's questionable whether users would notice the performance improvement. For a "hot" server, the performance impact seems really difficult (impossible?) to notice, and either way the results are cached for 3 hours on the Google Cloud Platform CDN at which point it is a static site.
• The server is built on different technologies (Python, Flask, Jinja2), than the front end (HTML, CSS and JavaScript) and the build scripts (JavaScript and Bash shell scripts). It may be better to consolidate our tech stack on JavaScript to allow a greater movement between front end and back end developers.
• We don't yet have CI/CD to allow pushing to production just by merging a change (though @rviscomi have talked about this recently and we believe this is possible to do given our improved automation and testing completed this year).

On the other hand, what we have is working well, we've had no major issues or items that we can't support on the site and functionality has been relatively easy to add (personally I had no experience of Python, Flask or Jinja2 before working on this project but have contributed a huge number of changes to that code). The refactor of Python in #949 and #1176 has helped improved the Python code no end, and the templating system we have (although seemingly quite convoluted at first) does allow us great support of other languages.

Also, as I say the site is VERY performant and rarely scores below 90 on Lighthouse and much higher on simple pages like the home page (95-98 Lighthouse performance score). Given the size and complexity of some of the data in the chapters that is quite a feat! Of course I'd love to get 100, and we could get a higher score by inlining our CSS, reducing the number of fonts, or removing interactive visualisations, but not sure those are compromises we're willing to take. So, for now, I'm happy with the performance so I for one don't believe we have a performance issue to solve per se, or that a move in backend platform would have a material impact on this - see #638 for more discussion on this and things have improved further since then.

It should also be noted that the site is not static. In particular we have:

• Dynamic redirects, based on language support. Visiting https://almanac.httparchive.org automatically redirects to the best language we can find for you and similarly attempting to visit an un-translated chapter redirects you back to (what we believe) is the best place for you.
• Language specific error pages (404, 500..etc.). Although we hope most people don't see our error pages, having language-specific ones really makes our international readers feel like first class citizens IMHO.
• Random pages (contributors and home page). This could be replaced with client side JavaScript (and indeed we've already done this for contributors in Randomize contributors on reload #1107 for reloads) but there is a performance impact to this.
• CSP nonces for inline JavaScript. While we have no real security concerns and would make do without such a strict Content Security Policy, I for one am pleased we follow best practices.
• Security and privacy HTTP headers. As well as the CSP already discussed, we set various other header giving us A+ score on SecurityHeaders.com and the Mozilla TLS Observatory.

Maybe none of these "dynamic" items are deal breakers, and we could potentially live without some (or maybe even all) of them. Other platforms may allows similar level of detail, or we could work around them with front end code. However, we've tried to make the Web Almanac the best possible site we can, and to serve as example of how sites should be built. So personally I'd be against moving to something very simple like GitHub pages since we couldn't keep the level control of some of the server-side items to allow all of the above to still be supported. Though if there are considerable benefits to moving, and more than enough to offset these negatives, then let's hear them.

So there's a lot to like about our tech stack and I'm loath to move, just for the sake of moving (though personally I'd love to learn more about 11ty since it seems to be the hot new thing at the mo!).

And with that I'll open it up to the floor for discussion!

One final ask would be that you qualify any suggestions with what benefits it would bring to the project over our current tech stack (e.g. "I think we should move to X." is not that helpful, whereas "I think we should move to Y, because it would be easier to do..." is).

[tunetheweb]

The other option of course, is to have a "full" python server to generate the static pages at deploy time, and then a light version of the server (also in python?) to serve these "static pages" and add the dynamic content (redirects, headers, nonces, randomised pages...etc) as need be.

That could be more performant for most pages - thought that is added complexity (two servers) and not sure our full python server is that heavy anyway. I'd imagine (without any testing whatsoever to back this up!) that spinning up a light python server would probably take just as long as the full one.

[tunetheweb]

Closing this as what we have is working for now and no feedback on desire to change it at this time.