Der Beginn einseitiger SPA-Anwendungen
Das Single Page Application (SPA) -Modell hat in den letzten Jahren an Popularität gewonnen. Es ist verständlich, dass dieser Ansatz einen gewissen Gewinn in Bezug auf Geschwindigkeit und Servicequalität bringt und die Grundlage für neue Muster der Webentwicklung von Kunden schafft.
Wie jeder meiner Meinung nach weiß, funktioniert SPA im Browser und erfordert kein erneutes Laden der Seite während der Verwendung.
Großartige Idee! Aber natürlich gibt es Fallstricke.
Unter den häufigsten Fällen (wenn Sie ein Tutorial zu React oder Vue absolvieren) enthält die Hauptseite index.html eine fast leere HTML-Datei mit einer kleinen Anzahl von CSS, JavaScript, Schriftarten usw., die für das gesamte Projekt global sind.
Und das ist das Problem:
- Während des ersten Renderns muss der Benutzer warten, bis die gesamte Codebasis und alle Ressourcen geladen sind (natürlich gibt es Ausnahmen, und Sie können das dynamische Laden sogenannter js / css-Chunks implementieren, aber das ist eine andere Geschichte).
- Bei einigen Crawlern oder Parsern, die nicht auf das Laden asynchroner Anforderungen warten können, werden nur alle Seiten leer angezeigt
Nun, Sie haben die Idee:
<!DOCTYPE html>
<html>
<head>
<title>My first SPA app</title>
<script src="https://cdn__"></script>
</head>
<body>
<div id="app"></div>
<script>
...
,
...
</script>
</body>
</html>
Serverseitiges Rendern von SSR
Im Gegensatz zu Client Side Rendering (CSR), bei dem der Browser zum Rendern des gesamten Anwendungsinhalts und zum Abrufen von Daten von APIs und dergleichen verwendet wird, verwendet SSR ... den Server. Das heißt, das gleiche Rendern und Abrufen von Daten wird vom Server verarbeitet (NodeJS mit Express, Next, Vue SSR, Nuxt oder was auch immer ...) und anschließend eine Antwort mit HTML-Markup, Stilen, Skripten und den von der API empfangenen Daten. an den Browser gesendet.
Somit können Sie zwei Ansätze nutzen: Geschwindigkeit / SEO und Interaktivität / UX.
Was ist Hydratation / Rehydratation?
Rehydration ist eine Art Brücke zwischen SSR und CSR.
Es gibt einen solchen Indikator für die Leistung von Webseiten wie First Contentful Paint (FCP) - grob übersetzt klingt es wie "erstes signifikantes Rendern" - die Zeit, als der Browser anfing, Text und Bilder (einschließlich Hintergrund) anzuzeigen. Dies sind die ersten Elemente, die der Benutzer auf der Seite sieht. Wenn Sie einen Bericht mit Lighthouse in Chrome erstellen, wird diese Metrik auf der Registerkarte Leistung sofort angezeigt.
Die Zeit, die zum Generieren von Inhalten auf dem Server aufgewendet wird, ist die Zeit für den ersten inhaltlichen Malvorgang.
Unmittelbar danach beginnt clientseitiges JavaScript mit der Ausführung, um eine vollwertige Clientanwendung zu erstellen (in den meisten Fällen sind beliebte Frameworks Virtual Dom und eine verbindliche Schnittstelle für die Verwaltung).
Zu diesem Zeitpunkt muss das gesamte DOM auf dem Client nicht erneut gerendert werden. Es müssen jedoch die fehlenden Ereignisse, Methoden und in einigen Fällen Elemente hinzugefügt werden, die nicht auf dem Server gerendert wurden.
Dieser Prozess wird als Hydratation / Rehydratation bezeichnet. Eine etwas detailliertere Beschreibung finden Sie im Vue SSR Guide (ebenfalls in russischer Sprache), jedoch mit einigen Merkmalen dieses speziellen Frameworks.
Performance
In diesem Teil treten jedoch einige Probleme auf. Rehydration hat einen gewissen Nachteil - es ist die Zeit vor der Interaktion oder Time to Interactive, die in dem uns bekannten Lighthouse Chrome zu sehen ist. Selbst wenn Sie alles auf der Serverseite perfekt organisiert haben und die Seite ein schnelles erstes Rendern des Inhalts aufweist, kann der Benutzer erst nach der CSR-Rehydratisierung mit ihm interagieren, was manchmal recht langsam ist. Dies ist ein großer Nachteil in Bezug auf UX.
Ein weiterer Indikator für die maximale potenzielle erste Eingangsverzögerung ist die erste Eingangsverzögerung (FID) - eine der Leistungsmetriken von Webseiten, die die Zeit beschreibt, die seit dem Moment vergangen ist, als der Benutzer zum ersten Mal mit der Webseite zu interagieren begann, d. H. e. Klicken Sie auf einen Link, eine Schaltfläche oder verwenden Sie ein JavaScript-basiertes Steuerelement, bis der Webbrowser auf die Interaktion reagieren kann (wie von Mozilla definiert).
Und die Rehydratisierungszeit wirkt sich direkt auf diesen Indikator aus. Und je mehr Komponenten und Logik sich auf Ihrer Seite befinden, desto schneller steigt diese Anzeige an.
Eine Lösung ist die träge Belastung für die Flüssigkeitszufuhr.
Ein Beispiel für die Implementierung eines ähnlichen Ansatzes in Vue SSR / NuxtJS ist das Vue -Lazy-Hydration-Paket(im npm-Repository), das die Hydratation nur im sichtbaren Teil des Ansichtsfensters des Browsers implementiert und den Rest nur dann "hydratisiert", wenn die Seite gescrollt wird. Empfehlungen zur Verwendung dieses Pakets finden Sie auch auf habr im Tutorial Erstellen Sie einen Online-Shop auf Nuxt.js , für den der AutorAntonMoskalchenkoIch möchte meinen besonderen Dank aussprechen. In seinem Artikel erzielte Lighthouse Chrome eine 100% ige Leistung.