Nombre de calques, taux de repli et substitution de polices lors d'un import Figma

Tu ouvres le panneau des calques d'un import et trois chiffres te disent presque tout ce qu'il faut savoir: combien de calques tu as obtenus, combien de sections sont retombées en position fixe plutôt qu'en auto layout, et combien de polices ont été substituées. Rien de tout ça n'est aléatoire. Ces trois chiffres remontent directement à la façon dont le HTML, le CSS et les polices de la page d'origine ont été construits, et des données publiques sur des millions de pages réelles montrent déjà ce schéma.

La méthode de capture compte ici, donc elle vient en premier. Les chiffres sur le nombre de calques viennent du Web Almanac 2024 de HTTP Archive, qui explore le DOM de millions de pages actives deux fois par an. Les chiffres sur les polices viennent du chapitre polices du Web Almanac 2025, du même projet. Les deux sont des jeux de données publics et datés. C'est une façon plus honnête de répondre à "à quoi ressemble un import typique" que de faire tourner UnHTML sur un petit lot de pages et d'appeler ça représentatif.

Combien de calques une page marketing génère réellement

UnHTML calque la structure d'une page un pour un: un div devient un frame, un nœud de texte devient un calque de texte, une image devient un remplissage image. Rien n'est aplati ni fusionné en cours de route, donc le nombre de calques d'un import suit de près le nombre d'éléments DOM de la page.

La distribution est plus large que ce que la plupart des gens attendent. Selon la répartition par percentiles du Web Almanac 2024 pour les pages mobiles, la page au 10e percentile compte 180 éléments. Le 25e en compte 342. La médiane se situe à 594. Le 75e percentile atteint 1 010, et le 90e atteint 1 716. La médiane a légèrement baissé, passant de 653 en 2022 à 594 en 2024, mais le quart supérieur des pages reste bien au dessus du millier d'éléments.

L'origine de ces éléments compte aussi. Les divs représentent à eux seuls 28,7% de tous les éléments d'une page moyenne, avec les balises de lien (a) à 12,6% et les spans à 11,2%. En ajoutant les éléments de liste (li) à 7,7%, la majeure partie d'un nombre de calques typique est constituée de conteneurs génériques et de liens, pas de nœuds porteurs de contenu réel. Une page construite avec des divs imbriqués à l'excès dépassera toujours en nombre de calques une page au contenu visible identique mais construite avec un balisage sémantique et plus plat.

Cette distribution correspond directement au forfait gratuit d'UnHTML, plafonné à 500 calques et qui utilise un positionnement absolu plutôt que l'auto layout. Une page au 25e percentile, 342 éléments, passe cette limite sans problème. La page médiane, 594 éléments, la dépasse déjà. Une page au 75e percentile, 1 010 éléments, fait plus du double de la limite. L'audit de taille du DOM de Lighthouse lui même avertit à partir de 800 nœuds et échoue complètement au delà de 1 400. Autrement dit, la page déjà signalée pour excès de DOM dans PageSpeed Insights est, selon la même mesure, la page la plus susceptible d'avoir besoin de la conversion auto layout sans limite de Pro plutôt que du forfait gratuit.

Substitution de polices: qui est exposé et qui ne l'est pas

La substitution de polices n'est pas non plus répartie uniformément sur le web. Le chapitre polices du Web Almanac 2025 situe l'usage de polices web à 88% de toutes les pages, en légère hausse par rapport aux 87% de 2024. Les 12% restants s'appuient sur les polices système et ne posent jamais de question de substitution.

Parmi les 88% qui utilisent bien une police personnalisée, l'hébergement est la ligne de partage. 72% hébergent eux mêmes au moins un fichier de police, tandis que Google Fonts apparaît seul sur 54% des pages de bureau et 47% des pages mobiles. Figma récupère n'importe quelle Google Font à la demande, sans installation locale nécessaire, donc cette moitié approximative de tout l'usage de polices ne déclenche presque jamais de substitution. L'exposition se concentre sur la part auto hébergée qui n'est pas chez Google.

Le format ajoute un autre filtre, et il touche plus de pages que le seul choix d'hébergement ne le suggérerait. 65,2% des requêtes de polices sur le web sont livrées en WOFF2, le format moderne dominant. Mais depuis 2026, l'installation locale de polices de Figma ne lit que les fichiers TTF et OTF. Une police auto hébergée, correctement sous licence et présente sur la page en WOFF2, se substitue malgré tout à l'import, sauf si cette même famille existe aussi sur ta machine en TTF ou OTF. Avoir la bonne police n'est pas la même chose que l'avoir dans un format que Figma peut lire.

Les polices variables ajoutent un cas d'échec plus étroit. 39,4% des pages de bureau et 41,3% des pages mobiles utilisent déjà une police variable. Si le fichier installé manque d'un seul style statique, souvent le gras, seul ce style est substitué tandis que le reste de la famille s'importe correctement. Le résultat paraît étrange la première fois qu'on le voit dans un rapport: une famille en partie correcte, en partie substituée.

À quoi ressemble vraiment un repli une fois qu'il se produit

Deux types de repli distincts apparaissent lors d'un import, et ils viennent d'endroits différents. Le premier concerne la mise en page: une section qui ne peut pas se calquer proprement sur l'auto layout de Figma retombe en position absolue et fixe. Le second concerne la police: un nœud de texte que UnHTML ne peut pas résoudre face à une police installée ou une Google Font retombe sur Inter, consigné dans le rapport d'import.

Le repli de mise en page n'est pas un problème de compatibilité navigateur. Le support de Flexbox atteint 98% des navigateurs en usage actif, et celui de Grid se situe à 97,5%, pratiquement universel sur les deux spécifications. Quand une section retombe malgré tout en position absolue à l'import, la cause tient à la façon précise dont le CSS de cette section a été écrit: conteneurs imbriqués à l'excès, contextes de positionnement mélangés, ou mise en page pilotée par JavaScript plutôt que par des règles CSS que UnHTML peut lire de façon statique. Pas une fonctionnalité manquante dans le navigateur qui l'affiche.

Figma a son propre repli, distinct, un niveau sous les changements de police que UnHTML consigne. Selon le blog d'ingénierie de Figma lui même, quand un caractère n'a pas de glyphe dans la police active, Figma résout ce caractère isolé avec la famille de polices Noto, de façon cohérente sur macOS, Windows et le web, plutôt que d'enchaîner les polices de repli propres à chaque plateforme qu'utiliserait un navigateur. C'est un repli plus étroit, au niveau du caractère, à l'intérieur du moteur de rendu de Figma, distinct de la substitution au niveau de la famille que consigne un rapport d'import.

Lire son propre rapport d'import

Le rapport généré par un import est le moyen le plus rapide de transformer ces moyennes en une réponse précise pour une page précise. Trois choses valent la peine d'être vérifiées, dans cet ordre: le nombre total de calques face à la limite des 500 calques du forfait gratuit, la liste des familles de polices substituées face à ce qui est réellement installé localement, et toute section signalée comme repli en position fixe si tu comptes la retravailler plus tard.

Une façon pratique de parcourir un rapport contenant plusieurs substitutions: regarder la liste d'abord. Puis décider, famille par famille, s'il vaut la peine d'installer la vraie police localement en TTF ou OTF et de relancer l'import, ou d'accepter Inter parce que le fichier est une maquette rapide plutôt qu'une reconstruction exacte de la typographie. UnHTML affiche ce rapport automatiquement à chaque import, conformément à sa propre politique de confidentialité qui consiste à tout résoudre localement.

Ce que ces chiffres donnent au final

Le nombre de calques, le taux de repli et la substitution de polices remontent tous à la même cause: la façon dont le balisage, le CSS et les polices d'une page précise ont été construits. Une page légère et sémantique avec des Google Fonts et des règles flex ou grid propres restera sous le forfait gratuit et arrivera avec sa typographie intacte. Une page chargée de divs, construite avec des polices WOFF2 auto hébergées et des sections en position absolue, atteindra la limite de calques, substituera plusieurs polices et nécessitera une seconde passe sur la mise en page.

Rien de tout cela n'est visible avant l'import. Ça devient visible au moment où tu ouvres le rapport.