Questions d'entretien Performance Web
1. Quels sont les Core Web Vitals et pourquoi sont-ils importants ?
Les Core Web Vitals sont les metriques de Google qui mesurent l'experience utilisateur : LCP (Largest Contentful Paint, < 2.5s) : temps d'affichage du plus grand element visible. INP (Interaction to Next Paint, < 200ms) : reactivite aux interactions utilisateur. CLS (Cumulative Layout Shift, < 0.1) : stabilite visuelle de la page. Ces metriques impactent le SEO (facteur de classement Google) et la conversion (chaque seconde de chargement reduit les conversions de 7%).
2. Comment optimiser le LCP (Largest Contentful Paint) ?
Le LCP mesure le temps d'affichage du plus grand element 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), reduire le TTFB (temps de reponse 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 reduire le CLS (Cumulative Layout Shift) ?
Le CLS mesure les decalages visuels inattendus. Causes courantes : images/videos 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 definir les dimensions des medias, utiliser font-display: swap avec preload, reserver l'espace pour les contenus dynamiques, et eviter d'inserer du contenu au-dessus du fold apres le chargement.
4. Expliquez le critical rendering path et comment l'optimiser.
Le critical rendering path est la sequence d'etapes du navigateur pour afficher le premier pixel : reception HTML -> construction du DOM -> reception 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, reduire la profondeur des chaines de dependances, 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 reduit le poids initial de la page et accelere 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 a la demande. Implementez-le avec import() dynamique pour les routes ou les composants lourds. Le navigateur ne charge que le code necessaire a 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 reduisent significativement la taille du JavaScript.
7. Comment optimiser les images pour le web ?
Techniques : format WebP (30% plus leger que JPEG) ou AVIF (50% plus leger), avec fallback. Responsive images : srcset + sizes pour servir la bonne taille selon le viewport. Lazy loading pour les images hors ecran. Compression appropriee (qualite 75-85% suffit generalement). CDN d'images (Cloudinary, imgix) pour les transformations a la volee. Placeholder flou (LQIP) pendant le chargement. Pour les icones : SVG inline ou sprite.
8. Expliquez les strategies 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 (strategies : Cache First, Network First, Stale While Revalidate). CDN caching : cache les reponses au niveau des edge servers. Strategie 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, independamment de la page web. Il intercepte les requetes reseau et peut servir des reponses depuis le cache. Strategies de caching : Cache First (cache, puis reseau si absent), Network First (reseau, puis cache si offline), Stale While Revalidate (cache immediat, mise a 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 (donnees terrain reelles). RUM (Real User Monitoring) avec les APIs web-vitals, Google Analytics, ou des outils comme Datadog/New Relic. Mesurez en conditions reelles (3G, appareil moyen) et en lab (conditions controlees).