Segmented Rendering is just a smarter way to do static rendering. Once you understand that it’s all about caching renders and then getting the right cached render for each request, everything will click into place.

To implement segmented rendering:

1. Define your “segments” for a page.
   Example: paid users versus free users, users from company A versus users from company B or C, etc.
2. Render as many static variations of a page you need, with one URL per segment.
   Example: /with-jokes/my-article, /bland/my-article. Each variation matches a segment, for instance, paid or free users.
3. Setup a very small redirection server, that checks the HTTP request content and redirects the user to the right variation, depending on their segment. Example: paid users are redirected to /with-jokes/my-article. We can tell if a user is paid or not by checking their request cookies.

More performance?
Render the site on demand with Incremental Static Regeneration

bulk optimize JPEG, PNG, WebP, or SVG images with no discernible quality loss.

The way it works is quite simple, you just have to copy and paste the content of your Dockerfile into the interface and the site gives you a list of recommendations to follow to improve your file.

I’m saying: consider the options, weigh them up against the norm and test them out. As long as you have a good reason behind the implementation, it kind of doesn’t matter what others think.

Partytown is a lazy-loaded library to help relocate resource intensive scripts into a web worker, and off of the main thread. Its goal is to help speed up sites by dedicating the main thread to your code, and offloading third-party scripts to a web worker.

An introduction and how it works:
https://www.smashingmagazine.com/2022/04/partytown-eliminates-website-bloat-third-party-apps/

The websites that are < 1MB.

The internet has become a bloated mess. Massive JavaScript libraries. Countless client-side queries. Overly complex frontend frameworks.

These things are a cancerous growth on the web.

But we can make a difference - no matter how small it may seem. 1MB Club is a growing collection of performance-focused web pages found across the internet.

Some examples of why C is faster than Java, because C and algorithms

Je veux être fier de mon travail. Je veux fournir des choses qui fonctionnent, qui sont stables. Pour faire ça, il faut que l’on comprenne ce que nous faisons, à l’entrée et à la sortie, et ça ne peut pas se faire dans un système fourre-tout avec autant de surcouches.

👍‍ pour tout ce qui est énoncé dans ce billet de blog

A case study

Optimisations:

• Make use of SQLite PRAGMA statements when possible
• Use prepared statements
• Do a batched insertions
• PyPy is actually 4x faster than CPython
• Threads / async may not be faster always

In CPython: 510s
In PyPy: 150s
In Rust: 33s

Le truc qui prend du temps:

10 Mo, c’est pas grand chose me direz-vous, mais c’est là qu’une particularité de la fonction sscanf vient broyer le tout : pour chaque octet de donnée ajouté lors de la lecture, la fonction compte chaque caractère de la chaîne de caractères de 10 Mo via un strlen.

À la place, stocker le résultat du strlen au départ avant d'itérer résout le problème.

Du point de vue de la consommation énergétique lors de l'utilisation, les data centers ont fait d'énorme progrès !

On oubli cependant le coût de fabrication et de recyclage (quand il a lieu).

C'est complexe.

Supprimer les fichiers de langues …/plugins/…/lang/…

42ko d'économisé, sois 50Tb de bande passante !

TL;DR

You should probably avoid benchmarking branchy code over small problems.