Qu'est-ce que "CLS" (Cumulative Layout Shift) et comment les attributs width/height ou aspect-ratio CSS aident à le réduire ?

Bonne réponse : CLS mesure les déplacements visuels inattendus. Spécifier width/height sur les images/vidéos ou utiliser aspect-ratio réserve l'espace avant le chargement. CLS (Cumulative Layout Shift) mesure l'instabilité visuelle. Les déplacements se produisent quand des éléments sont ajoutés ou redimensionnés après le rendu initial (ex: image qui se charge sans dimensions définies).

Qu'est-ce que "Feature Policy" / "Permissions Policy" et comment l'utiliser pour améliorer la sécurité et les performances ?

Bonne réponse : Un en-tête HTTP qui contrôle quelles fonctionnalités (geolocation, camera, microphone, autoplay) peuvent être utilisées et par quelles origines. Permissions Policy (ex-Feature Policy) permet de débloquer/verrouiller des fonctionnalités du navigateur (geolocation, camera, microphone, autoplay, synchronous XHR, etc.) pour la page et ses iframes.

HTML Senior — Performance et APIs

Q: Quelles sont les différences fondamentales entre les modes "quirks", "almost standards" et "standards" (strict) dans les navigateurs, et comment déclencher chacun ?

Bonne réponse : Le DOCTYPE déclenche le mode. Quirks : pas de DOCTYPE ou DOCTYPE obsolète ; Standards : DOCTYPE HTML complet ; Almost standards : certains DOCTYPEs transitionnels ou images dans des cellules de tableau. Les navigateurs ont trois modes de rendu : Quirks (compatible anciens navigateurs, box model différent), Almost Standards (quelques compromis), Standards (rendu standard complet). Le DOCTYPE déclenche le mode. Un <!DOCTYPE html> déclenche le mode standards dans tous les navigateurs modernes.

Q: Qu'est-ce que le "speculative parsing" (parsing spéculatif) dans les navigateurs et comment optimiser le chargement des ressources ?

Bonne réponse : Le navigateur scanne le HTML à la recherche de ressources (images, scripts, CSS) avant même de construire le DOM complet pour les charger en parallèle. Le speculative parsing (ou preload scanner) est une optimisation des navigateurs. Pendant que le parser principal construit le DOM (bloqué par les scripts), un scanner secondaire analyse le reste du HTML pour découvrir et charger les ressources (images, CSS, scripts) en parallèle.

Q: Quelle est la différence entre defer, async, et un script normal (<script> sans attribut) ?

Bonne réponse : Normal : bloque le parsing HTML ; Async : téléchargement parallèle, exécution immédiate ; Defer : téléchargement parallèle, exécution après le parsing HTML. Normal : le navigateur arrête le parsing HTML, télécharge et exécute le script immédiatement. Async : télécharge en parallèle du parsing, exécute dès que disponible (peut interrompre le parsing). Defer : télécharge en parallèle, exécute dans l'ordre après le parsing HTML complet (avant DOMContentLoaded).

Q: Quelles sont les implications du "layout thrashing" (reflow) et comment l'éviter ?

Bonne réponse : Le layout thrashing se produit quand on alterne lecture et écriture des propriétés géométriques (offsetHeight, scrollTop) forçant des reflows synchrones multiples. Le layout thrashing est un problème de performance causé par des accès répétés à des propriétés qui forcent un reflow synchrone (offsetHeight, clientWidth, scrollTop, etc.) entre des modifications du DOM. Le navigateur doit recalculer la géométrie à chaque lecture.

Q: Comment fonctionne le "event delegation" en JavaScript natif et quels sont ses avantages en termes de performance mémoire ?

Bonne réponse : Un seul écouteur sur un parent qui capture les événements des enfants via le bubbling ; réduit le nombre d'écouteurs et gère les éléments dynamiques. La délégation d'événement exploite le bubbling : on attache un seul écouteur sur un parent (ex: document.body) et on utilise event.target pour identifier l'élément réel. Avantages : moins d'écouteurs (mémoire), fonctionne pour les éléments ajoutés dynamiquement.

Q: Qu'est-ce que le "Shadow DOM" et quels problèmes résout-il dans le développement de composants web ?

Bonne réponse : Encapsulation du DOM et des styles : les styles d'un composant n'affectent pas le reste de la page, et vice-versa. Le Shadow DOM permet de créer un DOM isolé (arbre fantôme) pour un composant. Les styles définis dans le Shadow DOM ne s'appliquent qu'à l'intérieur, et les styles extérieurs ne le traversent pas (sauf via CSS custom properties et parts).

Q: Comment fonctionne le "history API" (pushState, replaceState) et quel est son impact sur le SEO des applications monopage (SPA) ?

Bonne réponse : Permet de changer l'URL sans recharger la page ; nécessite une gestion côté serveur (fallback) et des balises canoniques pour le SEO. pushState() et replaceState() modifient l'URL et l'historique du navigateur sans rechargement. Pour le SEO : le serveur doit être configuré pour servir la même page (index.html) pour toutes les routes (fallback), ou implémenter le rendu côté serveur (SSR) ou le prérendu.

Q: Qu'est-ce que "Content Security Policy" (CSP) et comment la mettre en œuvre pour se protéger contre le XSS ?

Bonne réponse : Un en-tête HTTP qui restreint les sources autorisées pour les scripts, styles, images ; ex: Content-Security-Policy: default-src "self". CSP est un en-tête HTTP (ou meta tag) qui définit les sources autorisées pour les ressources. Exemple : Content-Security-Policy: script-src "self" https://trusted.cdn.com bloque les scripts inline et les chargements depuis des sources non autorisées, prévenant le XSS.

Q: Comment fonctionne le "preload", "prefetch", "preconnect", "prerender" et quels sont leurs cas d'usage ?

Bonne réponse : preload : ressource prioritaire pour la page courante ; prefetch : ressource pour navigation future ; preconnect : établir connexion DNS/TLS ; prerender : précharger page entière. preload : charge une ressource critique nécessaire pour la page courante (ex: police, image LCP). prefetch : charge une ressource probablement utilisée dans les prochaines navigations. preconnect : établit la connexion DNS/TLS à l'avance. prerender : précharge et prérint une page entière.

Q: Qu'est-ce que "DOMContentLoaded" vs "load" et quel est leur impact sur la mesure des performances (LCP, TTI) ?

Bonne réponse : DOMContentLoaded : HTML parsé, DOM construit (sans attendre les images). load : toutes les ressources (images, CSS) sont chargées. LCP se rapproche de load, TTI peut être avant load. DOMContentLoaded se déclenche quand le DOM est prêt (HTML parsé, scripts defer exécutés). load attend que toutes les ressources (images, CSS, iframes) soient chargées. LCP (Largest Contentful Paint) se produit généralement entre DOMContentLoaded et load. TTI (Time to Interactive) peut être avant load si les ressources non bloquantes continuent de charger.

Html Senior Quiz-Html-Senior Shadow-Dom Web-Components Performance-Web Core-Web-Vitals Csp-Securite Cors Intersection-Observer Resource-Timing-Api Subresource-Integrity Http2 Bfcache Qcm-Html-Avance

Sénior 🔀 Mixte 20 questions ⏱ 15 min

📝

HTML Senior — Performance et APIs

20 questions avancées HTML : shadow DOM, web components, performance (CLS, LCP, FID), sécurité (CSP, CORS, SRI), APIs natives (Intersection Observer, Resource Timing), optimisation des ressources et architectures modernes du web. Idéal pour réussir un entretien HTML Senior.

20 questions ⏱ ~15 min Niveau Sénior

Publié/Développé par Mezgani Said

Développeur web full‑stack et formateur spécialisé en Angular, TypeScript et Node.js, il partage sur AngularForAll des ressources complètes pour les développeurs : tutoriels pratiques, guides pas‑à‑pas, outils gratuits, exercices, QCM techniques et retours d’expérience issus de projets réels (SaaS, micro‑frontends, architectures modulaires, applications d’entreprise).
Le site couvre l’ensemble de l’écosystème web : front‑end, intégration HTML/CSS, Composants réutilisables, SEO, back‑end, cloud, IA, CLI, productivité, bien‑être, outils web et métiers du digital.
Un espace pensé pour générer, apprendre, progresser et développer des projets modernes avec des bonnes pratiques professionnelles.

Banque de révision : les 25 questions corrigées

Voici l'intégralité des 25 questions de « HTML Senior — Performance et APIs », chacune avec sa bonne réponse et son explication. Le quiz interactif ci-dessus en tire une sélection aléatoire à chaque tentative — utilisez cette liste complète pour réviser.

Le DOCTYPE déclenche le mode. Quirks : pas de DOCTYPE ou DOCTYPE obsolète ; Standards : DOCTYPE HTML complet ; Almost standards : certains DOCTYPEs transitionnels ou images dans des cellules de tableau (bonne réponse)
Le mode est déterminé par la version du navigateur uniquement
Tous les navigateurs modernes utilisent le même mode
Le mode se configure via un meta tag

Explication : Les navigateurs ont trois modes de rendu : Quirks (compatible anciens navigateurs, box model différent), Almost Standards (quelques compromis), Standards (rendu standard complet). Le DOCTYPE déclenche le mode. Un <!DOCTYPE html> déclenche le mode standards dans tous les navigateurs modernes.

Toujours utiliser <!DOCTYPE html> pour garantir le mode standards. Évitez les DOCTYPEs transitionnels ou frameset qui déclenchent le mode almost standards dans certains navigateurs.

Le navigateur scanne le HTML à la recherche de ressources (images, scripts, CSS) avant même de construire le DOM complet pour les charger en parallèle (bonne réponse)
Une technique de préchargement JavaScript
Un mode de débogage
Une fonctionnalité désactivée par défaut

Explication : Le speculative parsing (ou preload scanner) est une optimisation des navigateurs. Pendant que le parser principal construit le DOM (bloqué par les scripts), un scanner secondaire analyse le reste du HTML pour découvrir et charger les ressources (images, CSS, scripts) en parallèle.

Pour optimiser : placez les <link rel="preload"> pour les ressources critiques, utilisez async/defer pour les scripts non bloquants.

Normal : bloque le parsing HTML ; Async : téléchargement parallèle, exécution immédiate ; Defer : téléchargement parallèle, exécution après le parsing HTML (bonne réponse)
Ils sont identiques
Async bloque le parsing, Defer aussi
Normal est plus rapide que Async

Explication : Normal : le navigateur arrête le parsing HTML, télécharge et exécute le script immédiatement. Async : télécharge en parallèle du parsing, exécute dès que disponible (peut interrompre le parsing). Defer : télécharge en parallèle, exécute dans l'ordre après le parsing HTML complet (avant DOMContentLoaded).

Utilisez defer pour les scripts qui dépendent du DOM complet, async pour les scripts indépendants (analytics), normal pour les scripts critiques.

Le layout thrashing se produit quand on alterne lecture et écriture des propriétés géométriques (offsetHeight, scrollTop) forçant des reflows synchrones multiples (bonne réponse)
Une erreur de parsing HTML
Un problème de cache navigateur
Une vulnérabilité de sécurité

Explication : Le layout thrashing est un problème de performance causé par des accès répétés à des propriétés qui forcent un reflow synchrone (offsetHeight, clientWidth, scrollTop, etc.) entre des modifications du DOM. Le navigateur doit recalculer la géométrie à chaque lecture.

Solutions : grouper les lectures, puis les écritures ; utiliser requestAnimationFrame ; éviter d'accéder aux propriétés de layout dans les boucles.

Un seul écouteur sur un parent qui capture les événements des enfants via le bubbling ; réduit le nombre d'écouteurs et gère les éléments dynamiques (bonne réponse)
Attacher un écouteur à chaque élément enfant
Désactiver le bubbling des événements
Une fonction spécifique à jQuery

Explication : La délégation d'événement exploite le bubbling : on attache un seul écouteur sur un parent (ex: document.body) et on utilise event.target pour identifier l'élément réel. Avantages : moins d'écouteurs (mémoire), fonctionne pour les éléments ajoutés dynamiquement.

Exemple : document.querySelector("ul").addEventListener("click", (e) => { if(e.target.tagName === "LI") { ... } })

Encapsulation du DOM et des styles : les styles d'un composant n'affectent pas le reste de la page, et vice-versa (bonne réponse)
Une nouvelle balise HTML
Un framework JavaScript
Une technique d'optimisation des images

Explication : Le Shadow DOM permet de créer un DOM isolé (arbre fantôme) pour un composant. Les styles définis dans le Shadow DOM ne s'appliquent qu'à l'intérieur, et les styles extérieurs ne le traversent pas (sauf via CSS custom properties et parts).

Utilisé par les Web Components. Exemple : element.attachShadow({ mode: "open" }). Les navigateurs l'utilisent pour les contrôles natifs (<video>).

Permet de changer l'URL sans recharger la page ; nécessite une gestion côté serveur (fallback) et des balises canoniques pour le SEO (bonne réponse)
Change l'URL avec rechargement de page
Aucun impact sur le SEO
Les SPA ne peuvent pas être indexées

Explication : pushState() et replaceState() modifient l'URL et l'historique du navigateur sans rechargement. Pour le SEO : le serveur doit être configuré pour servir la même page (index.html) pour toutes les routes (fallback), ou implémenter le rendu côté serveur (SSR) ou le prérendu.

Pour les SPA, utilisez le rendu côté serveur (Next.js, Nuxt) ou le prérendu (Gatsby) pour le SEO. Configurez votre serveur avec un fallback vers index.html.

Un en-tête HTTP qui restreint les sources autorisées pour les scripts, styles, images ; ex: Content-Security-Policy: default-src "self" (bonne réponse)
Une balise meta pour les cookies
Un framework JavaScript
Une fonctionnalité de navigateur désactivée par défaut

Explication : CSP est un en-tête HTTP (ou meta tag) qui définit les sources autorisées pour les ressources. Exemple : Content-Security-Policy: script-src "self" https://trusted.cdn.com bloque les scripts inline et les chargements depuis des sources non autorisées, prévenant le XSS.

Commencez en mode "report-only" pour tester. Activez le mode strict avec nonce ou hash pour les scripts inline.

preload : ressource prioritaire pour la page courante ; prefetch : ressource pour navigation future ; preconnect : établir connexion DNS/TLS ; prerender : précharger page entière (bonne réponse)
Tous font la même chose
prefetch est plus important que preload
prerender est déprécié

Explication : preload : charge une ressource critique nécessaire pour la page courante (ex: police, image LCP). prefetch : charge une ressource probablement utilisée dans les prochaines navigations. preconnect : établit la connexion DNS/TLS à l'avance. prerender : précharge et prérint une page entière.

Utilisez preload pour les ressources critiques, preconnect pour les origines tierces (CDN, APIs), prefetch pour les pages suivantes (ex: page de produit depuis une liste).

DOMContentLoaded : HTML parsé, DOM construit (sans attendre les images). load : toutes les ressources (images, CSS) sont chargées. LCP se rapproche de load, TTI peut être avant load (bonne réponse)
Ils sont identiques
DOMContentLoaded attend toutes les images
load se déclenche avant DOMContentLoaded

Explication : DOMContentLoaded se déclenche quand le DOM est prêt (HTML parsé, scripts defer exécutés). load attend que toutes les ressources (images, CSS, iframes) soient chargées. LCP (Largest Contentful Paint) se produit généralement entre DOMContentLoaded et load. TTI (Time to Interactive) peut être avant load si les ressources non bloquantes continuent de charger.

Utilisez DOMContentLoaded pour initialiser l'interactivité précoce, load pour charger les ressources secondaires (analytics).

Le navigateur diffère le chargement de l'image jusqu'à ce qu'elle soit proche du viewport (détection intersection observer) (bonne réponse)
L'image est chargée après le chargement complet de la page
L'image n'est jamais chargée
L'image est chargée mais affichée en basse résolution

Explication : L'attribut loading="lazy" utilise l'Intersection Observer API pour détecter quand l'image ou l'iframe approche du viewport. Le chargement est différé jusqu'à ce moment, améliorant le LCP et économisant la bande passante.

Vérifiez dans les outils développeur (Network tab) que les images ne se chargent qu'au scroll. Ne lazy loader pas les images LCP (visible au chargement).

CLS mesure les déplacements visuels inattendus. Spécifier width/height sur les images/vidéos ou utiliser aspect-ratio réserve l'espace avant le chargement (bonne réponse)
CLS mesure le temps de chargement
CLS mesure le nombre de requêtes
CLS ne peut pas être amélioré

Explication : CLS (Cumulative Layout Shift) mesure l'instabilité visuelle. Les déplacements se produisent quand des éléments sont ajoutés ou redimensionnés après le rendu initial (ex: image qui se charge sans dimensions définies).

Solution : toujours spécifier width et height sur les images, ou utiliser CSS aspect-ratio pour réserver l'espace. Évitez d'insérer du contenu au-dessus d'un contenu existant.

srcset : différentes résolutions d'une même image ; picture : différents types d'images (WebP vs JPEG) ou différents crops selon le viewport (art direction) (bonne réponse)
Ils sont identiques
picture est déprécié
srcset ne fonctionne que pour la largeur

Explication : srcset permet de fournir différentes résolutions (densité d'écran) de la même image. <picture> permet le "art direction" : différentes images (crops, formats) selon la taille d'écran, ou différents formats (WebP, AVIF) pour la compatibilité.

Utilisez srcset pour les images responsives standards, picture pour le WebP/AVIF (avec fallback JPEG) ou pour des versions recadrées sur mobile.

avec méthodes .showModal() (modal, bloque interaction) ou .show() (non-modal), et attribut open (bonne réponse)
Une simple div avec du CSS
Un élément déprécié
Une alternative à window.alert()

Explication : L'élément <dialog> crée des boîtes de dialogue natives. .showModal() ouvre un modal (bloque le reste de la page, fond semi-transparent). .show() ouvre non-modal. .close() ferme. returnValue récupère la valeur sélectionnée.

Un bouton avec formmethod="dialog" dans un formulaire ferme automatiquement le dialog. CSS pseudo-element ::backdrop pour styliser le fond.

Pour les requêtes non-simple (ex: PUT, DELETE, en-têtes personnalisés), le navigateur envoie d'abord une requête OPTIONS pour vérifier les permissions (bonne réponse)
CORS est une balise HTML
Le preflight est optionnel
Toutes les requêtes cross-origin envoient un preflight

Explication : CORS permet aux serveurs de contrôler quels domaines peuvent accéder à leurs ressources. Pour les requêtes "non-simple" (méthode autre que GET/POST, en-têtes personnalisés, content-type non standard), le navigateur envoie un preflight OPTIONS avant la requête réelle pour vérifier les permissions.

Le serveur doit répondre aux OPTIONS avec les en-têtes Access-Control-Allow-*. En développement, un proxy peut éviter les problèmes CORS.

Un en-tête HTTP qui contrôle quelles fonctionnalités (geolocation, camera, microphone, autoplay) peuvent être utilisées et par quelles origines (bonne réponse)
Une nouvelle API JavaScript
Un framework CSS
Un outil de debugging

Explication : Permissions Policy (ex-Feature Policy) permet de débloquer/verrouiller des fonctionnalités du navigateur (geolocation, camera, microphone, autoplay, synchronous XHR, etc.) pour la page et ses iframes.

Exemple : Permissions-Policy: geolocation=(self), camera=(). Utile pour la sécurité et les performances (ex: désactiver synchronous XHR).

L'Intersection Observer asynchrone (non-bloquante) évite les reflows synchrones et fonctionne hors du thread principal, contrairement à getBoundingClientRect qui force un reflow (bonne réponse)
C'est la même chose
Intersection Observer est plus lent
getBoundingClientRect est asynchrone

Explication : Intersection Observer est une API asynchrone qui exécute un callback quand un élément entre/sort du viewport ou d'un élément racine. Contrairement à scroll + getBoundingClientRect (synchrone, force reflow), l'Observer fonctionne hors du thread principal, ne bloque pas le rendu, et est plus performant.

Cas d'usage : lazy loading d'images, chargement infini (infinite scroll), tracking de visibilité, animations au scroll.

Navigation Timing : métriques de chargement de page (DNS, TCP, request, response, DOMContentLoaded, load). Resource Timing : métriques pour chaque ressource (image, script, CSS) (bonne réponse)
Des API pour les animations
Des frameworks JavaScript
Des fonctions de console

Explication : Navigation Timing API (performance.timing déprécié, performance.getEntriesByType("navigation")) donne les métriques de chargement de la page. Resource Timing API (performance.getEntriesByType("resource")) donne les détails de chaque ressource individuelle (temps DNS, connexion, transfert).

Utilisez PerformanceObserver pour capturer les métriques en temps réel. Ces API sont la base des outils RUM (Real User Monitoring).

Contrôle l'envoi des credentials (cookies, certificats) aux requêtes cross-origin et influence l'accès aux données (ex: Canvas avec images cross-origin) (bonne réponse)
Force le chargement en HTTP/2
Optimise le caching
Ajoute un certificat SSL

Explication : L'attribut crossorigin contrôle si les requêtes cross-origin envoient les credentials (cookies, certificats client). Valeurs : "anonymous" (pas de credentials), "use-credentials" (avec credentials). Affecte aussi la tainted canvas : une image cross-origin sans CORS approprié ne peut pas être lue par canvas.getImageData().

Pour les scripts externes, crossorigin="anonymous" est nécessaire pour capturer les erreurs (window.onerror).

Server Push envoie des ressources avant que le client ne les demande, mais peut sur-envoyer (over-push). Preload est plus efficace et ne remplace pas le cache du navigateur (bonne réponse)
Server Push est plus récent que preload
Preload est déprécié
Ils sont identiques

Explication : HTTP/2 Server Push permet au serveur d'envoyer des ressources sans attendre la requête. Problèmes : sur-envoi (ressources déjà en cache), compétition avec la bande passante, suppression de la priorisation. preload est préféré car il respecte le cache et donne plus de contrôle.

Si vous utilisez Server Push, implémentez la détection de cache avec l'en-tête Cache-Digest. Dans la plupart des cas, preload est plus simple et efficace.

SRI ajoute un hash (integrity) aux ressources externes ; le navigateur vérifie que la ressource chargée correspond au hash, sinon bloque l'exécution (bonne réponse)
Un système de cache
Une alternative à HTTPS
Un framework de sécurité

Explication : SRI (Subresource Integrity) utilise l'attribut integrity avec un hash (SHA-256, SHA-384, SHA-512) des ressources externes (scripts, styles). Si la ressource chargée ne correspond pas au hash (ex: CDN hackée, attaque MITM), le navigateur bloque l'exécution.

Exemple : <script src="https://cdn.com/lib.js" integrity="sha384-..." crossorigin="anonymous"></script>. Générez les hashs avec openssl dgst -sha384 fichier.js.

mode: "open" : accessible via element.shadowRoot ; mode: "closed" : non accessible (null). Les ARIA attributes ne traversent pas naturellement le shadow DOM, nécessitant des attributs ARIA explicites dans chaque arbre (bonne réponse)
Il n'y a pas de différence
Closed est plus sécurisé pour l'accessibilité
Open empêche l'accessibilité

Explication : Shadow DOM ouvert : accessible en JavaScript (element.shadowRoot). Fermé : inaccessible (null), utilisé par certains composants natifs (video). Pour l'accessibilité, les relations ARIA ne traversent pas les frontières du shadow DOM ; il faut dupliquer les attributs ARIA ou utiliser des parties accessibles (ElementInternals).

Pour les composants personnalisés, utilisez mode: "open" pour faciliter le débogage et l'accessibilité. Utilisez ElementInternals pour exposer les rôles ARIA.

Les ressources (CSS, scripts sync) qui empêchent le navigateur de peindre le contenu. Solutions : inline critical CSS, defer/async pour scripts, preload pour ressources critiques (bonne réponse)
Toutes les ressources bloquent le rendu
Seules les images bloquent
Les videos bloquent le rendu

Explication : Les ressources render-blocking sont les CSS externes (bloquent le rendu) et les scripts synchrones (bloquent le parsing HTML). Pour optimiser : inline le CSS critique (au-dessus de la fold), différer le CSS non critique avec media="print" onload, utiliser defer/async pour les scripts.

Utilisez Lighthouse ou WebPageTest pour identifier les ressources bloquantes. Visez un First Paint < 1s.

Le navigateur met en cache la page entière (état du DOM, JS) pour une navigation instantanée retour/avant. Écouter l'événement "pageshow" (persisted) pour détecter restauration (bonne réponse)
BFCache est une extension navigateur
BFCache ne fonctionne qu'en HTTPS
BFCache n'affecte pas l'état JS

Explication : Le BFCache (ou page cache) garde la page dans un état figé (y compris l'état JavaScript). Quand l'utilitaire utilise retour/avant, la page est restaurée instantanément. L'événement pageshow avec event.persisted indique si la page vient du BFCache.

Évitez de casser le BFCache (onunload, unload). Utilisez pageshow pour rafraîchir les données obsolètes. Le BFCache est excellent pour les performances.

font-display: swap (FOUT) ; optional (cache uniquement) ; fallback (court FOIT puis swap) ; block (FOIT long). Swap est préféré pour la performance perçue (bonne réponse)
Les polices n'ont pas d'impact sur les performances
font-display ne fonctionne pas avec les polices Google
Il faut toujours utiliser FOIT

Explication : FOIT (Flash of Invisible Text) : texte invisible jusqu'au chargement de la police. FOUT (Flash of Unstyled Text) : police système puis remplacement. font-display : swap (FOUT, recommandé pour la performance perçue), optional (utilise le cache, pas de fallback réseau), fallback (FOIT très court puis swap), block (FOIT long).

Utilisez font-display: swap pour le texte principal. Préchargez les polices critiques avec <link rel="preload" as="font">. Utilisez des polices variables pour réduire le nombre de fichiers.

HTML Senior — Performance et APIs

Partager

Banque de révision : les 25 questions corrigées

Q1. Quelles sont les différences fondamentales entre les modes "quirks", "almost standards" et "standards" (strict) dans les navigateurs, et comment déclencher chacun ?

Q2. Qu'est-ce que le "speculative parsing" (parsing spéculatif) dans les navigateurs et comment optimiser le chargement des ressources ?

Q3. Quelle est la différence entre defer, async, et un script normal (&lt;script&gt; sans attribut) ?

Q4. Quelles sont les implications du "layout thrashing" (reflow) et comment l'éviter ?

Q5. Comment fonctionne le "event delegation" en JavaScript natif et quels sont ses avantages en termes de performance mémoire ?

Q6. Qu'est-ce que le "Shadow DOM" et quels problèmes résout-il dans le développement de composants web ?

Q7. Comment fonctionne le "history API" (pushState, replaceState) et quel est son impact sur le SEO des applications monopage (SPA) ?

Q8. Qu'est-ce que "Content Security Policy" (CSP) et comment la mettre en œuvre pour se protéger contre le XSS ?

Q9. Comment fonctionne le "preload", "prefetch", "preconnect", "prerender" et quels sont leurs cas d'usage ?

Q10. Qu'est-ce que "DOMContentLoaded" vs "load" et quel est leur impact sur la mesure des performances (LCP, TTI) ?

Q11. Comment fonctionne l'attribut loading="lazy" pour les images et iframes, et comment vérifier qu'il est bien efficace ?

Q12. Qu'est-ce que "CLS" (Cumulative Layout Shift) et comment les attributs width/height ou aspect-ratio CSS aident à le réduire ?

Q13. Quelle est la différence entre &lt;picture&gt; et &lt;img srcset&gt; pour les images responsives ?

Q14. Comment fonctionne le "dialog element" HTML5 et quelle est son API JavaScript associée ?

Q15. Qu'est-ce que "Cross-Origin Resource Sharing" (CORS) et comment fonctionne le "preflight request" (OPTIONS) ?

Q16. Qu'est-ce que "Feature Policy" / "Permissions Policy" et comment l'utiliser pour améliorer la sécurité et les performances ?

Q17. Comment fonctionne l'API "Intersection Observer" et quel est son avantage par rapport à l'écoute de scroll + getBoundingClientRect ?

Q18. Qu'est-ce que "Resource Timing API" et "Navigation Timing API" pour la mesure des performances ?

Q19. Quelles sont les implications de l'attribut crossorigin sur les éléments &lt;script&gt;, &lt;link&gt; et &lt;img&gt; ?

Q20. Comment fonctionne "Server Push" (HTTP/2 push) et pourquoi est-il souvent déconseillé aujourd'hui au profit de "preload" ?

Q21. Qu'est-ce que "Subresource Integrity" (SRI) et comment protège-t-il contre les CDN compromises ?

Q22. Comment fonctionne le "shadow DOM" ouvert vs fermé et quelles sont les implications pour l'accessibilité (ARIA) ?

Q23. Qu'est-ce que "Render-Blocking Resources" et comment identifier/optimiser les ressources qui bloquent le premier affichage (FCP/LCP) ?

Q24. Comment fonctionne "BFCache" (Back-Forward Cache) et comment éviter que l'état de la page ne soit mal restauré ?

Q25. Quelles sont les stratégies avancées pour l'optimisation du chargement des polices (FOIT, FOUT) avec font-display ?

Voir aussi

Explorer par mot clé