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 Le templating est une technique de développement web permettant de générer dynamiquement des pages HTML en utilisant des modèles préconçus qui sont remplis avec des données lors de l'exécution. , ici, dans l’exemple en PHP. C’est-à-dire qu’il va construire la page HTML Le HTML (HyperText Markup Language) est le langage standard utilisé pour structurer et afficher le contenu sur le web. Il définit des éléments comme les titres, paragraphes, liens, images, et autres composants d'une page web. 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 Le DOM (Document Object Model) est une représentation en structure d'arbre d'un document HTML ou XML, permettant aux développeurs d'accéder et de manipuler dynamiquement les éléments d'une page web via des langages de programmation comme JavaScript. et effectuer le rendu et le paint de la page à l’aide des fichiers CSS Le CSS (Cascading Style Sheets) est un langage utilisé pour décrire l'apparence et la mise en page des documents HTML, en définissant des styles comme les couleurs, polices, marges, et positionnements des éléments sur une page web. 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 Le First Input Delay (FID) est une métrique qui mesure le temps écoulé entre la première interaction de l'utilisateur avec une page web (clic, touche) et la réponse du navigateur, reflétant la réactivité du site. ), si un JS bloque les interactions, en occupant trop le processeur. La somme de ces temps de blocage est nommé le Total Blocking Time Le Total Blocking Time (TBT) est une métrique de performance web qui mesure le temps pendant lequel une page web reste bloquée et ne répond pas aux interactions utilisateur, de l'apparition du premier contenu jusqu'à l'interactivité complète. .
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 Le modèle MVC (Modèle-Vue-Contrôleur) est un schéma d'architecture logicielle qui sépare une application en trois composants : le modèle (données), la vue (interface utilisateur) et le contrôleur (logique de traitement), facilitant la maintenance et le dé ) 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 Le TTFB (Time to First Byte) est une métrique qui mesure le temps écoulé entre l'envoi d'une requête par un navigateur et la réception du premier octet de réponse du serveur, reflétant la réactivité du serveur. .

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 Le HTTP (HyperText Transfer Protocol) est un protocole utilisé pour transférer des données sur le web, permettant la communication entre un navigateur et un serveur pour afficher des pages web. . 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 Le référencement naturel, ou SEO (Search Engine Optimization), est l'ensemble des techniques visant à améliorer la visibilité d'un site web dans les résultats de recherche des moteurs comme Google, sans utiliser de publicité payante. , 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 Le back-end est la partie d'un site web ou d'une application qui fonctionne côté serveur. Il gère la logique, les bases de données, et le traitement des données, invisible pour l'utilisateur final. va chercher les données correspondantes à la requête url Une URL (Uniform Resource Locator) est l'adresse unique d'une ressource sur Internet, comme une page web, une image ou un fichier, permettant de la localiser et d'y accéder via un navigateur. 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 L'hydratation, en développement web, est le processus par lequel un site généré côté serveur devient interactif côté client en liant les éléments HTML statiques à du JavaScript pour activer des fonctionnalités dynamiques. 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.

1. Comme dans le modèle 2, les serveurs sont sollicités en amont de la requête. Ils génèrent la page avant que l’internaute la demande.
2. Le résultat est stocké de manière statique dans un serveur de cache.
3. La page est ensuite envoyé à l’internaute quand il la demande sans prendre de temps de traitement côté serveur.
4. Reste la réhydratation de la page pour être pleinement dynamique. Là encore, l’utilisateur doit attendre que cette réhydratation soit terminée.
5. La page est mise à jour avec les données…

Avec un cache côté serveur, on va encore gagner un peu de temps au premier chargement, de la même manière qu’entre le modèle 1 de conception de site web et le modèle 2.

On pourrait même imaginer mettre en cache toutes les requêtes avec un Varnish par exemple.

Par contre, en terme de complexité nous avons donc plusieurs niveaux de couche à bien configurer pour que tout cela soit bien stable.

Timings

Avec le cache, le premier chargement a un TTFB rapide mais le souci reste la réhydratation avec les mêmes solutions citées pour le modèle 4.