Warum nicht Stile / Skripte in HTML einbetten anstatt zu verlinken?

Wir verknüpfen CSS- und JavaScript-Dateien, um die Anzahl der HTTP-Anforderungen zu verringern und die Leistung zu verbessern. Das Ergebnis ist HTML wie folgt:

<link rel="stylesheet" href="all-my-css-0fn392nf.min.css">
<!-- later... -->
<script src="all-my-js-0fn392nf.min.js"></script>

Wenn wir Server-seitige / Build-Logik haben, um all dies für uns zu erledigen, warum nicht noch einen Schritt weiter gehen und diese verketteten Stile und Skripte in HTML einbetten?

<style>.all{width:100%;}.my{display:none;}.css{color:white;}</style>
<!-- later... -->
<script>var all, my, js;</script>

Das sind zwei HTTP-Anfragen weniger, aber ich habe diese Technik in der Praxis nicht gesehen. Warum nicht?

Da das Speichern von HTTP-Anforderungen wenig hilfreich ist, wenn Sie das Caching unterbrechen. Wenn die Stylesheets und Skripte separat bereitgestellt werden, können sie sehr gut zwischengespeichert und über viele, viele Anfragen auf ganz andere Seiten amortisiert werden. Wenn sie auf derselben HTML-Seite gespeichert sind, müssen sie bei jeder erneut übertragen werden. Single. Anfrage.

Der HTML-Code dieser Seite ist derzeit beispielsweise 13 KB groß. Die 180 KB CSS wurden im Cache abgelegt, ebenso die 360 ​​KB JS. Beide Cache-Zugriffe nahmen nur wenige Zeit in Anspruch und verbrauchten praktisch keine Bandbreite. Schalten Sie den Netzwerk-Profiler Ihres Browsers aus und probieren Sie ihn auf einigen anderen Websites aus.

Einfach, weil die Webleistung wirklich zählt! 99% ige Reaktionszeit für Endbenutzer.

Hier sind einige Beispiele von Velocity Conf.

• Bing - Eine Seite, die 2 Sekunden langsamer war, führte zu einem Rückgang der Einnahmen / Nutzer um 4,3%.
• Google - Eine Verzögerung von 400 Millisekunden verursachte einen Rückgang der Suchanfragen / Nutzer um 0,59%.
• Yahoo ! - Eine Verlangsamung von 400 Millisekunden führte zu einem Rückgang des gesamten Seitenverkehrs um 5-9%.
• Shopzilla - Durch die Beschleunigung der Website um 5 Sekunden wurde die Conversion-Rate um 7-12% erhöht, die Anzahl der Sitzungen aus dem Suchmaschinen-Marketing verdoppelt und die Anzahl der erforderlichen Server halbiert.
• Durch Mozilla - Shaving 2,2 Sekunden vor ihrer Landingpage stiegen die Download-Conversions um 15,4%, was nach ihrer Schätzung zu 60 Millionen weiteren Firefox-Downloads pro Jahr führen wird.
• Netflix - Die Einführung einer einzigen Optimierung, der GZIP-Komprimierung, führte zu einer Beschleunigung von 13 bis 25% und einer Reduzierung des ausgehenden Netzwerkverkehrs um 50%.

Von Steve Souders, Pionier in der Optimierung der Webleistung,

80-90% der Antwortzeit des Endbenutzers wird für das Frontend aufgewendet. Beginnen Sie hier zuerst.

Die Verwendung externer Dateien führt zu schnelleren Seiten, da die JavaScript- und CSS-Dateien vom Browser / Netzwerk / Proxy zwischengespeichert werden (wie im HTTP-Protokoll mit Cache-Headern definiert). JavaScript und CSS, die in HTML-Dokumenten eingebettet sind, werden bei jeder Anforderung des HTML-Dokuments heruntergeladen. Dies reduziert die Anzahl der erforderlichen HTTP-Anforderungen, erhöht jedoch die Größe des HTML-Dokuments. Wenn Sie Jquery-ähnliche Skripte verwenden, können Sie problemlos 300 KB an Skripten aktualisieren und glauben nicht, dass alle eine Bandbreite von 100 MBit / s mit geringer Latenz haben und eine einzige Anwendung ausführen - den Browser -, der auf Ihrer Website geöffnet ist. 99% ige Reaktionszeit für Endbenutzer.

Die Häufigkeit, mit der externe JavaScript- und CSS-Komponenten im Verhältnis zur Anzahl der angeforderten HTML-Dokumente zwischengespeichert werden, ist ebenfalls wichtig. Wenn Benutzer auf Ihrer Website mehrere Seitenaufrufe pro Sitzung haben und viele Ihrer Seiten dieselben Skripte und Stylesheets (Bundles) wiederverwenden, ist der potenzielle Nutzen von zwischengespeicherten externen Dateien größer.

Inlining ist jedoch manchmal für Einzelseitenanwendungen oder Websites mit einer einzelnen Seitenansicht pro Sitzung vorzuziehen. Es gibt keine goldene Regel, und vergessen Sie sie im Allgemeinen, da es sich hauptsächlich um sehr spezifische Websites handelt, die wirklich von der Leistung der Endbenutzer betroffen sind.

Hier können Sie nachlesen , warum es auf die Leistung ankommt (Haftungsausschluss: Ich bin der Autor)

Die neueste Version von HTTP wurde vor langer Zeit im Jahr 1999 erstellt. Im Jahr 1999 stellten alle Benutzer eine DFÜ-Verbindung zum Internet her. Das Internet war sehr langsam. 16 Jahre später hat sich viel getan, aber die Protokolle, die wir verwenden, haben es nicht getan.

Die Antworten, die wir nicht ankreuzen sollten, weil sie das Caching stören, sind etwas irreführend, insbesondere im Zeitalter des superschnellen Internets. Wenn Sie die Berechnungen tatsächlich durchführen, gibt es häufig einen vernachlässigbaren Unterschied zwischen den Ladezeiten bei Benutzern mit warmem und kaltem Cache, sofern Sie dies angegeben haben. Die Tatsache , dass es ist ein kleiner Unterschied ist nicht von Natur aus, weil Sie inlined haben, aber wegen der unflexiblen Gestaltung von HTTP / 1.1.

Das SPDY-Protokoll implementiert einen sogenannten Server-Push . Dies nimmt im Wesentlichen das Inlining aus dem HTML-Dokument selbst und in das Protokoll vor. Ein intelligenter Server weiß, über welche Ressourcen der Client bereits verfügt. Ein dummer Server sendet einfach alles, unabhängig davon - das ist immer noch ein Leistungsvorteil, kann aber in Bezug auf die Bandbreite Kosten verursachen. Wenn der Browser den Inhalt in seinem Cache hat, kann er die eingehenden Kopien einfach verwerfen. Der Server wartet, bis der HTML-Code geladen ist, bevor er die zusätzlichen Ressourcen sendet - theoretisch kann der Browser ein Signal senden, um den Server-Push abzubrechen.

HTTP / 2.0 basiert auf SPDY und wird höchstwahrscheinlich Server-Push implementieren. Theoretisch können Sie SPDY heute verwenden. Der wahre Grund, warum wir keine Inline-Protokolle verwenden, liegt in der Vergangenheit - die derzeit vorhandenen Protokolle sind alt und nicht flexibel genug, um Inlining auf Protokollebene zu erreichen.

Zusätzlich zu den Problemen beim Zwischenspeichern und Abrufen, die die anderen Antworten aufwerfen, möchte ich ein weiteres, dunkleres Problem hervorheben: das Parsen .

In HTML angezeigtes JavaScript kann zu Analyseproblemen führen, wie im folgenden Beispiel:

<html>
<head>
<script>
function myfunc() {
    if ("</style> isn't a problem")
        return "but </script> is"
}
</script>
<style>
body::after {
  content: '</script> is okay, but not </style>'
}
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

... was bedeutet, dass Sie Ihr Skript transformieren müssen, um einige Zeichen zu umgehen, die in HTML ausgelöst werden. Dieses Problem tritt nicht mehr auf, wenn Sie CSS und JavaScript als externe Ressourcen bereitstellen, da diese den übergeordneten Analysekontext nicht mehr berücksichtigen müssen.

Wenn Sie Ihre Inhalte als XML bereitstellen, können Sie dies teilweise mithilfe von CDATA-Abschnitten umgehen. CDATA hat jedoch ein ähnliches Problem:

<?xml version="1.0" encoding="utf-8"?>
<html>
<head>
<script>
// <![CDATA[
function myfunc() {
    if ("</script> is no longer a problem")
        return "but ]]> is"
}
// ]]>
</script>
<style>
<![CDATA[
body::after {
  content: 'same ]]> issue here'
}
]]>
</style>
</head>
<body>
<script>document.write(myfunc())</script>
</body>
</html>

Inliner aufgepasst.

Die Trennung des Inhalts von der Gestaltung seiner Präsentation ist normalerweise ein größerer Vorteil als weniger http-Anforderungen.

Durch die Trennung des gesamten Stils werden die Wiederverwendung und gemeinsame Nutzung von Dateien ermöglicht und gefördert.

Der Inhalt der Dateien ist außerdem statischer und kann auf Servern und Clients sowohl für diese als auch für andere besuchte Seiten zwischengespeichert werden.

Auf Ihre spezielle Frage ... Wenn der Server die Minimierung selbst durchführt, sind die Assets schwieriger zu warten und Probleme zu beheben. Viele Frameworks tun dies jetzt jedoch auf Dateiebene, z. B. alle cs und alle js. Zum Beispiel minimiert das Ruby on Rails-Framework jetzt seine Produktionsressourcen. 5 bis 10 zusätzliche HTTP-Anforderungen sind normalerweise nicht der Engpass. Wenn mehr als 100 HTTP-Anforderungen vorliegen (die Sie häufig mit Bildern erhalten), ist dies die häufigere Ursache.

Der zusätzliche Schritt des tatsächlichen Einfügens des Codes in die Seiten selbst hätte den Nachteil, dass größere Seiten die Downloadsequenz sorgfältig verwalten müssten und die Seite ohne den Rest der (jetzt großen) Seite häufig keinen Inhalt anzeigen kann wird heruntergeladen.

1. Doppelte Codierung minimieren. um Zeit zu sparen (Sie können den Stil und die JS-Funktion, die für eine Seite codiert sind, wiederverwenden).
2. Änderungsaufwand minimieren. (Wenn Ihr Kunde Sie auffordert, die Farbe der Schaltflächen auf der Website zu ändern, müssen Sie eine Seite nach der anderen wechseln.)
3. Reduzieren Sie die Ladezeit (Wenn Ihr CSS und Ihr JS doppelt vorhanden sind, bedeutet dies, dass die Größe der einzelnen Seiten zunimmt und das Herunterladen viel Zeit in Anspruch nimmt. Häufig verwendete CSS-JSs müssen jedoch nicht immer wieder heruntergeladen werden).
4. Remote-Nutzung. (Sie können Ihr gemeinsames CSS js JS an einem entfernten Ort ablegen, nicht auf demselben gehosteten Server.)
5. Reduzieren Sie die Fehlerbehebungszeit. Wenn es einen Fehler in einer Funktion gibt, müssen Sie Seite für Seite gehen, um die Fehler in eingebettetem JS und CSS zu beheben.
6. SEO steigern (Inhalte einfach mit Metadaten trennen)
7. Sauberer und verständlicher Code (Wenn Sie alles in eine Datei einbetten, ist das Debuggen und die Klarheit des Codes verschwunden. Jede Seite ist sehr lang.)
8. Darüber hinaus können Sie auf diese Weise die Größe des Produkts reduzieren.
9. Sie können aber dennoch in Betracht ziehen, die meisten einzigartigen Elemente in dieselbe Seite einzubetten.

Wir sollten keine Stile / Skripte in HTML einbetten, weil

Eingebettete Stile / Skripte müssen bei jeder Seitenanforderung heruntergeladen werden:

Diese Stile können vom Browser nicht zwischengespeichert und für eine andere Seite wiederverwendet werden. Aus diesem Grund wird empfohlen, möglichst wenig CSS / JS einzubetten.

Stattdessen verwenden wir "Linking Coz", wenn wir "Linking" zum Binden von CSS / Skripten verwenden

Die Geschwindigkeit der Site erhöht sich für mehrere Seitenanforderungen:

Wenn eine Person Ihre Website zum ersten Mal besucht, lädt ihr Browser den HTML-Code der aktuellen Seite sowie die verknüpfte CSS- und JS-Datei herunter. Wenn sie zu einer anderen Seite navigieren, muss ihr Browser nur den HTML-Code der neuen Seite herunterladen. Die CSS / JS-Datei wird zwischengespeichert und muss nicht erneut heruntergeladen werden. Dies kann einen großen Unterschied machen, insbesondere wenn Sie eine große Stil- und Skriptdatei haben.