Single-Page-Anwendung
Da das SPA eine Weiterentwicklung weg von der zustandslosen Seite-neu zu zeichnen Modell, das Browser wurden ursprünglich für, einige neue Herausforderungen entstanden. Mögliche Lösungen (unterschiedlicher Komplexität, Vollständigkeit und Autorenkontrolle) umfassen:
- Clientseitige JavaScript-Bibliotheken.
- Serverseitige Webframeworks, die auf das SPA-Modell spezialisiert sind.
- Die Entwicklung von Browsern und die HTML5-Spezifikation, die für das SPA-Modell entwickelt wurde.,
Search-engine optimizationEdit
Aufgrund der fehlenden JavaScript-Ausführung bei Crawlern einiger beliebter Web-Suchmaschinen hat SEO (Search Engine optimization) in der Vergangenheit ein Problem für öffentlich zugängliche Websites dargestellt, die das SPA-Modell übernehmen möchten.
Zwischen 2009 und 2015 schlug Google Webmaster Central ein „AJAX-Crawling-Schema“ vor und empfahl es dann, ein erstes Ausrufezeichen in Fragmentbezeichnern für stateful AJAX-Seiten zu verwenden (#!)., Spezielles Verhalten muss von der SPA-Site implementiert werden, um die Extraktion relevanter Metadaten durch die Suchmaschine Crawler zu ermöglichen. Bei Suchmaschinen, die dieses URL-Hash-Schema nicht unterstützen, bleiben die Hash-URLs des SPA unsichtbar. Diese „Hash-Bang“ – URIs wurden von einer Reihe von Autoren als problematisch angesehen, darunter Jeni Tennison vom W3C, da sie Seiten für diejenigen unzugänglich machen, auf die JavaScript in ihrem Browser nicht aktiviert ist. Sie unterbrechen auch HTTP-Referer-Header, da Browser die Fragmentkennung im Referer-Header nicht senden dürfen., Im Jahr 2015 veraltete Google ihren Hash-Bang AJAX Crawling Vorschlag.
Alternativ können Anwendungen das Laden der ersten Seite auf dem Server und nachfolgende Seitenupdates auf dem Client rendern. Dies ist traditionell schwierig, da der Rendering-Code möglicherweise in einer anderen Sprache oder einem anderen Framework auf dem Server und im Client geschrieben werden muss. Durch die Verwendung von Vorlagen ohne Logik, das Cross-Compilieren von einer Sprache in eine andere oder die Verwendung derselben Sprache auf dem Server und dem Client kann die Menge des gemeinsam genutzten Codes erhöht werden.,
Im Jahr 2018 führte Google dynamisches Rendering als weitere Option für Websites ein, die Crawlern eine nicht JavaScript-schwere Version einer Seite für Indizierungszwecke anbieten möchten. Dynamisches Rendering wechselt zwischen einer Version einer Seite, die clientseitig gerendert wird, und einer vorgerenderten Version für bestimmte Benutzeragenten. Bei diesem Ansatz erkennt Ihr Webserver Crawler (über den Benutzeragenten) und leitet sie an einen Renderer weiter, von dem aus ihnen dann eine einfachere Version von HTML-Inhalten bereitgestellt wird.,
Da SEO-Kompatibilität in SPAs nicht trivial ist, ist es erwähnenswert, dass SPAs häufig nicht in einem Kontext verwendet werden, in dem Suchmaschinenindizierung entweder eine Anforderung oder wünschenswert ist. Anwendungsfälle umfassen Anwendungen,die private Daten hinter einem Authentifizierungssystem verbergen. In den Fällen, in denen es sich bei diesen Anwendungen um Konsumgüter handelt, wird häufig ein klassisches „Page Redraw“ – Modell für die Zielseite und die Marketing-Site der Anwendungen verwendet, das genügend Metadaten bereitstellt, damit die Anwendung als Treffer in einer Suchmaschinenabfrage angezeigt wird., Blogs, Support-Foren und andere traditionelle Artefakte zum Neuzeichnen von Seiten befinden sich häufig im SPA, die Suchmaschinen mit relevanten Begriffen versorgen können.
Ein anderer Ansatz, der von serverzentrierten Webframeworks wie dem Java-basierten ItsNat verwendet wird, besteht darin, Hypertext auf dem Server mit derselben Sprache und Vorlagentechnologie zu rendern. Bei diesem Ansatz kennt der Server genau den DOM-Status auf dem Client, jede große oder kleine Seitenaktualisierung, die auf dem Server generiert wird, und transportiert von Ajax den genauen JavaScript-Code, um die Clientseite in den neuen Status zu bringen, der DOM-Methoden ausführt., Entwickler können entscheiden, welche Seitenzustände von Webspinnen für SEO gecrawlt werden können, und den erforderlichen Status beim Laden generieren von einfachem HTML anstelle von JavaScript generieren. Im Fall des ItsNat-Frameworks ist dies automatisch, da ItsNat den Client-DOM-Baum auf dem Server als Java W3C DOM-Baum behält; Das Rendern dieses DOM-Baums auf dem Server generiert beim Laden einfachen HTML-Code und JavaScript-DOM-Aktionen für Ajax-Anforderungen., Diese Dualität ist für SEO sehr wichtig, da Entwickler mit demselben Java-Code und reinen HTML-basierten Vorlagen den gewünschten DOM-Status im Server erstellen können; Zur Seitenladezeit wird herkömmliches HTML von ItsNat generiert, wodurch dieser DOM-Status SEO-kompatibel wird.
Ab Version 1.,3 stellt ItsNat einen neuen zustandslosen Modus bereit, und das Client-DOM wird nicht auf dem Server gehalten, weil mit dem zustandslosen Modus-Client der DOM-Status teilweise oder vollständig auf dem Server rekonstruiert wird, wenn eine Ajax-Anforderung basierend auf erforderlichen Daten verarbeitet wird, die vom Client gesendet werden und den Server über den aktuellen DOM-Status informieren; Der zustandslose Modus kann auch SEO-kompatibel sein, da die SEO-Kompatibilität zum Zeitpunkt des Ladens der ersten Seite ohne zustands-oder zustandslose Modi erfolgt., Eine weitere mögliche Wahl sind Frameworks wie PreRender, Puppeteer, Rendertron, die einfach als Middleware mit Webserverkonfiguration in jede Website integriert werden können, sodass Bot-Anforderungen (Google Bot und andere) von der Middleware bedient werden können, während Nicht-Bot-Anforderungen wie gewohnt bedient werden. Diese Frameworks cachen die relevanten Website-Seiten regelmäßig zwischen, damit die neuesten Versionen für Suchmaschinen verfügbar sind. Diese Frameworks wurden offiziell von Google genehmigt.
Es gibt ein paar Problemumgehungen, damit es so aussieht, als ob die Website crawlbar ist., Beide beinhalten das Erstellen separater HTML-Seiten, die den Inhalt des SPA widerspiegeln. Der Server könnte eine HTML-basierte Version der Website erstellen und diese an Crawler liefern, oder es ist möglich, einen kopflosen Browser wie PhantomJS zu verwenden, um die JavaScript-Anwendung auszuführen und die resultierende HTML-Ausgabe.
Beide erfordern ziemlich viel Aufwand und können am Ende einen Wartungsschmerz für die großen komplexen Standorte verursachen. Es gibt auch potenzielle SEO-Fallstricke. Wenn servergeneriertes HTML als zu unterschiedlich vom SPA-Inhalt angesehen wird, wird die Site bestraft., Das Ausführen von PhantomJS zur Ausgabe des HTML-Codes kann die Reaktionsgeschwindigkeit der Seiten verlangsamen, was Suchmaschinen-insbesondere Google-die Rangliste herabstufen.
Client / Server Code Partitionierungdit
Eine Möglichkeit, die Menge an Code zu erhöhen, die zwischen Servern und Clients gemeinsam genutzt werden kann, ist eine Logik-less Template-Sprache wie Schnurrbart oder Lenker zu verwenden. Solche Vorlagen können aus verschiedenen Hostsprachen wie Ruby auf dem Server und JavaScript im Client gerendert werden., Das bloße Teilen von Vorlagen erfordert jedoch in der Regel eine Duplizierung der Geschäftslogik, mit der die richtigen Vorlagen ausgewählt und mit Daten gefüllt werden. Das Rendern von Vorlagen kann sich negativ auf die Leistung auswirken, wenn nur ein kleiner Teil der Seite aktualisiert wird, z. B. der Wert einer Texteingabe in einer großen Vorlage. Das Ersetzen einer gesamten Vorlage kann auch die Auswahl oder Cursorposition eines Benutzers stören, wobei das Aktualisieren nur des geänderten Werts möglicherweise nicht erfolgt., Um diese Probleme zu vermeiden, können Anwendungen UI-Datenbindungen oder granulare DOM-Manipulationen verwenden, um nur die entsprechenden Teile der Seite zu aktualisieren, anstatt ganze Vorlagen neu zu rendern.
Browserhistorieedit
Mit einem SPA, das per Definition „eine einzelne Seite“ ist, bricht das Modell das Design des Browsers für die Seitenverlaufsnavigation mit den Schaltflächen“Vorwärts „oder“ Zurück“., Dies stellt ein Usability-Hindernis, wenn ein Benutzer die Zurück-Taste drückt, den vorherigen Bildschirmzustand innerhalb des SPA erwartet, sondern die einzelne Seite der Anwendung entlädt und die vorherige Seite im Browser Geschichte präsentiert.
Die traditionelle Lösung für SPAs bestand darin, die Hash-Fragmentkennung der Browser-URL entsprechend dem aktuellen Bildschirmstatus zu ändern. Dies kann mit JavaScript erreicht werden und führt dazu, dass URL-Verlaufsereignisse im Browser erstellt werden., Solange das SPA in der Lage ist, denselben Bildschirmstatus anhand der im URL-Hash enthaltenen Informationen wiederzubeleben, bleibt das erwartete Verhalten der Zurück-Schaltfläche erhalten.
Um dieses Problem weiter zu beheben, hat die HTML5-Spezifikation pushState und replaceState eingeführt, die programmatischen Zugriff auf die tatsächliche URL und den Browserverlauf ermöglichen.
AnalyticsEdit
Analysetools wie Google Analytics sind stark auf das Laden ganz neuer Seiten im Browser angewiesen, die durch ein neues Laden der Seite ausgelöst werden. SPAs funktionieren nicht so.,
Nach dem ersten Laden der Seite werden alle nachfolgenden Seiten-und Inhaltsänderungen intern von der Anwendung behandelt, die einfach eine Funktion zum Aktualisieren des Analysepakets aufrufen sollte. Wenn diese Funktion nicht aufgerufen wird, löst der Browser niemals ein neues Laden der Seite aus, es wird nichts zum Browserverlauf hinzugefügt, und das Analysepaket hat keine Ahnung, wer was auf der Site tut.
Hinzufügen von Seitenladungen zu einem SPAEdit
Es ist möglich, einem SPA Seitenladeereignisse mithilfe der HTML5 history API hinzuzufügen., Die Schwierigkeit besteht darin, dies zu verwalten und sicherzustellen, dass alles genau verfolgt wird – dies beinhaltet die Überprüfung auf fehlende Berichte und doppelte Einträge.Einige Frameworks bieten Open-Source-Analytics-Integrationen für die meisten großen Analytics-Anbieter. Entwickler können sie in die Anwendung integrieren und sicherstellen, dass alles korrekt funktioniert, aber Sie müssen nicht alles von Grund auf neu machen.
Geschwindigkeit des ersten Ladens
Einseitige Anwendungen haben ein langsameres Laden der ersten Seite als serverbasierte Anwendungen., Dies liegt daran, dass beim ersten Laden das Framework und der Anwendungscode heruntergefahren werden müssen, bevor die erforderliche Ansicht als HTML im Browser gerendert wird. Eine serverbasierte Anwendung muss nur das erforderliche HTML an den Browser senden, um die Latenz und die Downloadzeit zu reduzieren.
Beschleunigung des Seitenladevorgangs
Es gibt einige Möglichkeiten, das anfängliche Laden eines SPA zu beschleunigen, z. B. einen umfassenden Ansatz für das Caching und das verzögerte Laden von Modulen bei Bedarf., Aber es ist nicht möglich, weg von der Tatsache zu bekommen, dass es das Framework herunterladen muss, zumindest einen Teil des Anwendungscodes, und wird höchstwahrscheinlich eine API für Daten treffen, bevor etwas im Browser angezeigt wird. Dies ist ein „pay me now, oder zahlen Sie mich später“ trade-off “ – Szenario. Die Frage nach Leistung und Wartezeiten bleibt eine Entscheidung, die der Entwickler treffen muss.