Questions d'entretien Performance Web
1. Quels sont les Core Web Vitals et pourquoi sont-ils importants ?
Les Core Web Vitals sont les métriques de Google qui mesurent l'expérience utilisateur : LCP (Largest Contentful Paint, < 2.5s) : temps d'affichage du plus grand élément visible. INP (Interaction to Next Paint, < 200ms) : réactivité aux interactions utilisateur. CLS (Cumulative Layout Shift, < 0.1) : stabilité visuelle de la page. Ces métriques impactent le SEO (facteur de classement Google) et la conversion (chaque seconde de chargement réduit les conversions de 7%).
2. Comment optimiser le LCP (Largest Contentful Paint) ?
Le LCP mesure le temps d'affichage du plus grand élément visible (souvent une image hero ou un titre). Optimisations : preload les ressources critiques (images hero, fonts), optimiser les images (WebP/AVIF, srcset pour le responsive, lazy loading sauf pour le LCP), réduire le TTFB (temps de réponse serveur), eliminer le CSS/JS bloquant le rendu, utiliser un CDN pour rapprocher le contenu des utilisateurs, et inline le CSS critique dans le HTML.
3. Comment réduire le CLS (Cumulative Layout Shift) ?
Le CLS mesure les decalages visuels inattendus. Causes courantes : images/vidéos sans dimensions (width/height ou aspect-ratio CSS), publicites/iframes dynamiques, web fonts qui provoquent un FOIT/FOUT, contenu injecte dynamiquement au-dessus du viewport. Solutions : toujours définir les dimensions des médias, utiliser font-display: swap avec preload, reserver l'espace pour les contenus dynamiques, et éviter d'insérer du contenu au-dessus du fold après le chargement.
4. Expliquez le critical rendering path et comment l'optimiser.
Le critical rendering path est la séquence d'étapes du navigateur pour afficher le premier pixel : réception HTML -> construction du DOM -> réception CSS -> construction du CSSOM -> construction du Render Tree -> Layout -> Paint. Optimisations : minifier HTML/CSS/JS, inline le CSS critique (above-the-fold), defer/async les scripts non critiques, preconnect aux domaines tiers, réduire la profondeur des chaînes de dépendances, et preload les ressources critiques.
5. Comment fonctionne le lazy loading et quand l'utiliser ?
Le lazy loading differe le chargement des ressources non visibles dans le viewport initial. Pour les images : l'attribut loading="lazy" (natif, sans JS) charge les images quand elles approchent du viewport. Pour les composants : import() dynamique en JS (code splitting). Pour les iframes : loading="lazy". Ne lazy-loadez jamais le contenu above-the-fold (LCP) — uniquement les ressources below-the-fold. Le lazy loading réduit le poids initial de la page et accélère le premier rendu.
6. Qu'est-ce que le code splitting et le tree shaking ?
Le code splitting divise le bundle JavaScript en morceaux (chunks) charges à la demande. Implementez-le avec import() dynamique pour les routes ou les composants lourds. Le navigateur ne charge que le code nécessaire à la page courante. Le tree shaking elimine le code mort (fonctions importees mais jamais utilisees) au moment du build. Les bundlers modernes (Webpack, Vite, Rollup) le font automatiquement avec les imports ESM. Ensemble, ils réduisent significativement la taille du JavaScript.
7. Comment optimiser les images pour le web ?
Techniques : format WebP (30% plus léger que JPEG) ou AVIF (50% plus léger), avec fallback. Responsive images : srcset + sizes pour servir la bonne taille selon le viewport. Lazy loading pour les images hors écran. Compression appropriee (qualité 75-85% suffit généralement). CDN d'images (Cloudinary, imgix) pour les transformations à la volee. Placeholder flou (LQIP) pendant le chargement. Pour les icônes : SVG inline ou sprite.
8. Expliquez les stratégies de caching HTTP.
Cache-Control : l'en-tete principal. max-age=31536000 pour les assets versionnees (immutable), no-cache pour les documents HTML (valide avec le serveur avant d'utiliser le cache). ETag/Last-Modified : validation conditionnelle (304 Not Modified). Service Worker : cache programmable cote client (stratégies : Cache First, Network First, Stale While Revalidate). CDN caching : cache les réponses au niveau des edge servers. Stratégie recommandee : HTML (no-cache), assets avec hash dans le nom (max-age=1an, immutable).
9. Qu'est-ce qu'un Service Worker et comment ameliore-t-il les performances ?
Un Service Worker est un script qui s'execute en arriere-plan, indépendamment de la page web. Il intercepte les requêtes réseau et peut servir des réponses depuis le cache. Stratégies de caching : Cache First (cache, puis réseau si absent), Network First (réseau, puis cache si offline), Stale While Revalidate (cache immédiat, mise à jour en arriere-plan). Le Service Worker permet aussi le fonctionnement offline, les notifications push, et le pre-caching des ressources critiques.
10. Comment mesurer et surveiller les performances web ?
Outils : Lighthouse (audit automatise, score de performance), Chrome DevTools Performance tab (timeline detaillee, flame chart), WebPageTest (tests multi-localisations, filmstrip), Core Web Vitals dans Google Search Console (données terrain réelles). RUM (Real User Monitoring) avec les APIs web-vitals, Google Analytics, ou des outils comme Datadog/New Relic. Mesurez en conditions réelles (3G, appareil moyen) et en lab (conditions controlees).