Neulich fiel mir auf, dass Web-Performance ein riesiges Thema ist, das sehr viel umfasst – von der Minimierung von Assets bis zur Verwendung bestimmter Dateiformate. Es kann eine ganze Menge sein, das man beim Erstellen einer Website im Hinterkopf behalten muss. Für mich ist es sicherlich viel zu viel, um es sich zu merken!
Also habe ich eine Web-Performance-Checkliste erstellt. Es ist ein Notion-Dokument, das ich forken und zum Abhaken von erledigten Elementen verwenden kann, wann immer ich ein neues Projekt beginne. Es enthält auch eine Reihe von Links als Referenzen.
Dieses Dokument ist noch in Arbeit. Irgendwelche Empfehlungen oder Links? Fühlen Sie sich frei, etwas in den Kommentaren unten vorzuschlagen!
Tolle Liste! Danke fürs Teilen! Habe gerade bemerkt: Meinten Sie vielleicht „transform“ statt „position“ in „vermeiden Sie Animationen von Stilen außer:“?
Web-Performance ist heutzutage ein so komplexes Thema mit so vielen zu berücksichtigenden Aspekten, dass es eine interessante Herausforderung ist, es in etwas mehr als 30 Stichpunkten abzudecken.
Wenn es jedoch nur eine Sache gäbe, die man hinzufügen sollte, würde ich empfehlen, die Optimierung der HTML-Performance und die Entfernung optionaler Markup-Elemente für die Produktion einzubeziehen (optionale Tags, unnötige Anführungszeichen, ebenso keine Attribut-Wert-Paare, die sich auf Standardwerte beziehen). Ich habe an einer Stelle einen Überblick gegeben, es gibt aber möglicherweise andere Dokumente, die auch die notwendigen Details liefern könnten.
Da es hier um CSS geht, würden Sie etwas über Skalierbarkeit oder alternative Bilder für verschiedene Bildschirmgrößen hinzufügen?
Danke für das Teilen der Web-Performance-Checkliste. Wahrscheinlich ist dies eine sehr wichtige Checkliste, die jeder Entwickler regelmäßig überprüfen muss. Selbst wenn Sie die Ladezeit um 1 Sekunde reduzieren können. Es hat einen enormen Einfluss auf den ersten Eindruck des Besuchers.
Uhh, sieht gut aus! Wenn möglich, würde ich auf den OpenLiteSpeed Webserver umsteigen. Mit LiteSpeed ist fast alles von den oben genannten Punkten enthalten.
Entfernen Sie ungenutztes CSS. Das passiert immer. Wir fügen neue Komponenten hinzu oder entfernen alte, wir ändern etwas, aber wir berühren das CSS nicht. Nach einiger Zeit beginnen die CSS-Dateien an Gewicht zuzunehmen, und dieses Gewicht schlägt sich in langsamen Ladezeiten nieder.
Verwenden Sie, wenn möglich, auch WebM-Videos (weiß aber nicht genau, ob diese von modernen Browsern vollständig unterstützt werden).
Platzieren Sie CSS- und JS-Verknüpfungen/Importe an der richtigen Stelle. Vermischen Sie sie nicht, sonst könnten Sie am Ende ein seltsames Layout haben.
Das ist eine fantastische Checkliste, ich arbeite auch daran!
Ein weiteres Tool, das ich zum Testen mag, ist https://tools.pingdom.com/
Jede Programmiersprache hat auch Best Practices in Bezug auf die Optimierung, zum Beispiel müssen wir für CSS effiziente Selektoren verwenden, in PHP und SQL müssen wir effiziente Datenbankabfragen durchführen und in allen Sprachen müssen wir Redundanzen vermeiden. 3 interessante Ressourcen unten
https://10up.github.io/Engineering-Best-Practices/css/#performance
https://10up.github.io/Engineering-Best-Practices/javascript/#performance
https://10up.github.io/Engineering-Best-Practices/php/#performance
Assets zu verketten ist immer noch eine gute Praxis zur Verbesserung des PageSpeed-Scores, aber ich weiß nicht, wie nützlich es tatsächlich mit HTTP/2 und parallelen Anfragen ist. Zum Beispiel ist es nicht gut, wenn die einzige .css- und .js-Datei im Kopfbereich steht. Am besten wäre es, diese Dateien im Footer zu platzieren und nur das kritische CSS im Kopfbereich.
Offensichtlich wäre das Beste, nur das CSS und den JavaScript, der auf jeder Seite verwendet wird, auch auf dieser Seite zu laden. Offensichtlich, aber nicht so einfach, wenn wir mit CMS wie WordPress und vielen Plugins arbeiten! In WordPress gibt es zum Beispiel spezifische Funktionen und Bedingungen, um Stile und Skripte auf verschiedenen Seiten, Archiven oder Beiträgen zu registrieren/deregistrieren, nur dort, wo wir sie benötigen.
Ich weiß, dass die Checkliste versucht, für alle Fälle zu gelten, und ich weiß, dass es vielleicht umstritten ist, aber wenn ich HTTP/2 verwende, werde ich nicht eilig alle meine HTTP-Aufrufe reduzieren und alle meine Dateien verketten. Das kann zu großen einzelnen Dateien führen, die das CSS/JS für Komponenten enthalten, die auf meiner aktuellen Seite nicht verwendet werden. Da HTTP/2 Multiplexing die begrenzte Anzahl von Verbindungen besser nutzt, ist es möglicherweise schneller, nur die mehreren einzelnen Skripte/Dateien abzurufen, die tatsächlich für Ihre Seite benötigt werden.
Es ist es wert, getestet zu werden, und es hängt sehr stark davon ab, wie viele Komponenten Ihr System insgesamt verwendet im Vergleich zu denen, die für eine einzelne Seite benötigt werden. Ich habe bei sehr großen Systemen einen Geschwindigkeitsvorteil festgestellt, und ich habe kleinere Websites gesehen, die mit verketteten CSS/JS-Dateien schneller waren.
Ich würde auch die Liste „Asynchrones Laden von JavaScript“ (das kein rendern blockierendes Skript ist) hinzufügen und den „Preconnect“-Ressourcenhinweis zum Öffnen von Verbindungen zu anderen Domains verwenden. Viele unserer Kunden verwenden GTM, um nach dem Laden der Seite unzählige Analyse-Skripte hinzuzufügen, und die Möglichkeit, die TLS-Verbindung bereitzuhaben, bevor GTM die Skripte anfordert, kann Hunderte von Millisekunden sparen.
In einem ähnlichen Zusammenhang kann ich „Vermeiden Sie mehrere Analyse-Skripte“ nicht genug betonen! Viele Leistungsprobleme unserer Kunden lassen sich auf GTM zurückführen, das unzählige Analyse-Skripte lädt...