Skip to content

Phase 7 — Performance

Pourquoi la performance

Un site qui charge en plus de 3 secondes perd 50 % de ses visiteurs avant même de s'afficher (étude Google 2024). La performance est une question d'expérience utilisateur, de SEO (Google pénalise les sites lents) et d'inclusion (tous les utilisateurs n'ont pas une fibre ni un dernier iPhone).

Objectifs de la phase

Cette phase couvre la section 7 de la checklist finale :

🔴 Critique🟠 Important🟢 Bonus
Temps de chargement < 3 secondesImages optimiséesScore Lighthouse Performance > 90
Score Lighthouse Performance > 70Lazy loading hors écranCSS/JS minifiés

Lighthouse — l'outil de référence

Lighthouse est intégré à Chrome DevTools. Il analyse votre page et produit un score de 0 à 100 sur 4 axes : Performance, Accessibilité, Bonnes pratiques, SEO.

Lancer un audit

  1. Ouvrir votre site dans Chrome (de préférence en navigation privée, pour éviter les extensions qui faussent le résultat)
  2. F12 (DevTools) → onglet Lighthouse
  3. Cocher au minimum Performance + Accessibilité
  4. Choisir le device : Mobile d'abord (Google se base sur le mobile pour le ranking)
  5. Cliquer Analyze page load

Toujours tester en mobile en premier

Google indexe les sites en mobile-first. Un site rapide sur desktop mais lent sur mobile sera mal classé. Le mode Mobile de Lighthouse simule une connexion 4G et un CPU 4× plus lent — c'est plus représentatif que votre Mac sur fibre.

Lire un rapport

Le rapport présente 4 zones :

ZoneCe qu'elle montre
Scores (haut)Les 4 notes globales sur 100
MetricsLes 5 Web Vitals (FCP, LCP, TBT, CLS, Speed Index)
OpportunitiesOptimisations qui feront gagner du temps (avec estimation en secondes)
DiagnosticsInformations utiles mais sans gain temporel direct

Les 3 actions correctives les plus rentables

D'après l'expérience, ces trois actions règlent 80 % des problèmes de performance :

  1. Optimiser les images — souvent 70 % du poids d'une page. Compresser, choisir le bon format (WebP/AVIF), définir des dimensions (width/height HTML), activer le lazy loading.
  2. Activer un cache — la deuxième visite doit être quasi instantanée. Sur WordPress = plugin de cache. Sur Vue/Vite = headers HTTP. Sur HTML statique = headers serveur.
  3. Minifier CSS et JS — supprime espaces, commentaires, retours à la ligne. Vite/Webpack le font automatiquement en build. Pour HTML statique, utiliser un outil comme minify-html.

Métriques Web Vitals à connaître

Google mesure 3 métriques principales appelées Core Web Vitals, complétées par 2 secondaires. Maîtriser ces métriques permet de cibler les bonnes optimisations.

MétriqueNom completCe qu'elle mesureCible
LCPLargest Contentful PaintTemps avant l'affichage de l'élément principal visible (grande image, gros titre, bloc de texte). Indique quand l'utilisateur perçoit que la page est « chargée ».< 2.5s
INPInteraction to Next PaintRéactivité de la page aux clics, taps et saisies clavier — délai entre l'action de l'utilisateur et la réponse visible à l'écran. Remplace FID depuis mars 2024.< 200ms
CLSCumulative Layout ShiftStabilité visuelle. Pénalise les éléments qui sautent pendant le chargement (image sans dimensions, bannière qui s'insère, police qui change la mise en page).< 0.1
FCPFirst Contentful PaintTemps avant l'apparition du tout premier contenu à l'écran (texte, image, SVG). Signal de « la page commence à se charger ».< 1.8s
TTITime to InteractiveTemps avant que la page réponde de façon fiable aux interactions (boutons cliquables, formulaires utilisables).< 3.8s

Outils complémentaires

Pour aller au-delà de Lighthouse, ces outils donnent des angles différents :

OutilTypeForce
PageSpeed InsightsEn ligne (Google)Lighthouse + données terrain (vraies visites des 28 derniers jours) — pagespeed.web.dev
GTmetrixEn ligneWaterfall détaillé : voir chaque requête, sa durée, sa taille — gtmetrix.com
WebPageTestEn ligneTests depuis différents pays et différents navigateurs — webpagetest.org

Pourquoi tester avec plusieurs outils ?

Lighthouse en local mesure une seule fois sur votre machine. PageSpeed Insights ajoute les données terrain (CrUX) — ce que vivent vos vrais utilisateurs. WebPageTest permet de tester depuis un autre pays (utile si votre site est hébergé en Suisse mais consulté depuis le Canada).

Optimisations clés

Images

Les images représentent souvent 60-80 % du poids d'une page. Trois axes d'action :

1. Compresser

OutilTypeUsage
AfinaEn ligne (DIVTEC)Glisser-déposer, AVIF/WebP/JPEG/PNG, traitement côté client (rien n'est envoyé sur un serveur) — afina-five.vercel.app
SquooshEn ligne (Google)Glisser-déposer, comparer formats en live — squoosh.app
TinyPNGEn ligneCompression PNG/JPG/WebP — tinypng.com
ImageOptimApp MacDrag & drop, batch — imageoptim.com

2. Choisir le bon format

FormatQuand l'utiliser
WebPPhotos et illustrations — 30 % plus léger que JPG, supporté partout
AVIFEncore plus léger que WebP (-50 %), mais support navigateur récent
SVGLogos, icônes, graphiques — scalable et minuscule
JPGPhotos sans transparence, en fallback de WebP
PNGUniquement si transparence + besoin de qualité lossless
html
<!-- Servir le meilleur format selon le navigateur -->
<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Description" width="800" height="600">
</picture>

3. Activer le lazy loading

Les images hors écran ne doivent pas bloquer le chargement initial. Ajouter loading="lazy" sur tous les <img> qui ne sont pas visibles immédiatement (les images en bas de page, les photos d'une grille).

html
<!-- Image hero (visible immédiatement) : pas de lazy -->
<img src="hero.webp" alt="..." width="1200" height="600">

<!-- Image plus bas dans la page : lazy -->
<img src="produit-1.webp" alt="..." width="400" height="300" loading="lazy">

Toujours définir width et height

Sans width et height, le navigateur ne sait pas la place que prendra l'image avant qu'elle ne charge — il déplace tout le contenu en dessous, ce qui crée du CLS (mauvais score Web Vitals).

Cache

Le cache permet à un visiteur de ne pas re-télécharger ce qu'il a déjà chargé. Effet sur la seconde visite : page quasi instantanée.

Sur WordPress (cours 741)

Installer un seul plugin de cache (jamais deux en même temps, ils se cassent l'un l'autre).

PluginCaractéristique
WP Super CacheGratuit, simple, recommandé pour débuter — wordpress.org/plugins/wp-super-cache
W3 Total CacheGratuit, riche en options (mais complexe)
WP RocketPayant (~50 $/an), excellent et tout-en-un

Configuration minimale WP Super Cache

  1. Installer et activer le plugin
  2. Settings → WP Super Cache → activer « Caching On »
  3. Choisir Simple (suffisant pour 95 % des sites)
  4. Cocher « Compress pages » (gzip)
  5. Tester : ouvrir le site en navigation privée, recharger 2× → la 2ᵉ doit être instantanée

Sur Vue / Vite (cours 141)

Vite génère automatiquement des noms de fichiers avec hash (app.a1b2c3.js), donc le navigateur peut cacher éternellement. Il suffit de configurer les headers HTTP sur le serveur :

apache
# .htaccess Apache — cache 1 an sur les assets hashés
<FilesMatch "\.(js|css|woff2|webp|avif)$">
  Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>

# HTML : pas de cache (pour servir la dernière version)
<FilesMatch "\.(html)$">
  Header set Cache-Control "no-cache"
</FilesMatch>

Sur HTML statique

Pour un site sans framework, configurer le .htaccess (Apache, courant chez Infomaniak) ou nginx.conf (selon votre hébergeur).

apache
# Cache 1 mois sur images, fonts et CSS/JS qui changent peu
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 month"
  ExpiresByType image/jpeg "access plus 1 month"
  ExpiresByType text/css "access plus 1 week"
  ExpiresByType application/javascript "access plus 1 week"
</IfModule>

Minification CSS et JS

La minification supprime les espaces, retours à la ligne et commentaires inutiles. Effet typique : -30 % à -50 % sur le poids des fichiers texte.

StackComment
Vue / ViteAutomatique avec npm run build
WordPressPlugin (ex: Autoptimize, ou option du plugin de cache)
HTML statiqueOutils CLI : minify-html, ou éditeur en ligne csscompressor.com

Workflow d'optimisation

ÉtapeActionOutil
1. MesurerScore Lighthouse initial (en mobile)Chrome DevTools
2. CiblerIdentifier les 3 plus gros gains dans OpportunitiesRapport Lighthouse
3. Optimiser imagesCompression + WebP + lazy loadingSquoosh, loading="lazy"
4. Activer cachePlugin (WP) ou headers HTTP (Vite/statique)WP Super Cache, .htaccess
5. MinifierCSS et JS minifiés en productionnpm run build, plugin WP
6. Re-mesurerComparer le nouveau scoreLighthouse

Checklist de la Phase 7

  • Score Lighthouse Performance mesuré sur mobile (en navigation privée)
  • Temps de chargement < 3 secondes sur 4G simulée
  • Score Lighthouse Performance > 70 (objectif minimum)
  • Images compressées et au bon format (WebP de préférence)
  • Attributs width et height définis sur toutes les images
  • loading="lazy" ajouté aux images hors écran
  • CSS et JS minifiés en production
  • Cache activé (plugin WP ou headers HTTP)
  • Bonus : score Lighthouse Performance > 90

Prochaine étape

La page est rapide. Passez à la Phase 8 — Responsive design pour vérifier qu'elle s'adapte à toutes les tailles d'écran.

Documentation pour les cours de développement web