Ebenenanzahl, Fallback-Raten und Schriftersetzung bei einem Figma Import

Öffnest du das Ebenenpanel eines Imports, sagen dir drei Zahlen fast alles, was du wissen musst: wie viele Ebenen du bekommen hast, wie viele Abschnitte statt auto layout auf feste Position zurückgefallen sind, und wie viele Schriften ersetzt wurden. Nichts davon ist zufällig. Alle drei Zahlen gehen direkt darauf zurück, wie das HTML, CSS und die Schriften der ursprünglichen Seite gebaut wurden, und öffentliche Messdaten zu Millionen von echten Seiten zeigen das Muster bereits.

Die Erfassungsmethode ist hier wichtig, deshalb zuerst dazu. Die Zahlen zur Ebenenanzahl stammen aus dem Web Almanac 2024 von HTTP Archive, das zweimal jährlich das DOM von Millionen aktiver Seiten crawlt. Die Schriftzahlen stammen aus dem Schriftkapitel des Web Almanac 2025, demselben Projekt. Beide sind öffentliche, datierte Datensätze. Das ist eine ehrlichere Art, "wie sieht ein typischer Import aus" zu beantworten, als UnHTML an einer kleinen Stichprobe von Seiten laufen zu lassen und das als repräsentativ zu bezeichnen.

Wie viele Ebenen eine Marketingseite tatsächlich erzeugt

UnHTML bildet die Struktur einer Seite eins zu eins ab: ein div wird zu einem Frame, ein Textknoten wird zu einer Textebene, ein Bild wird zu einer Bildfüllung. Dabei wird nichts geglättet oder zusammengeführt, sodass die Ebenenanzahl eines Imports eng mit der DOM Elementanzahl der Seite zusammenhängt.

Die Verteilung ist breiter, als die meisten erwarten. Laut der Perzentilaufschlüsselung des Web Almanac 2024 für mobile Seiten hat die 10. Perzentile Seite 180 Elemente. Die 25. hat 342. Der Median liegt bei 594. Die 75. Perzentile erreicht 1.010, und die 90. erreicht 1.716. Der Median ist leicht gesunken, von 653 im Jahr 2022 auf 594 im Jahr 2024, aber das obere Viertel der Seiten liegt weiterhin deutlich über tausend Elementen.

Woher diese Elemente kommen, spielt ebenfalls eine Rolle. Divs machen allein 28,7% aller Elemente auf einer durchschnittlichen Seite aus, mit Link Tags (a) bei 12,6% und Spans bei 11,2%. Zählt man Listenelemente (li) mit 7,7% dazu, besteht der Großteil einer typischen Ebenenanzahl aus generischen Containern und Links, nicht aus Knoten mit echtem Inhalt. Eine Seite mit übermäßig verschachtelten Wrapper Divs übertrifft in der Ebenenanzahl immer eine Seite mit dem gleichen sichtbaren Inhalt, die auf semantischem, flacherem Markup aufbaut.

Diese Verteilung passt direkt zum Gratis Tarif von UnHTML, der bei 500 Ebenen liegt und statt auto layout absolute Positionierung verwendet. Eine Seite in der 25. Perzentile, 342 Elemente, bleibt bequem unter dieser Grenze. Die mediane Seite, 594 Elemente, liegt bereits darüber. Eine Seite in der 75. Perzentile, 1.010 Elemente, liegt mehr als doppelt so hoch wie die Grenze. Lighthouses eigene DOM Größenprüfung warnt ab 800 Knoten und schlägt oberhalb von 1.400 vollständig fehl. Das heißt, die Seite, die in PageSpeed Insights bereits wegen DOM Überlastung markiert ist, ist nach demselben Maßstab die Seite, die am wahrscheinlichsten die unbegrenzte auto layout Konvertierung von Pro statt des Gratis Tarifs braucht.

Schriftersetzung: wer betroffen ist und wer nicht

Auch die Schriftersetzung verteilt sich nicht gleichmäßig im Web. Das Schriftkapitel des Web Almanac 2025 setzt die Nutzung von Webschriften auf 88% aller Seiten, etwas mehr als die 87% von 2024. Die restlichen 12% verlassen sich auf Systemschriften und stehen nie vor einer Ersetzungsfrage.

Unter den 88%, die eine eigene Schrift verwenden, ist das Hosting die entscheidende Linie. 72% hosten mindestens eine Schriftdatei selbst, während Google Fonts allein auf 54% der Desktop Seiten und 47% der mobilen Seiten erscheint. Figma ruft jede Google Font bei Bedarf ab, ohne dass eine lokale Installation nötig ist, sodass diese ungefähre Hälfte der gesamten Schriftnutzung praktisch nie eine Ersetzung auslöst. Die Belastung konzentriert sich auf den selbst gehosteten, nicht Google Anteil.

Das Format fügt einen weiteren Filter hinzu, und er erfasst mehr Seiten, als die Hosting Wahl allein vermuten lässt. 65,2% der Schriftanfragen im Web werden als WOFF2 ausgeliefert, dem dominierenden modernen Format. Aber mit Stand 2026 liest Figmas lokale Schriftinstallation nur TTF und OTF Dateien. Eine selbst gehostete Schrift, korrekt lizenziert und als WOFF2 auf der Seite vorhanden, wird beim Import trotzdem ersetzt, sofern dieselbe Familie nicht auch als TTF oder OTF lokal auf deinem Rechner existiert. Die richtige Schrift zu haben ist nicht dasselbe wie sie in einem Format zu haben, das Figma sehen kann.

Variable Schriften bringen einen engeren Fehlerfall mit sich. 39,4% der Desktop Seiten und 41,3% der mobilen Seiten verwenden bereits eine variable Schrift. Fehlt der installierten Datei ein einzelner statischer Stil, häufig Bold, wird nur dieser eine Stil ersetzt, während der Rest der Familie korrekt importiert wird. Das Ergebnis sieht beim ersten Mal in einem Bericht seltsam aus: eine Familie, teils korrekt, teils ersetzt.

Wie ein Fallback tatsächlich aussieht, wenn er eintritt

Zwei verschiedene Arten von Fallback treten bei einem Import auf, und sie kommen aus unterschiedlichen Quellen. Die erste ist das Layout: ein Abschnitt, der sich nicht sauber auf Figmas auto layout abbilden lässt, fällt auf absolute, feste Positionierung zurück. Die zweite ist die Schrift: ein Textknoten, den UnHTML nicht gegen eine installierte Schrift oder eine Google Font auflösen kann, fällt auf Inter zurück, protokolliert im Importbericht.

Der Layout Fallback ist kein Browserkompatibilitätsproblem. Die Flexbox Unterstützung erreicht 98% der aktiv genutzten Browser, und Grid liegt bei 97,5%, praktisch universell bei beiden Spezifikationen. Fällt ein Abschnitt trotzdem beim Import auf absolute Position zurück, liegt die Ursache daran, wie das CSS dieses Abschnitts konkret geschrieben wurde: übermäßig verschachtelte Wrapper, gemischte Positionierungskontexte, oder ein Layout, das von JavaScript statt von CSS Regeln gesteuert wird, die UnHTML statisch lesen kann. Keine fehlende Funktion im Browser, der sie rendert.

Figma hat seinen eigenen, separaten Fallback, eine Ebene unterhalb der Schriftwechsel, die UnHTML protokolliert. Laut Figmas eigenem Engineering Blog löst Figma, wenn ein Zeichen in der aktiven Schrift keinen Glyphen hat, dieses einzelne Zeichen mit der Noto Schriftfamilie auf, konsistent über macOS, Windows und das Web hinweg, anstatt die plattformspezifischen Fallback Schriften zu verketten, die ein Browser verwenden würde. Das ist ein engerer, zeichenbasierter Fallback innerhalb von Figmas Renderer, getrennt von der Ersetzung auf Familienebene, die ein Importbericht protokolliert.

Deinen eigenen Importbericht lesen

Der Bericht, den ein Import erzeugt, ist der schnellste Weg, diese Durchschnittswerte in eine konkrete Antwort für eine konkrete Seite zu verwandeln. Drei Dinge lohnt es sich in dieser Reihenfolge zu prüfen: die Gesamtebenenanzahl gegen die 500 Ebenen Grenze des Gratis Tarifs, die Liste der ersetzten Schriftfamilien gegen das, was tatsächlich lokal installiert ist, und jeden Abschnitt, der als Fallback auf feste Position markiert ist, falls du ihn später neu gestalten willst.

Ein praktischer Weg durch einen Bericht mit mehreren Ersetzungen: zuerst die Liste durchgehen. Dann pro Familie entscheiden, ob es sich lohnt, die echte Schrift lokal als TTF oder OTF zu installieren und den Import erneut laufen zu lassen, oder Inter zu akzeptieren, weil die Datei ein schneller Entwurf ist und kein typografisch exakter Nachbau. UnHTML zeigt diesen Bericht automatisch bei jedem Import an, im Einklang mit der eigenen Datenschutzrichtlinie, alles lokal aufzulösen.

Was diese Zahlen zusammen bedeuten

Ebenenanzahl, Fallback Rate und Schriftersetzung gehen alle auf dieselbe Ursache zurück: wie das Markup, das CSS und die Schriften einer bestimmten Seite gebaut wurden. Eine schlanke, semantische Seite mit Google Fonts und saubaren Flex oder Grid Regeln bleibt unter dem Gratis Tarif und kommt mit intakter Typografie an. Eine div schwere Seite, gebaut mit selbst gehosteten WOFF2 Schriften und absolut positionierten Abschnitten, erreicht die Ebenengrenze, ersetzt mehrere Schriften und braucht einen zweiten Durchgang beim Layout.

Nichts davon ist vor dem Import sichtbar. Es wird sichtbar in dem Moment, in dem du den Bericht öffnest.