CSS umgestalten: Größe und Leistung optimieren (Teil 3)

In früheren Artikeln dieser Reihe haben wir uns mit der Prüfung des Zustands der CSS-Codebasis und der inkrementellen CSS-Refactoring-Strategie, dem Testen und der Wartung befasst. Unabhängig davon, wie sehr die CSS-Codebasis während des Refactoring-Prozesses verbessert wurde und wie viel besser wartbar und erweiterbar sie ist, muss das endgültige Stylesheet für die bestmögliche Leistung und die geringstmögliche Dateigröße optimiert werden.

Die Bereitstellung der umgestalteten Codebasis sollte nicht zu einer schlechteren Websiteleistung und einer schlechteren Benutzererfahrung führen. Schließlich müssen die Benutzer nicht ewig warten, bis die Website geladen ist. Außerdem wird das Management trotz der Verbesserungen der Codequalität mit dem durch die nicht optimierte Codebasis verursachten geringeren Datenverkehr und Umsatz unzufrieden sein.

In diesem Artikel werden wir CSS-Optimierungsstrategien behandeln, die CSS-Dateigröße, Ladezeiten und Renderleistung optimieren können. Auf diese Weise ist die umgestaltete CSS-Codebasis nicht nur besser wartbar und erweiterbar, sondern auch performant und erfüllt alle Anforderungen, die sowohl für den Endbenutzer als auch für das Management wichtig sind.

Optimieren der Stylesheet-Dateigröße

Die Optimierung der Dateigröße läuft darauf hinaus, unnötige Zeichen zu entfernen und den CSS-Code zu formatieren und zu optimieren, um unterschiedliche Syntax- oder Kurzschrifteigenschaften zu verwenden, um die Gesamtzahl der Zeichen in einer Datei zu reduzieren.

Optimierung und Minimierung

CSS-Optimierung und -Minifizierung gibt es schon seit Jahren und sind zu einem festen Bestandteil der Frontend-Optimierung geworden. Tools wie cssnano und clean-css gehören zu meinen Lieblingstools, wenn es um CSS-Optimierung und -Minifizierung geht. Sie bieten eine Vielzahl von Anpassungsoptionen, um weiter zu steuern, wie Code optimiert wird und welche Browser unterstützt werden.

Diese Tools funktionieren auf ähnliche Weise. Zunächst wird der nicht optimierte Code gemäß den in der Konfiguration festgelegten Regeln analysiert und transpiliert. Das Ergebnis ist ein Code, der weniger Zeichen verwendet, aber dennoch die Formatierung (Zeilenumbrüche und Leerzeichen) beibehält.

 /* Before - original and unoptimized code */ .container { padding: 24px 16px 24px 16px; background: #222222; } /* After - optimized code with formatting */ .container { padding: 24px 16px; background: #222; }

Und schließlich wird der transpilierte optimierte Code minimiert, indem alle unnötigen Textformatierungen entfernt werden . Abhängig von der Codebasis und den unterstützten Browsern, die in der Konfiguration festgelegt sind, kann auch Code mit veralteten Anbieterpräfixen entfernt werden.

 /* Before - optimized code with formatting */ .container { padding: 24px 16px; background: #222; } /* After - optimized and minified code */ .container{padding:24px 16px;background:#222}

Selbst in diesem einfachen Beispiel ist es uns gelungen, die Gesamtdateigröße von 76 Byte auf 55 Byte zu reduzieren, was zu einer Reduzierung von 23 % führt. Abhängig von der Codebasis und den Optimierungstools und -konfigurationen können CSS-Optimierung und -Minifizierung sogar noch effektiver sein.

CSS-Optimierung und -Minifizierung können aufgrund der erheblichen Auszahlung mit nur wenigen Änderungen am CSS-Workflow als einfacher Gewinn angesehen werden. Aus diesem Grund sollte die Minimierung als absolutes Minimum an Leistungsoptimierung und als Voraussetzung für alle Stylesheets im Projekt betrachtet werden.

Optimierung von Medienabfragen

Wenn wir Medienabfragen in CSS schreiben, insbesondere wenn mehrere Dateien (PostCSS oder Sass) verwendet werden, verschachteln wir den Code normalerweise nicht unter einer einzigen Medienabfrage für ein ganzes Projekt. Für eine verbesserte Wartbarkeit, Modularität und Codestruktur schreiben wir normalerweise dieselben Medienabfrageausdrücke für mehrere CSS-Komponenten.

Betrachten wir das folgende Beispiel einer nicht optimierten CSS-Codebasis.

 .page { display: grid; grid-gap: 16px; } @media (min-width: 768px) { .page { grid-template-columns: 268px auto; grid-gap: 24px; } } /* ... */ .products-grid { display: grid; grid-template-columns: repeat(2, 1fr); grid-gap: 16px; } @media (min-width: 768px) { .products-grid { grid-template-columns: repeat(3, 1fr); grid-gap: 20px; } }

Wie Sie sehen können, haben wir für eine bessere Lesbarkeit und Wartung ein wiederholtes @media (min-width: 768px) pro Komponente. Lassen Sie uns die Optimierung und Verkleinerung dieses Codebeispiels ausführen und sehen, was wir bekommen.

 .page{display:grid;grid-gap:16px}@media (min-width: 768px){.page{grid-template-columns:268px auto;grid-gap:24px}}.products-grid{display:grid;grid-template-columns:repeat(2,1fr);grid-gap:16px}@media (min-width: 768px){.products-grid{grid-template-columns:repeat(3,1fr);grid-gap:20px}}

Dies ist möglicherweise etwas schwierig zu lesen, aber alles, was wir bemerken müssen, ist die wiederholte @media (min-width: 768px) . Wir sind bereits zu dem Schluss gekommen, dass wir die Anzahl der Zeichen in einem Stylesheet reduzieren möchten und mehrere Selektoren unter einer einzigen Medienabfrage verschachteln können. Warum hat der Minifier den doppelten Ausdruck nicht entfernt? Das hat einen einfachen Grund.

Die Regelreihenfolge ist in CSS wichtig, daher müssen Codeblöcke verschoben werden, um die duplizierten Medienabfragen zusammenzuführen. Dies führt dazu, dass Regelreihenfolgen geändert werden, was zu unerwünschten Nebeneffekten in Stilen führen kann.

Das Kombinieren von Medienabfragen könnte die Dateigröße jedoch je nach Codebasis und Struktur möglicherweise sogar noch kleiner machen. Tools und Pakete wie postcss-sort-media-queries ermöglichen es uns, doppelte Medienabfragen zu entfernen und die Dateigröße weiter zu reduzieren.

Natürlich gibt es den wichtigen Vorbehalt, eine gut strukturierte CSS-Codebasisstruktur zu haben , die nicht von der Regelreihenfolge abhängt. Diese Optimierung sollte bei der Planung des CSS-Refaktors und der Festlegung von Grundregeln berücksichtigt werden.

Ich würde empfehlen, zunächst zu prüfen, ob der Optimierungsnutzen die potenziellen Risiken überwiegt. Dies lässt sich leicht bewerkstelligen, indem Sie ein CSS-Audit durchführen und die Statistiken der Medienabfragen überprüfen. Wenn dies der Fall ist, würde ich empfehlen, es später hinzuzufügen und automatisierte Regressionstests durchzuführen, um unerwartete Nebenwirkungen und Fehler zu erkennen, die dadurch auftreten können.

Nicht verwendetes CSS entfernen

Während des Refactoring-Prozesses besteht immer die Möglichkeit, dass Sie am Ende einige nicht verwendete Legacy-Stile haben, die nicht vollständig entfernt wurden, oder dass Sie einige neu hinzugefügte Stile haben, die nicht verwendet werden. Diese Stile erhöhen auch die Gesamtzeichenzahl und die Dateigröße. Das Eliminieren dieser ungenutzten Stile mit automatisierten Tools kann jedoch etwas riskant sein, da die Tools nicht genau vorhersagen können, welche Stile tatsächlich verwendet werden.

Tools wie purgecss gehen alle Dateien im Projekt durch und verwenden alle in Dateien erwähnten Klassen als Selektoren, nur um auf Nummer sicher zu gehen und nicht versehentlich Selektoren für dynamische, JavaScript-injizierte Elemente zu löschen, neben anderen möglichen Fällen. purgecss bietet jedoch flexible Konfigurationsoptionen als Workarounds für diese potenziellen Probleme und Risiken.

Diese Verbesserung sollte jedoch nur vorgenommen werden, wenn die potenziellen Vorteile die Risiken überwiegen . Darüber hinaus erfordert diese Optimierungstechnik viel Zeit zum Einrichten, Konfigurieren und Testen und kann später zu unbeabsichtigten Problemen führen. Gehen Sie also vorsichtig vor und stellen Sie sicher, dass das Setup absolut sicher ist.

Eliminieren von Render-blockierendem CSS

Standardmäßig ist CSS eine Renderblocking-Ressource, was bedeutet, dass die Website dem Benutzer erst angezeigt wird , wenn alle verknüpften Stylesheets und ihre Abhängigkeiten (z. B. Schriftarten) vom Browser heruntergeladen und geparst wurden.

Wenn die Stylesheet-Datei eine große Dateigröße oder mehrere Abhängigkeiten hat, die sich auf Servern von Drittanbietern oder CDNs befinden, kann das Rendern der Website je nach Netzwerkgeschwindigkeit und -zuverlässigkeit erheblich verzögert werden.

Largest Contentful Paint (LCP) ist in den letzten Monaten zu einer wichtigen Kennzahl geworden. LCP ist nicht nur wichtig für die Leistung, sondern auch für SEO – Websites mit besseren LCP-Werten haben ein besseres Ranking in den Suchergebnissen. Das Entfernen von Render-Blocking-Ressourcen wie CSS ist eine Möglichkeit, den LCP-Score zu verbessern.

Wenn wir jedoch das Laden und Verarbeiten des Stylesheets verschieben würden, würde dies zu Flash Of Unstyled Content (FOUC) führen – Inhalte würden dem Benutzer sofort angezeigt und Stile würden wenige Augenblicke später geladen und angewendet. Dieser Schalter könnte verwirrend aussehen und einige Benutzer sogar verwirren.

Kritisches CSS

Mit Critical CSS können wir sicherstellen, dass die Website mit der minimalen Anzahl von Stilen geladen wird, die garantiert auf der Seite verwendet werden, wenn sie zum ersten Mal gerendert wird. Auf diese Weise können wir den FOUC viel weniger auffällig machen oder ihn in den meisten Fällen sogar eliminieren. Wenn die Homepage beispielsweise eine Header-Komponente mit Navigation und eine Hero-Komponente enthält, die sich über der Falte befinden, bedeutet dies, dass das kritische CSS alle erforderlichen globalen und Komponentenstile für diese Komponenten enthält, während Stile für andere Komponenten auf der Seite vorhanden sind wird aufgeschoben.

Dieses CSS ist in HTML unter einem style -Tag eingebettet, sodass die Styles zusammen mit der HTML-Datei geladen und analysiert werden. Obwohl dies zu einer etwas größeren HTML -Dateigröße führt (die ebenfalls minimiert werden sollte), werden alle anderen nicht kritischen CSS zurückgestellt und nicht sofort geladen, und die Website wird schneller gerendert. Alles in allem überwiegen die Vorteile die Erhöhung der HTML-Dateigröße.

 <head> <style type="text/css"><!-- Minified Critical CSS markup --></style> </head>

Es gibt viele automatisierte Tools und NPM-Pakete, die abhängig von Ihrem Setup kritische CSS extrahieren und zurückgestellte Stylesheets generieren können.

Aufschieben von Stylesheets

Wie genau machen wir das CSS so, dass es nicht blockiert? Wir wissen, dass es nicht im HTML head Element referenziert werden sollte, wenn der HTML-Code der Seite zum ersten Mal heruntergeladen wird. Demian Renzulli hat diese Methode in seinem Artikel skizziert.

Es gibt (noch) keinen nativen HTML-Ansatz , um das Laden von Render-Blocking-Ressourcen zu optimieren oder zu verzögern, daher müssen wir JavaScript verwenden, um das unkritische Stylesheet nach dem anfänglichen Rendern in das HTML-Markup einzufügen. Wir müssen auch sicherstellen, dass diese Stile auf nicht optimale Weise (Rendering-Blockierung) geladen werden, wenn ein Benutzer die Seite besucht, während JavaScript im Browser nicht aktiviert ist.

 <!-- Deferred stylesheet --> <link rel="preload" as="style" href="path/to/stylesheet.css" onload="this.onload=null;this.rel='stylesheet'"> <!-- Fallback --> <noscript> <link rel="stylesheet" href="path/to/stylesheet.css"> </noscript>

Mit link rel="preload" as="style" dafür, dass die Stylesheet-Datei asynchron angefordert wird, während der JavaScript-Handler onload dafür sorgt, dass die Datei vom Browser geladen und verarbeitet wird, nachdem das HTML-Dokument fertig geladen ist. Eine gewisse Bereinigung ist erforderlich, daher müssen wir onload auf null setzen, um zu vermeiden, dass diese Funktion mehrmals ausgeführt wird und unnötige Neuberechnungen verursacht.

Genau so handhabt das Smashing Magazine seine Stylesheets. Jede Vorlage (Startseite, Artikelkategorien, Artikelseiten usw.) hat ein vorlagenspezifisches kritisches CSS , das innerhalb des HTML- style -Tags im head Element main.css - Stylesheet , das alle nicht kritischen Stile enthält.

Anstatt jedoch den rel -Parameter umzuschalten, sehen wir hier, dass die Medienabfrage von den automatisch zurückgestellten print mit niedriger Priorität auf das all -Attribut mit hoher Priorität umgeschaltet wird, wenn die Seite fertig geladen ist. Dies ist ein alternativer, ebenso praktikabler Ansatz, um das Laden von unkritischen Stylesheets aufzuschieben.

 <link href="/css/main.css" media="print" onload="this.media='all'" rel="stylesheet">

Aufteilen und bedingtes Laden von Stylesheets mit Medienabfragen

Für die Fälle, in denen die endgültige Stylesheet-Datei auch nach Anwendung der oben genannten Optimierungen eine große Dateigröße aufweist, könnten Sie die Stylesheets basierend auf Medienabfragen in mehrere Dateien aufteilen und die Medieneigenschaft für Stylesheets verwenden, auf die im Link-HTML-Element verwiesen wird, um sie bedingt zu laden .

 <link href="print.css" rel="stylesheet" media="print"> <link href="mobile.css" rel="stylesheet" media="all"> <link href="tablet.css" rel="stylesheet" media="screen and (min-width: 768px)"> <link href="desktop.css" rel="stylesheet" media="screen and (min-width: 1366px)">

Auf diese Weise werden bei Verwendung eines Mobile-First-Ansatzes Stile für größere Bildschirmgrößen nicht auf Mobilgeräte heruntergeladen oder analysiert, die möglicherweise in langsameren oder unzuverlässigen Netzwerken ausgeführt werden.

Nur um es noch einmal zu wiederholen, diese Methode sollte verwendet werden, wenn das Ergebnis der zuvor erwähnten Optimierungsmethoden zu einem Stylesheet mit suboptimaler Dateigröße führt. In normalen Fällen ist diese Optimierungsmethode je nach Größe des einzelnen Stylesheets nicht so effektiv oder wirkungsvoll.

Aufschieben von Schriftdateien und Stylesheets

Das Zurückstellen von Schriftart-Stylesheets (z. B. Google Font-Dateien) könnte auch für die anfängliche Renderleistung von Vorteil sein. Wir sind zu dem Schluss gekommen, dass Stylesheets Renderblocker sind, aber das gilt auch für die Schriftartdateien, auf die im Stylesheet verwiesen wird. Schriftdateien erhöhen auch die anfängliche Renderleistung erheblich.

Das Laden von Schriftart-Stylesheets und Schriftartdateien ist ein komplexes Thema, und es würde einen ganzen neuen Artikel erfordern, nur um alle praktikablen Ansätze zu erklären. Glücklicherweise hat Zach Leatherman in diesem großartigen umfassenden Leitfaden viele praktikable Strategien skizziert und die Vor- und Nachteile jedes Ansatzes zusammengefasst. Wenn Sie Google Fonts verwenden, hat Harry Roberts eine Strategie für das schnellste Laden von Google Fonts skizziert.

Wenn Sie sich entscheiden, Schriftart-Stylesheets zurückzustellen, landen Sie bei Flash of Unstyled Text (FOUT). Die Seite wird zunächst mit der Fallback-Schriftart gerendert, bis die zurückgestellten Schriftartdateien und Stylesheets heruntergeladen und analysiert wurden, woraufhin die neuen Stile angewendet werden. Diese Änderung kann sehr auffällig sein und je nach Einzelfall Layoutverschiebungen verursachen und Benutzer verwirren.

Barry Pollard hat einige Strategien skizziert, die uns beim Umgang mit FOUT helfen können, und über die kommende CSS-Funktion zur Größenanpassung gesprochen, die einen einfacheren, nativeren Umgang mit FOUT bieten wird.

Serverseitige Optimierungen

HTTP-Komprimierung

Zusätzlich zur Minimierung und Optimierung der Dateigröße können statische Assets wie HTML, CSS-Dateien, JavaScript-Dateien usw. verwendet werden. HTTP-Komprimierungsalgorithmen wie Gzip und Brotli können verwendet werden, um die heruntergeladene Dateigröße zusätzlich zu reduzieren.

Die HTTP-Komprimierung muss auf dem Server konfiguriert werden, was vom Tech-Stack und der Konfiguration abhängt. Die Leistungsvorteile können jedoch variieren und haben möglicherweise nicht so viel Einfluss wie die standardmäßige Stylesheet-Minifizierung und -Optimierung, da die Browser die komprimierten Dateien immer noch dekomprimieren und sie analysieren müssen.

Zwischenspeichern von Stylesheets

Das Zwischenspeichern statischer Dateien ist eine nützliche Optimierungsstrategie. Browser müssen die statischen Dateien beim ersten Laden immer noch vom Server herunterladen, aber sobald sie zwischengespeichert sind, werden sie bei nachfolgenden Anfragen direkt von ihm geladen, was den Ladevorgang beschleunigt.

Das Caching kann über den Cache-Control-HTTP-Header auf Serverebene gesteuert werden (z. B. mithilfe der .htaccess -Datei auf einem Apache-Server).

Mit max-age können wir angeben, wie lange die Datei im Browser zwischengespeichert werden soll (in Sekunden), und mit public geben wir an, dass die Datei vom Browser und anderen Caches zwischengespeichert werden kann.

 Cache-Control: public, max-age=604800

Eine aggressivere und effektivere Cache-Strategie für statische Assets kann mit einer immutable Konfiguration erreicht werden. Dadurch wird dem Browser mitgeteilt, dass sich diese bestimmte Datei nie ändern wird und dass alle neuen Updates dazu führen, dass diese Datei gelöscht wird und eine neue Datei mit einem anderen Dateinamen an ihre Stelle tritt. Dies wird als Cache-Busting bezeichnet.

 Cache-Control: public, max-age=604800, immutable

Ohne eine geeignete Cache-Busting-Strategie besteht die Gefahr, die Kontrolle über Dateien zu verlieren, die im Browser des Benutzers zwischengespeichert werden. Das heißt, wenn sich die Datei ändert, kann der Browser nicht wissen, dass er die aktualisierte Datei herunterladen und nicht die veraltete zwischengespeicherte Datei verwenden soll. Und von diesem Zeitpunkt an können wir praktisch nichts mehr tun, um das zu beheben, und der Benutzer bleibt an der veralteten Datei hängen, bis sie abläuft.

Für Stylesheets könnte dies bedeuten, dass diese Stile nicht angezeigt werden, wenn wir HTML-Dateien mit neuen Inhalten und Komponenten aktualisieren, die ein neues Design erfordern, da das veraltete Stylesheet ohne Cache-Busting-Strategie zwischengespeichert wird und der Browser dies nicht weiß es muss die neue Datei herunterladen.

Bevor Sie eine Caching-Strategie für Stylesheets oder andere statische Dateien verwenden, sollten effektive Cache-Busting-Mechanismen implementiert werden, um zu verhindern, dass veraltete statische Dateien im Cache des Benutzers hängen bleiben. Sie können einen der folgenden Versionierungsmechanismen für das Cache-Busting verwenden:

• Anhängen einer Abfragezeichenfolge an den Dateinamen.
  Zum Beispiel styles.css?v=1.0.1. Einige CDNs können die Abfragezeichenfolge jedoch vollständig ignorieren oder aus dem Dateinamen entfernen, was dazu führt, dass die Datei im Cache des Benutzers hängen bleibt und nie aktualisiert wird.
• Ändern des Dateinamens oder Anhängen eines Hashs.
  Zum Beispiel styles.a1bc2.css oder styles.v1.0.1.css. Dies ist zuverlässiger und effektiver als das Anhängen einer Abfragezeichenfolge an den Dateinamen.

CDN oder Selbsthoster?

Content Delivery Network (CDN) ist eine Gruppe geografisch verteilter Server, die häufig für die zuverlässige und schnelle Bereitstellung statischer Assets wie Bilder, Videos, HTML-Dateien, CSS-Dateien, JavaScript-Dateien usw. verwendet werden.

Obwohl CDNs wie eine großartige Alternative zu selbst gehosteten statischen Assets erscheinen mögen, hat Harry Roberts gründliche Nachforschungen zu diesem Thema angestellt und ist zu dem Schluss gekommen, dass selbst gehostete Assets für die Leistung vorteilhafter sind.

„Es gibt wirklich kaum einen Grund, Ihre statischen Assets in der Infrastruktur anderer zu belassen. Die wahrgenommenen Vorteile sind oft ein Mythos, und selbst wenn sie es nicht wären, sind die Kompromisse es einfach nicht wert. Das Laden von Assets aus mehreren Quellen ist nachweislich langsamer.“

Davon abgesehen würde ich empfehlen , die Stylesheets standardmäßig selbst zu hosten (einschließlich Schriftart-Stylesheets, wenn möglich) und nur dann zu CDN zu wechseln, wenn es stichhaltige Gründe oder andere Vorteile dafür gibt.

Prüfung der Größe und Leistung von CSS-Dateien

WebPageTest und andere ähnliche Tools zur Leistungsprüfung können verwendet werden, um einen detaillierten Überblick über den Ladevorgang der Website, Dateigrößen, Render-Blocking-Ressourcen usw. zu erhalten. Diese Tools können Ihnen einen Einblick geben, wie Ihre Website auf einer Vielzahl von Geräten geladen wird — von einem Desktop-PC, der in einem Hochgeschwindigkeitsnetzwerk läuft, bis hin zu Low-End-Smartphones, die in langsamen und unzuverlässigen Netzwerken laufen.

Lassen Sie uns eine Leistungsprüfung auf einer Website durchführen, die im ersten Artikel dieser Serie erwähnt wird – die mit den 2 MB an minimiertem CSS.

Zuerst werfen wir einen Blick auf die Inhaltsaufschlüsselung , um festzustellen, welche Ressourcen die meiste Bandbreite beanspruchen. Aus den folgenden Diagrammen können wir ersehen, dass die Bilder die meisten Anfragen aufnehmen, was bedeutet, dass sie verzögert geladen werden müssen. Aus dem zweiten Diagramm können wir ersehen, dass Stylesheets und JavaScript-Dateien in Bezug auf die Dateigröße am größten sind. Dies ist ein guter Hinweis darauf, dass diese Dateien entweder minimiert und optimiert, umgestaltet oder in mehrere Dateien aufgeteilt und asynchron geladen werden müssen.

Noch mehr Schlüsse können wir aus den Web Vitals Charts ziehen. Indem wir einen Blick auf das Largest Contentful Paint (LCP)-Diagramm werfen, können wir uns einen detaillierten Überblick über Render-Blocking-Ressourcen verschaffen und wie stark sie das anfängliche Rendern beeinflussen.

Wir konnten bereits schlussfolgern, dass das Website -Stylesheet den größten Einfluss auf die LCP- und Ladestatistiken haben wird . Wir können jedoch Schriftart-Stylesheets, JavaScript-Dateien und Bilder sehen, auf die in den Stylesheets verwiesen wird, die ebenfalls renderblockierend sind. In dem Wissen, dass wir die oben genannten Optimierungsmethoden anwenden können, um die LCP-Zeit zu reduzieren, indem Render-Blocking-Ressourcen eliminiert werden.

Fazit

Der Refactoring-Prozess ist nicht abgeschlossen, wenn der Zustand und die Qualität des Codes verbessert und Schwächen und Probleme der Codebasis behoben wurden. Die umgestaltete Codebasis sollte im Vergleich zur Legacy-Codebasis zu derselben oder einer verbesserten Leistung führen.

Endbenutzer sollten keine Leistungsprobleme oder langen Ladezeiten von der umgestalteten Codebasis erfahren. Glücklicherweise gibt es viele Methoden, um sicherzustellen, dass die Codebasen sowohl robust als auch leistungsfähig sind – von einfachen Minimierungs- und Optimierungsmethoden bis hin zu komplexeren Methoden wie der Eliminierung von Render-Blocking-Ressourcen und Code-Splitting.

Wir können verschiedene Performance-Audit-Tools wie WebPageTest verwenden , um einen detaillierten Überblick über Ladezeiten, Leistung, Render-Blocking-Ressourcen und andere Faktoren zu erhalten, damit wir diese Probleme frühzeitig und effektiv angehen können.

Verweise

• „Renderblockierendes CSS“, Ilya Grigorik
• „Verzögern Sie unkritisches CSS“, Demian Renzulli
• „Ein umfassender Leitfaden für Strategien zum Laden von Schriftarten“, Zach Leatherman
• „Ein neuer Weg, um die Auswirkung beim Laden von Schriftarten zu reduzieren: CSS-Schriftdeskriptoren“, Barry Pollard
• „Hosten Sie Ihre statischen Assets selbst“, Harry Roberts
• „Optimieren Sie das Laden und Rendern von WebFonts“, Ilya Grigorik