Conception de site web :
les différentes approches

1. Dans ce modèle de conception de site web, c’est le serveur qui va faire le templating, ici, dans l’exemple en PHP. C’est-à-dire qu’il va construire la page HTML avec les données de la base de données. La construction puis la transmission se font à la demande.
2. Le temps de transport dépend du protocole et de la qualité de la connexion.
3. Au fur et à mesure que les données arrivent, le navigateur va charger le DOM et effectuer le rendu et le paint de la page à l’aide des fichiers CSS et éventuellement JS liés pour pouvoir l’afficher.
4. Quand l’utilisateur clique sur un lien, il peut y avoir un délai qu’on appelle FID (First Input Delay), si un JS bloque les interactions, en occupant trop le processeur. La somme de ces temps de blocage est nommé le Total Blocking Time.
5. La logique reste la même pour les pages que l’utilisateur visitera.

N’en déplaise aux développeurs, cela reste le modèle de conception de site web le plus utilisé. La plupart des CMS, dont WordPress, sont basés sur celui-ci. Sa caractéristique est surtout d’avoir les requêtes aux données (en SQL par exemple) inclus dans le templating (le code HTML).

D’un point de vue code, c’est pas terrible. D’un point de vue organisation non plus. Généralement, ceux qui font le templating ne sont pas les mêmes que ceux qui font les requêtes aux datas. A l’inverse pour des projets simples, tout est regroupé au même endroit ce qui est souvent plus compréhensible.

Toutefois, il y a aujourd’hui des modèles de conception (dites MVC) qui prennent soin, sur le serveur, de séparer accès aux données et templating, comme avec Symfony. C’est généralement plus contraignant mais plus évolutif aussi.

Timings

Peu importe comment est construit la page sur le serveur, là, c’est son poids et sa complexité qui vont déterminer les temps de chargement et d’affichage. Pour l’exemple, je me suis basé sur les temps relevés avec un profil mobile/3G avec ce modèle de conception de site web qui est en fait celui du site artwai.com lui-même. On est sur un site plutôt bien optimisé mais son grand défaut reste le TTFB.

A noter, que les ressources dites statiques sont stockées dans le cache du navigateur et ne sont donc pas rechargées à chaque page. Et si on pouvait faire pareil mais côté serveur…

1. Avec un système de cache coté serveur, les pages ne sont pas créées au moment où l’internaute les demande mais avant.
   Généralement, la page est générée :
   • quand elle est modifiée par le CMS,
   • et/ou selon une routine exécutée régulièrement,
   • et/ou à la première demande.

Le reste des étapes 2 à 5 sont similaires au premier schéma.

Cette solution peut être mise en place sur deux niveaux :

1. Sur le serveur même où est exécuté le site, pour générer les pages de manière statique. Il n’y aura pas d’exécution de génération de la page. Exemple : WP Rocket ou WP Total cache pour WordPress
2. Ou sur un serveur reverse proxy qui stocke des pages statiques pour chaque nouvelle requête. Les pages seront délivrées dès qu’une requête sera faite, sans appel au serveur d’origine et vos pages chargeront plus vite. Exemple : Varnish ou AWS.

Cette solution ne change rien à la conception du code. On garde les mêmes avantages et inconvénients d’un code où les requêtes et le templating peuvent être mélangés.

Le gros inconvénient : les pages sont statiques, elles ne peuvent pas être dynamiques selon le contexte utilisateur. Vous ne pouvez pas gérer un panier de commande par exemple.

Pour faire simple, avec un site bien conçu, dont l’exécution du code côté serveur est bien optimisé, on peut se permettre de faire cohabiter les 2 solutions en excluant les pages qui doivent être dynamiques du processus de mise en cache côté serveur.

Timings

Avec cette solution on corrige le principal point faible d’une conception classique, à savoir le TTFB. Par exemple, sur nos schémas, on constate que celui-ci passe de 700 à 500 ms ! Pour info, le site artwai.com repose sur cette solution.

1. Avec un Framework JS, la première requête n’exécute que très peu de code pour répondre à l’internaute.
2. Mais uniquement pour envoyer une structure de page vide, c’est le moteur JavaScript qui va s’occuper de faire les routes et le rendu des pages.
3. Une seconde requête est faite en JavaScript au serveur pour récupérer les données à afficher. La page est finalement affichée.
4. Quand l’utilisateur clique sur un autre lien, le site n’effectue pas de rechargement de page. On garde la structure de page mais on fait une nouvelle requête en JavaScript pour aller chercher les données dont l’affichage est géré par le moteur JS.
5. La logique reste la même pour toutes les pages visitées en conservant toujours la structure issue de l’étape 2.

Avec cette conception de site web utilisant Vue.js, React, Angular ou autres, on est entièrement dépendant de l’appareil de l’utilisateur. C’est lui qui manipule le DOM pour modifier l’affichage. Avec l’inconvénient, que si l’appareil dispose de peu de ressources, d’être plus lent que prévu.

A l’inverse, l’avantage est que les requêtes au serveur sont plus courtes car on ne charge que de la donnée. Dès lors, chaque nouvelle page est censée s’afficher plus rapidement que la première. De plus, le code est mieux structuré en séparant les données et le templating, généralement en fonctionnant par composant.

D’un point de vue SEO, cela pose un autre problème. Si l’exécution du JS pour rendre la première page prend plus de 500ms, le moteur de recherche risque de référencer un contenu vide… pas glop !

Timings

Alors oui, après le premier chargement, les autres pages sont plus rapides à charger. Mais c’est là que le bas blesse. En effet, c’est présupposer que l’internaute va patiemment attendre ce premier chargement. Car le chargement en 2 étapes est plus long et le FID peut aussi en souffrir, le temps que le JS est bien mis en place toute la page… Sur notre schéma, on perd 400ms de ce point de vue entre le modèle 2 et le modèle 3.

Google l’a bien compris et recommande sérieusement d’améliorer le premier affichage pour conserver votre audience et même votre positionnement.

1. Le serveur back-end va chercher les données correspondantes à la requête url et les envois au serveur JavaScript, généralement Node.js.
2. Ce dernier agglomère les données et le templating pour créer la page avec le même code JS que dans le modèle précédent.
3. La page est donc envoyée en une seule fois au navigateur. Puis le navigateur interprète tout le JavaScript pour « réhydrater » les différents composants de la page.
4. L’utilisateur doit attendre que cette réhydratation soit terminée avant que son interaction puisse répondre rapidement, notamment un clic vers une nouvelle page
5. La page est mise à jour avec les données, la réhydratation n’est (normalement) plus à faire.

Le server side rendering vient corriger le problème d’un chargement en 2 fois (donc plus lent), et surtout les problèmes de SEO.

Toutefois, côté serveur, nous déportons la création de la page dans le modèle 1, du navigateur vers le serveur. Sorte de retour au source à la conception classique sauf qu’ici le code est le même. Il s’agit du JavaScript. Du coup, le gain en termes de temps de chargement par rapport à une conception classique reste limité.

De plus, l’hydratation ou la réhydratation doit convertir, via JavaScript, une page Web statique en une page Web dynamique, en attachant des gestionnaires d’événements aux éléments HTML. Et cela peut prendre du temps, compliquant par la même le FID, car l’utilisateur ne peut interagir de suite avec la page… Pour éviter cette attente, on voit se multiplier les écrans de chargement ou les skeletons. En le faisant patienter, ils empêchent ainsi l’internaute de cliquer trop tôt.

Ce modèle conserve toutefois l’avantage que les chargements suivants sont censés être plus rapides.

Timings

Le premier chargement redevient acceptable avec TTFB plus rapide que précédemment. Le souci vient donc essentiellement de la chaîne JavaScript qui ralentit le FID.

L’une des solutions est d’effectuer une hydratation partielle et/ou progressive pour limiter le TBT.