Statische Website-Verarbeitung – CSI

CSI ist eine browserseitige dynamische und statische Integrationslösung. Nachdem mein Artikel veröffentlicht wurde, fragte mich ein Freund, ob die CSI-Technologie Daten über Ajax laden soll. Was genau ist das denn? Ist es CSI-Technologie? Dies muss tatsächlich aus der Perspektive der Integration dynamischer und statischer Ressourcen definiert werden.

Die CSI-Technologie unterteilt das Laden der Seite tatsächlich in zwei Schritte, nachdem die Seite von statischen Ressourcen getrennt wurde. Der erste Schritt besteht darin, statische Ressourcen zu laden. Diese Definition ist jedoch noch unvollständig. Der unvollständige Teil besteht darin, dass wir den Zweck der Trennung dynamischer und statischer Ressourcen auf der Seite betonen müssen. Diese statische Ressource kann sich in einem statischen Web befinden Auf der Seite kann es sich um ein CDN oder einen Browser handeln. Unabhängig davon, wie die statischen Ressourcen zwischengespeichert werden, besteht unser Zweck darin, das Laden statischer Ressourcen zu beschleunigen Ressourcen werden effizient. Selbst wenn wir das CSI-Formular zum Entwerfen der Seite verwenden, nutzen wir tatsächlich nicht die Vorteile von CSI, sondern führen versehentlich die Mängel von CSI ein. Was sind also die Nachteile von CSI? Die Einzelheiten lauten wie folgt:

Nachteil 1 von CSI: CSI ist der SEO der Seite, also der Suchmaschinenoptimierung, nicht förderlich. Suchmaschinen-Webcrawler greifen im Allgemeinen anhand der URL auf die Seite zu, rufen den Inhalt der Seite ab, entfernen nutzlose Informationen wie CSS-Stile und JS-Skripte und analysieren dann den verbleibenden Textinhalt, wenn ein Teil des Seiteninhalts benötigt wird asynchron geladen, dann Diese Ladesteuerung muss durch JavaScript-Code abgeschlossen werden, sodass asynchrone Ladevorgänge nicht auf Seiten ausgeführt werden können, die von Webcrawlern nach unten gecrawlt werden (ich habe gehört, dass einige fortgeschrittene Crawler asynchrone Vorgänge ausführen und asynchrone Inhalte erfassen können, selbst wenn dies der Fall ist). Technologie ignorieren die meisten Mainstream-Crawler immer noch JavaScript-Code und asynchron geladene Inhalte), was dazu führt, dass einige Informationen auf den vom Crawler gecrawlten Seiten verloren gehen, sodass CSI nicht sehr SEO-freundlich ist. Wenn wir diesen Mangel jedoch sorgfältig analysieren, ist er möglicherweise nicht so schwerwiegend. Wir haben zuvor über viele statische Trennungsstrategien gesprochen. Wenn wir bei dynamischen und statischen Trennungsstrategien gute Arbeit leisten, handelt es sich im Grunde genommen um Inhalte, die nicht zwischengespeichert werden können Der Inhalt dieser Änderungen muss nicht von Webcrawlern gecrawlt werden. Auch wenn er gecrawlt wird, weist die Suchmaschine auf diese Seite hin Auf der Seite Keywords glaube ich, dass viele Freunde bei der Verwendung von Suchmaschinen auf diese Situation stoßen werden. Ich denke jedoch, dass Entwickler diesen Bereich möglicherweise nicht besonders gut beherrschen, wenn sie CSI nicht richtig verwenden, sodass dieser Mangel immer noch leicht eingeführt werden kann.

Nachteil 2 von CSI: Wir verbringen so viel Zeit und Mühe damit, unsere Website statisch zu machen. Der Zweck besteht darin, das Laden der Seite einfach in zwei Schritte aufzuteilen wirklich schnell? Dies ist nicht unbedingt der Fall. Tatsächlich ähnelt die Methode der Trennung von dynamischem und statischem Lesen der in meiner vorherigen Serie erwähnten Trennung von Datenbank-Lesen und -Schreiben, indem die Zuordnung zwischen Lesen und Schreiben aufgeteilt wird Um das Problem des Leseengpasses zu lösen, ist die dynamische und statische Trennung von Webseiten erforderlich, da statische Ressourcen leicht optimiert werden können. Daher müssen wir dynamische und statische Ressourcen aufteilen. Wenn wir also die dynamischen und statischen Ressourcen trennen, aber die statischen Ressourcen nicht optimieren, ist auf den ersten Blick klar, dass uns ein Vorgang zur Beschleunigung des Seitenladens fehlt. Daher ist es wirklich schwer zu sagen, ob die Seite schneller geladen werden kann Das asynchrone Laden erfordert die Ausführung von JavaScript-Code. Beim Laden statischer Ressourcen kann es jedoch leicht dazu kommen, dass das JavaScript-Skript blockiert wird. Wenn das blockierte Skript zufällig der asynchrone Ladeteil ist, ist das Ergebnis nur langsamer als zuvor.

Es ist ersichtlich, dass die zuvor erwähnten SSI- und ESI-Technologien sehr wichtig sind, damit wir die Vorteile der CSI-Technologie auf der Browserseite nutzen können. SSI und ESI haben gute Arbeit bei der Nutzung statischer Ressourcen geleistet Das Laden ist effizienter, was den ersten Schritt des CSI-Betriebs effizienter macht. Sobald der erste Schritt verarbeitet ist, müssen wir nur noch die Auswirkungen der Skriptblockierung auf das asynchrone Laden auf der Seite kontrollieren Verbessern Sie das Laden der gesamten Seite. Darüber hinaus halte ich es für eine falsche Behauptung, dass CSI einen erheblichen Einfluss auf SEO hat. Wenn der Einsatz von CSI zu schlechten SEO-Ergebnissen führt, dann muss es daran liegen, dass das Design unseres CSI-Plans nicht stimmt.

Manche Leute denken, dass CSI einen Mangel hat, aber ich glaube nicht, dass dies ein Mangel ist. Dies ist tatsächlich ein Designproblem, und ob es gut oder schlecht ist, hängt von den persönlichen Bediengewohnheiten ab. Was ist dieser Mangel, den andere für ihn halten? Bei Verwendung der CSI-Technologie wird die Seite zwar schnell geladen, der dynamische Inhaltsteil zeigt jedoch möglicherweise eine Ladeaufforderung an, was zu einer Verringerung der Benutzerfreundlichkeit der Seite führt. Tatsächlich handelt es sich um eine Art synchroner und asynchroner Lade-Mashup-Vorgang ist zu üblich. Fast alle großen Portale, E-Commerce-Websites und unzählige Websites verwenden eine Mischung aus synchronen und asynchronen Lademethoden. Wenn diese Websites dies nicht tun, werden dies meiner Meinung nach auf jeden Fall der Fall sein. Es ist so langsam, dass die Leute Blut erbrechen, weil viele ihrer Webseiten zu viel Inhalt haben und die Bilder etwas überwältigend sind, sodass sie eine Mischung aus synchronen und asynchronen Lademethoden und sogar viele statische Ressourcen wie Bilder verwenden müssen und Flash wird auch eine asynchrone Lademethode sein. Trotzdem sind einige Leute möglicherweise immer noch nicht überzeugt, dass ihnen die Ladeaufforderung beim Laden der Seite nicht gefällt. Wie sollten wir dieses Problem also lösen? Dieses Problem lässt sich leicht lösen. Wenn Sie bereit sind, die CSI-Technologie zu verwenden, bedeutet dies, dass der Benutzer weiterhin bereit ist, die asynchrone Ladetechnologie zu verwenden. Wenn es Ihnen nicht gefällt, wird eine Aufforderung zum Laden angezeigt. Dies bedeutet, dass der Benutzer bei synchronen Ladevorgängen keine asynchronen Vorgänge vermischen möchte. Obwohl die Ajax-Technologie mittlerweile sehr beliebt ist, gibt es keine Möglichkeit, das synchrone Laden durch die Ajax-Technologie zu lösen, das heißt, wir geben die Website-URL in den Browser ein Adressleiste, um die Seite anzufordern, daher müssen wir angesichts der oben genannten Anforderungen nur sicherstellen, dass dieser Synchronisierungsvorgang nur einer ist. Verwenden Sie einfach reine synchrone Vorgänge ohne asynchrones Laden. Diese Lösung ist einfach zu implementieren, daher werde ich nicht darauf eingehen Details hier.

Nach der dynamischen und statischen Trennung werden wir statische Ressourcen zwischenspeichern. Da CSI nun auf der Browserseite angekommen ist, müssen wir darüber sprechen . Sprechen Sie über Browser-Caching-Vorgänge. Der Caching-Vorgang der Seite besteht darin, HTTP-Abläufe und Cache-Kontrolle zu verwenden. Schauen wir uns zunächst die folgende Schrift an:

<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="cache-control" content="no-cache">
<meta http-equiv="expires" content="0">

Dies wird in dem Java-Webprojekt verwendet, an dem ich gerade arbeite, sowohl JSP als auch VM-Dateien werden in der Metakonfiguration verwendet. Ihr Zweck besteht darin, zu verhindern, dass die Seite vom Browser zwischengespeichert wird. Wenn jedoch die CSI-Technologie verwendet wird und die dynamische und statische Trennung gut erfolgt, können wir dies tatsächlich nicht mehr in den Seitenkopf schreiben. Wir können die Seite in einem angemessenen Zeitraum zwischenspeichern. Wenn die Seite zwischengespeichert wird, wird die Ladeeffizienz der Webseite höher, wenn wir sie in Zukunft besuchen.

Hier gibt es ein weiteres Problem: Um die parallelen Ladeeigenschaften von Webseiten voll auszunutzen, platzieren wir Bilder, externe JS- und CSS-Dateien häufig in separaten statischen Webcontainern oder CDN, dann können diese Dateien oft vom Browser zwischengespeichert werden. Wie können wir das so einrichten, dass der Browser weiß, dass er sie zwischenspeichert? Hier nehmen wir Apache als Beispiel. Damit statische Ressourcen vom Browser zwischengespeichert werden können, muss Apache das Modul mod_expires verwenden und dann die folgende Konfiguration zur Apache-Konfigurationsdatei hinzufügen:

<FilesMatch "\.(gif|jpg|png|js|css">ExpiresDefault "access plus 10 years"</FilesMatch>

Dann greift der Browser auf diesen Apache zu. Nachdem statische Ressourcen erstellt wurden, speichert der Browser die Bilder sowie die JS- und CSS-Dateien auf dem Server im Browser zwischen.

Wenn der HTTP-Antwortcode 304 ist, liest der Browser die Ressource aus dem Cache. Einige Freunde hier fragen sich möglicherweise, warum eine HTTP-Anfrage für die zwischengespeicherte Ressource gesendet wird. Um dies zu verstehen, müssen wir den Mechanismus des Cachings verstehen. Da es sich um eine temporäre Speicherung handelt, sollte die Art und Weise, wie wir das Caching definieren, erfolgen Es ist sinnvoll zu prüfen, ob der Cache abgelaufen ist. Daher müssen wir bei jeder Verwendung des Caches eine Anfrage an den Server senden Der Server gibt einen 304-Antwortcode zurück: 304 Die zurückgegebene Antwort enthält keinen HTTP-Nachrichtentext. Daher sind die Rückgabedaten dieser HTTP-Anforderung sehr klein, sodass die HTTP-Effizienz immer noch sehr hoch ist. Wenn der Server feststellt, dass die Ressource abgelaufen ist , gibt der Server die neue Ressource an den Browser zurück. Tatsächlich hat diese Anfrage zur Erkennung, ob eine Ressource abgelaufen ist, einen richtigen Namen, der als bedingte Get-Anfrage bezeichnet wird. Wie der Server den Überprüfungsvorgang abschließt, wird in dieser Serie ausführlich erläutert, wenn es um die Web-Front-End-Optimierung geht, sodass wir hier nicht näher darauf eingehen. Einige Freunde haben möglicherweise erneut Fragen: Warum kann der Cache-Ablauf nicht auf der Browserseite ermittelt werden? Dies liegt hauptsächlich daran, dass die Überprüfung durch den Browser sehr ungenau ist, da die Computeruhr des Benutzers möglicherweise nicht genau ist oder die Computeruhr des Benutzers nicht mit der des Servers übereinstimmt. Wenn die Zeitzone hinzugefügt wird, ist dies noch problematischer und daher am besten um den Cache auf dem Server ungültig zu machen, damit die Genauigkeit des zwischengespeicherten Gültigkeitszeitraums gewährleistet werden kann. Das Aufkommen von HTML5 hat die Browser-Caching-Funktionen erheblich verbessert. Ich habe mich jedoch nicht eingehend mit der Verwendung der HTML5-Technologie für das Caching befasst, daher werde ich sie hier nicht beschreiben.

Okay, das CSI-Thema ist fertig. Wenn es um CSI-Technologie und Browser geht, können wir mit einem weiteren wichtigen Inhalt dieser Serie beginnen: der Trennung von Front- und Backend. Dies wird das Thema meines nächsten Artikels sein Ich habe es in meinem Blog schon oft erwähnt. Wenn es um die Front-End- und Back-End-Trennung geht, werde ich bald noch einmal darüber sprechen. Dieser Vortrag ist eine Zusammenfassung meiner langjährigen Forschung zur Front-End- und Back-End-Trennung.