|
|
|
@ -0,0 +1,163 @@
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
gitea: none
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
include_toc: true
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[TOC]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Architecture client/serveur
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Un site Web est généralement constitué d'au moins 2 parties :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- *le côté client* : qui est l'ensemble des fichiers (HTML/CSS/JS/WASM) interprétés par le navigateur et exécuté sur le poste de travail de l'utilisateur.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- *le côté serveur* : qui va s'exécuter sur le serveur et qui répondra aux requêtes du navigateur. C'est lui qui va, entre autres, donner au navigateur les fichiers HTML/CSS/JS/WASM nécessaires à l'affichage du site.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
La communication entre le client et le serveur se fait généralement via le protocole HTTP(S). Le client envoie une requête HTTP au serveur qui retourne une réponse HTTP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<img src="file:///home/demigda/Data/Recherche/Git/Notes-de-Cours/Web/X%20-%20Communications%20Client-Serveur/HTTP%20queries.png" title="" alt="" data-align="center">
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
L'affichage d'une page Web se déroule usuellement de la sorte :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
```html
|
|
|
|
|
|
|
|
<!DOCTYPE>
|
|
|
|
|
|
|
|
<html>
|
|
|
|
|
|
|
|
<head>
|
|
|
|
|
|
|
|
<script src='...' defer></script>
|
|
|
|
|
|
|
|
<link rel='stylesheet' href='...'></link>
|
|
|
|
|
|
|
|
</head>
|
|
|
|
|
|
|
|
<body>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</body>
|
|
|
|
|
|
|
|
</html>
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. Le navigateur demande au serveur le fichier HTML correspondant à la page Web à afficher.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2. Le navigateur commence à lire et à interpréter le fichier HTML reçu.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3. Le navigateur lit la balise `<script>` et commence à télécharger le fichier correspondant. Comme la balise a l'attribut `defer`, le navigateur continue de lire et interpréter le fichier HTML.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4. Le navigateur lit la balise `<link>` et commence à télécharger le fichier CSS correspondant.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
5. Le navigateur commence à construire l'arbre DOM à partir du contenu de `<body>`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
6. Une fois l'arbre DOM construit, il execute le script qui était `defer`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
7. Une fois l'exécution du script fini, le navigateur dessine la page Web pour la première fois.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Optimisations
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
L'un des objectifs des développeur Web est de dessiner la page Web le plus tôt possible. Pour cela, il va user de diverses techniques :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- *Compresser les fichiers* avant de les transmettre, réduisant le temps de téléchargement des ressources nécessaires.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- *Réduire la taille des fichiers* en
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- supprimant le code inutilisé
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- le minimifiant (supprime les espaces et retours à la ligne)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- en l'uglifiant (réduit la taille du code au prix de sa lisibilité, e.g. en renommant les variables).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- pour les images, en réduisant sa résolution/qualité, ou en utilisant des formats vectoriels (SVG).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- pour les images, afficher un *placeholder* ou version en basse résolution puis progressivement [la remplacer une version de plus haute résolution](https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Tutorials/js13kGames/Loading#images).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- *Télécharger ou exécuter plus tard* les ressources non-nécessaires à l'affichage, via :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- du *lazy load*, e.g. ne télécharger les images que lorsqu'elles apparaissent à l'écran.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- de la *pagination*, e.g. sur un tableau ne télécharger/afficher que les X premières entrées et proposer des boutons pour afficher les entrées suivantes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- en reportant l'execution de certains bouts de codes à plus tard.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- *Réduire le nombre de fichiers téléchargés* (on vise généralement 3-4 fichiers par page) :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- remplacer l'URL d'une image par [une chaîne de charactère en base64](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- fusionner les fichiers CSS en un seul.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- fusionner les fichiers JS en un seul.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- intégrer certaines ressources (e.g. JSON) dans le fichier JS.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- intégrer le JS et/ou le CSS dans le fichier HTML.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- *Utiliser des caches* pour éviter de re-télécharger à chaque fois certaines ressources :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- un cache basé le protocole HTTP (cf [Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching)).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- un cache local basé sur `localStorage`, `sessionStorage`, ou `indexDB`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- un cache côté serveur en enregistrant des données dans la RAM afin de pouvoir répondre plus rapidement aux requêtes qui s'il fallait aller les lire directement sur le disque.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- *Pré-télécharger les ressources*, en commençant à les télécharger le plus tôt possible :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- dans les balises `<script>`, l'attribut `defer`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- pour d'autres ressources utilisées plus tard, cf [<link rel=preload href='...' as='...'/>](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/preload).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Pour les site Web massivement visités :
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- *distribuer la charge* (load balancing) entre plusieurs serveurs (⚠ engendre des problématiques de synchronisations).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- *rapprocher le serveur du client*, *edge computing* (contenu dynamique), *content delivery network* (contenu statique).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- découper son site Web en plusieurs modules/services indépendants hébergés sur plusieurs serveurs (⚠ si les services doivent fréquemment communiquer entre eux cela peut s'avérer contre-productif).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
⚠ L'optimisation prématurée est diabolique. Vous n'avez, à votre niveau, pas besoin d'optimiser vos sites Web. Vous n'avez pas non plus à implémenter vous-mêmes ces optimisations, de nombreux outils le font déjà pour vous (e.g. Webpack).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
🚩 [TODO] : outils navigateur pour network / load performances (lighthouse)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
🚩 [TODO] : archi projet dev vs prod.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Le serveur Web
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nginx/Apache2/Live Server vs Deno => pourquoi séparer (statique vs dynamique ! CORS !) ?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Command line
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
BDD API/FileAPI
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
! Jamais faire confiance client
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Serveur REST
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
=> Principe
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
=> Utilité
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
=> Différent type de requêtes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
=> Routes
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
=> Serveur Python/JS/TS
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Websocket
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Server event
|
