Présentation Jérémy DESVAUX DE MARIGNY Consultant - Direction Technique - Développement WordPress - Obtention du label Numérique Responsable pour l’Agence Wonderful @jdmweb
1 - L’aspect environnemental “ Alors que l’humanité doit diviser son empreinte écologique par 4 pour atteindre les objectifs d’un développement durable, l’univers numérique continue son expansion, avec des impacts environnementaux toujours plus importants. “ En 2020, le numérique représente 7% de nos émissions de gaz à effet de serre, soit plus que l’aviation civile. Greenit.fr
Chronologie d’une requête 1. Un utilisateur va se servir d'un terminal : ordinateur, tablette, téléphone etc. 2. Ces terminaux sont équipés d’un navigateur internet, comme chrome, firefox, safari, edge, brave etc, aussi appelés clients. 3. Pour afficher le service numérique, le navigateur va faire une requête à un serveur web. 4. La requête va transiter sur le réseau internet pour atteindre le serveur. 5. Ce dernier va calculer la page à retourner, puis préparer une réponse qui va être envoyée en sens inverse au client.
Chronologie d’une réponse 1. La réponse part du serveur, et re-transite en sens inverse à travers le matériel réseau qui constitue internet. 2. Le client récupère la réponse, l’analyse puis demande au serveur les différentes ressources nécessaires au bon affichage de la page : les images, les feuilles de style, les fichiers javascript, et les polices notamment. 3. Le navigateur interprète et exécute les différentes ressources. Il affiche les images, il applique les styles demandés, et exécute le code JavaScript interprété. Il calcule tout pour construire la page. 4. La page est complètement affichée dans le navigateur.
Affichage de la page supdeweb.com/montpellier Client Réseau internet Serveur Web Calcul du rendu 65 requêtes = 65 fois ce schéma 8Mo de ressources échangées à travers les équipements
Impacts sur le serveur Complexité de calcul Répétition de calcul Travail pour rien Duplication sans valeur ajoutée CPU Mémoire Ventilateur Consommation électrique Scalabilité & obsolescence Saturation
Réduction des impacts sur le serveur Complexité de calcul Répétition de calcul Éviter (Cache) Réduire les calculs Optimiser le code Sobriété fonctionnelle Sobriété visuelle Scalabilité & obsolescence Bien dimensionner Surveiller Éviter la saturation Prolonger la durée de vie Objectifs: Éviter de changer le serveur / Réduire sa consommation
Réduction des impacts sur le réseau Bande passante Fréquence de transfert Cache pour éviter les téléchargements redondants Réduire le Poids des réponses / des pages. Compression Concaténation Réduire le nb de ressources à télécharger Scalabilité & obsolescence Bien dimensionner Surveiller Éviter la saturation Prolonger la durée de vie Objectifs: Éviter de changer les équipements / Réduire leur consommation
Réduction des impacts sur les terminaux Ressources Obsolescence Éviter la saturation Prolonger la durée de vie Optimiser pour l’exécution client Réduire les calculs Simplifier Saturation Objectifs: Réduire leur consommation / Éviter un changement de terminal
4 savoirs faire indispensables 1. Connaître les opportunités de sobriété numérique 2. Connaître les bonnes pratiques 3. Savoir utiliser les outils de mesures 4. Savoir tenir un cap
3.1 Connaître les opportunités de sobriété numérique Spécifications Limiter les fonctionnalités non essentielles Conception Design sobre Approche mobile first ou +>DC Production Optimiser le code, le cache Choisir un cap, le mesurer, le maintenir Hébergement Serveurs bien dimensionnés, bien utilisés. Hébergeur engagé. Limiter les DEEE
3.3 Savoir utiliser les outils de mesures - Inspecteur web - Nombre de requêtes - Poids - Temps d’exécution - Outil d’analyse spécialisé - ecoindex.fr - Green It extension - Lighthouse - Page speed insights
3.4 Savoir tenir un cap - On choisit un but, communément appelé budget, essayer de viser une métrique choisie (ou plusieurs) et s’y tenir (poids, nombre de requêtes, vitesse de chargement, eco index …) - Mesurer avant application des améliorations - Faire les modifications - Mesurer de nouveau - Tenir la métrique souhaitée dans le temps
Le client fait une demande de fonctionnalité - On questionne la demande - Si non pertinent on arbitre. Go? No Go? Alternative plus légère? - On fait passer en web design - On anticipe les impacts, on critique - On implémente - En faisant attention au budget associé. - On mesure - On optimise si ça ne passe pas. - On revient dessus si ça ne passe toujours pas.
On applique la méthode 2. On évalue le scope fonctionnel - Peut-on réduire le scope fonctionnel? - Le service est-il bien concentré sur sa valeur ajoutée initiale? Pas d’obésité fonctionnelle?
On applique la méthode 3. On évalue le design - Le design est-il adapté? Pas trop lourd? - Si trop lourd, revoir les maquettes. - Faire attention aux implications des décisions de design - Mettre en perspective d’un objectif à ne pas dépasser
On applique la méthode 4. On évalue le code qu’on peut (le code client - frontend) ● Est-ce que le serveur communique des directives de cache au client ? Si non, configurer le cache client. ● Le poids du service est-il raisonnable ou trop important ? Si trop lourd : - optimiser les assets du mieux possible (images, CSS, JS, polices, vidéos notamment) - Réduire le périmètre fonctionnel si possible ● Le nombre de requêtes nécessaires à l’utilisation du service est-il raisonnable ? Si non, optimiser les requêtes avec différents principes (concaténation, sprites, lazy load) ● La gestion des images est-elle optimisée ? ● Si non, reprendre le process image ● Utiliser des formats modernes ● Mettre en place des outils de compression
Pour les terminaux - Le code envoyé au terminal est-il optimisé pour fonctionner sur la plupart des terminaux en termes de poids et de complexité de calcul ? - Si non, optimiser le poids (refactoring, concatenation, minification, simplification, polyfills) - Dans quelle mesure le service numérique s’adapte-t-il aux conditions dans lesquelles il est utilisé par le terminal ? (taille d’écran, densité de pixels, offline, batterie, capacités du navigateur) - Si pas satisfaisant, mieux exploiter les forces et les faiblesses du panel de terminaux supportés. - La technologie est-elle adaptée - Attention aux technologies qui exercent une grosse pression sur le front (webgl, framework full front)...
On applique la méthode 5. Si on peut on analyse le code backend ● Le code est-il saint? Est-il optimisé Si non, refactorer le code pour être moins consommateur. ● Le code est-il bien mis en cache? - Si non, mettre en place une politique de cache
Appliquer la méthode à un site existant 1. Choisir un site 2. L’analyser en suivant la méthode 3. Rédiger une recommandation 4. Présenter cette recommandation à l’oral
jdmweb
ashitanoterakoya
hide2kano
signer
okuramasafumi
asial_edu
tomap
kfujita
codeforeveryone
onurcanalp
yasubei
paulrobertlloyd
garrettdimon
shpigford
sstephenson
keithpitt
jasonvnalue
bryan
phodgson
trishagee
eileencodes
denniskardys
marcelosomers