Mittwoch, 9. November 2016
Progressive Web Apps
(PWAs) nutzen neue Technologien, um den Nutzern das Beste aus mobilen Websites und nativen Anwendungen zu bieten – und sie sind eine der spannendsten neuen Ideen im Web. Damit sie jedoch wirklich Wirkung zeigen, ist es wichtig, dass sie indexierbar und verlinkbar sind. Jede in diesem Artikel vorgestellte Empfehlung ist eine bewährte Methode für die Indexierbarkeit – unabhängig davon, ob Sie eine Progressive Web App oder eine einfache statische Website erstellen. Dennoch haben wir diese Best Practices zusammengefasst, um Ihnen eine Checkliste als Leitfaden an die Hand zu geben:
Machen Sie Ihre Inhalte crawlbar
Warum? Historisch gesehen generierten oder renderten Websites ihr HTML immer auf dem Server, was der einfachste Weg ist, um sicherzustellen, dass Ihre Inhalte direkt verlinkbar sind. Webanwendungen popularisierten das Konzept des clientseitigen Renderns, bei dem Inhalte dynamisch auf der Seite aktualisiert werden, während der Nutzer navigiert, ohne dass die Seite neu geladen werden muss.
Der moderne Ansatz ist das hybride Rendering, bei dem serverseitiges Rendering verwendet wird, wenn ein Nutzer direkt zu einer URL navigiert, und clientseitiges Rendering nach dem ersten Laden der Seite für nachfolgende Navigationen und asynchrone Anfragen genutzt wird.
Unser
serverseitiges PWA-Beispiel
demonstriert reines serverseitiges Rendering, während unser
hybrides PWA-Beispiel
den kombinierten Ansatz demonstriert.
Wenn Sie mit der Terminologie von serverseitigem und clientseitigem Rendering nicht vertraut sind,
lesen Sie diese Artikel überclient- und serverseitiges Rendering
sowie
serverseitiges Rendering in React und Node.js.
Best Practices:
Verwenden Sie serverseitiges oder hybrides Rendering, damit Nutzer den Inhalt bereits in der ersten Antwort ihrer Webanfrage erhalten.
Stellen Sie immer sicher, dass Ihre URLs unabhängig zugänglich sind:
Das Obige sollte direkt auf diese spezifische Ressource verlinken.
Wenn Sie serverseitiges oder hybrides Rendering für Ihre Progressive Web App nicht unterstützen können und sich für clientseitiges Rendering entscheiden, empfehlen wir die Verwendung des Google Search Console “Abruf wie durch Google”-Tools, um zu überprüfen, ob Ihre Inhalte für unseren Such-Crawler erfolgreich gerendert werden.
Leiten Sie Nutzer, die auf Deep Links zugreifen, nicht zurück auf die Startseite Ihrer Web-App.
Zudem sollte vermieden werden, den Nutzern anstelle eines Deep Links eine Fehlerseite anzuzeigen.
Bereitstellung sauberer URLs Warum?Fragment-Identifikatoren ( #user/24601/ oder#!user/24601/
) waren eine effektive Übergangslösung für Browser, um neue Inhalte per AJAX von einem Server zu laden, ohne die Seite neu zu laden. Dieses Design ist als clientseitiges Rendering bekannt. Die Syntax der Fragment-Identifikatoren ist jedoch nicht mit einigen Web-Tools, Frameworks und Protokollen kompatibel, wie zum Beispiel.
dem Open Graph-Protokoll von Facebook Die History API #! ermöglicht es uns, die URL ohne Fragment-Identifikatoren zu aktualisieren und dennoch Ressourcen asynchron abzurufen, wodurch Seitenneuladungen vermieden werden – es ist das Beste aus beiden Welten. Das AJAX-Crawling-Schema
(mit seinen #! escaped-fragment URLs) war zu seiner Zeit sinnvoll, wird aber heute nicht mehr empfohlen.
Unsere
hybriden PWA- und clientseitigen PWA-Beispiele
demonstrieren die History API.# Best Practices: #!Stellen Sie saubere URLs ohne Fragment-Identifikatoren bereit (
oder
) wie zum Beispiel:
Wenn Sie clientseitiges oder hybrides Rendering verwenden, stellen Sie sicher, dass Sie die Browsernavigation mit der History API unterstützen. #! Vermeiden Sie:
Die Verwendung der # URL-Struktur zur Steuerung eindeutiger URLs wird nicht empfohlen:
Sie wurde als Übergangslösung vor der Einführung der History API eingeführt. Sie gilt als ein # von der reinen URL-Struktur getrenntes Muster. ! Die Verwendung der
URL-Struktur ohne das begleitende
Symbol wird nicht unterstützt:
https://www.example.com/#product/25/
Diese URL-Struktur ist bereits ein Konzept im Web und bezieht sich auf Deep Linking zu Inhalten auf einer bestimmten Seite. Kanonische URLs angeben
Warum?
Der beste Weg, Verwirrung bei der Indexierung zu vermeiden, wenn derselbe Inhalt unter mehreren URLs (sei es auf derselben oder auf verschiedenen Domains) verfügbar ist, besteht darin, eine Seite als kanonisch zu markieren und alle anderen Seiten, die diesen Inhalt duplizieren, darauf verweisen zu lassen.
Best Practices:
Fügen Sie auf allen Seiten, die ein bestimmtes Stück Inhalt spiegeln, das folgende Tag ein: Wenn Sie Accelerated Mobile Pages unterstützen, stellen Sie sicher, dass Sie auch das entsprechende
rel=”amphtml”
Tag korrekt verwenden.
Vermeiden Sie: Vermeiden Sie es, Inhalte absichtlich über mehrere URLs zu duplizieren und das
rel=”canonical” Link-Element nicht zu verwenden. Zum Beispiel kann das
rel=”canonical”
Link-Element die Mehrdeutigkeit bei URLs mit Tracking-Parametern verringern.
Vermeiden Sie widersprüchliche kanonische Referenzen zwischen Ihren Seiten. Design für mehrere Geräte
Warum?
Es ist wichtig, dass alle Ihre Nutzer die bestmögliche Erfahrung bei der Betrachtung Ihrer Website erhalten, unabhängig von ihrem Gerät. Machen Sie Ihre Website in ihrem Design
—Schriftarten, Ränder, Abstände, Schaltflächen und das allgemeine Design Ihrer Website sollten dynamisch basierend auf Bildschirmauflösungen und Geräte-Viewports skaliert werden.
Kleine Bilder, die für Desktop- oder Tablet-Geräte hochskaliert werden, bieten eine schlechte Erfahrung. Umgekehrt benötigen Bilder mit extrem hoher Auflösung lange zum Herunterladen auf Mobiltelefonen und können die Scroll-Leistung auf Mobilgeräten beeinträchtigen.
Lesen Sie mehr über
UX für PWAs.
Best Practices:
Verwenden Sie das
srcset Attribut
um Bilder mit unterschiedlicher Auflösung für Bildschirme mit unterschiedlicher Dichte abzurufen, um zu vermeiden, dass Bilder heruntergeladen werden, die größer sind, als der Bildschirm des Geräts anzeigen kann.
Skalieren Sie Ihre Schriftgröße und Zeilenhöhe, um sicherzustellen, dass Ihr Text unabhängig von der Größe des Geräts lesbar ist. Stellen Sie ebenso sicher, dass die Abstände und Ränder der Elemente ebenfalls sinnvoll skaliert werden.
Testen Sie
verschiedene Bildschirmauflösungen
unter Verwendung der
Gerätemodus-Funktion der Chrome Developer Tools
und des
Mobile-Friendly-Test-Tools.
Zeigen Sie Benutzern keine anderen Inhalte als Google. Wenn Sie
Weiterleitungen oder User-Agent-Erkennung
(auch bekannt als Browser-Sniffing oder
dynamische Bereitstellung) verwenden, um das Design Ihrer Website für verschiedene Geräte zu ändern, ist es wichtig, dass der Inhalt selbst gleich bleibt.
Verwenden Sie das Tool “Abruf wie durch Google” in der Search Console, um zu überprüfen, ob der von Google abgerufene Inhalt mit dem Inhalt übereinstimmt, den ein Benutzer sieht.
Vermeiden Sie aus Gründen der Benutzerfreundlichkeit Schriftarten mit fester Größe.
Iterativ entwickeln
Warum? Einer der sichersten Wege beim Hinzufügen von Funktionen zu einer Webanwendung besteht darin, Änderungen iterativ vorzunehmen. Wenn Sie Funktionen nacheinander hinzufügen, können Sie die Auswirkungen jeder einzelnen Änderung beobachten.
Alternativ ziehen es viele Entwickler vor, ihre progressive Webanwendung als Gelegenheit zu sehen, ihre mobile Website auf einen Schlag zu überarbeiten – indem sie die neue Webanwendung in einer isolierten Umgebung entwickeln und sie gegen ihre bestehende mobile Website austauschen, sobald sie fertig ist.
Wenn Sie Funktionen iterativ entwickeln, versuchen Sie, die Änderungen in separate Teile zu unterteilen. Wenn Sie beispielsweise vom serverseitigen Rendering zum hybriden Rendering übergehen möchten, gehen Sie dies als einzelne Iteration an – anstatt in Kombination mit anderen Funktionen.
Beide Ansätze haben ihre Vor- und Nachteile. Iterationen verringern die Komplexität beim Umgang mit der Suchindexierbarkeit, da der Übergang kontinuierlich ist. Iterationen können jedoch zu einem langsameren Entwicklungsprozess und möglicherweise zu einer weniger innovativen Überarbeitung führen, wenn die Entwicklung nicht bei Null beginnt.
In jedem Fall sind die sensibelsten Bereiche, die Sie im Auge behalten sollten, Ihre kanonischen URLs und die robots.txt-Konfiguration Ihrer Website.
Best Practices:
Iterieren Sie Ihre Website schrittweise, indem Sie neue Funktionen Stück für Stück hinzufügen.
Wenn Sie beispielsweise HTTPS noch nicht unterstützen, beginnen Sie mit der Migration zu einer sicheren Website.
Vermeiden:
Wenn Sie Ihre progressive Webanwendung in einer isolierten Umgebung entwickelt haben, vermeiden Sie es, sie zu starten, ohne zu überprüfen, ob die rel-canonical-Links und die robots.txt ordnungsgemäß eingerichtet sind.
Stellen Sie sicher, dass Ihre rel-canonical-Links auf die echte Website verweisen und dass Ihre robots.txt-Konfiguration es Crawlern ermöglicht, Ihre neue Website zu crawlen.
Es ist logisch, Crawler daran zu hindern, Ihre Website in der Entwicklung vor dem Start zu indexieren, aber vergessen Sie nicht, den Zugriff der Crawler auf Ihre neue Website nach dem Start freizugeben.
Progressive Enhancement verwenden
Warum? Wo immer möglich, ist es wichtig, Browserfunktionen zu erkennen, bevor Sie sie verwenden. Feature-Erkennung ist auch besser als das Testen auf Browser, von denen Sie glauben, dass sie eine bestimmte Funktion unterstützen.
Eine häufige schlechte Praxis in der Vergangenheit war es, Funktionen durch Testen des Browsers des Benutzers zu aktivieren oder zu deaktivieren. Da sich Browser jedoch ständig mit Funktionen weiterentwickeln, wird diese Technik dringend abgeraten.
Service Worker ist eine relativ neue Technologie und es ist wichtig, die Kompatibilität nicht im Streben nach Fortschritt zu beeinträchtigen – es ist ein perfektes Beispiel dafür, wann man Progressive Enhancement verwenden sollte.
Best Practices:
Bevor Sie einen Service Worker registrieren, prüfen Sie die Verfügbarkeit seiner API:
Verwenden Sie die pro-API-Erkennungsmethode für alle Funktionen Ihrer Website.
Verwenden Sie niemals den User-Agent des Browsers, um Funktionen in Ihrer Webanwendung zu aktivieren oder zu deaktivieren. Überprüfen Sie immer, ob die API der Funktion verfügbar ist, und degradieren Sie sie ordnungsgemäß, falls sie nicht verfügbar ist.
Vermeiden Sie es, Ihre Website zu aktualisieren oder zu starten, ohne sie in mehreren Browsern zu testen! Überprüfen Sie Ihre Website-Analysen, um zu erfahren, welche Browser bei Ihrer Benutzerbasis am beliebtesten sind.
Mit Search Console testen
Warum? Es ist wichtig zu verstehen, wie die Google-Suche den Inhalt Ihrer Website sieht. Sie können die
Search Console verwenden, um
einzelne URLs von Ihrer Website abzurufen
und zu sehen, wie die Google-Suche sie sieht, indem Sie die Funktion “Crawling > Abruf wie durch Google” verwenden. Die Search Console verarbeitet Ihr JavaScript und rendert die Seite, wenn diese Option ausgewählt ist; andernfalls wird nur die rohe HTML-Antwort angezeigt.
Die Google Search Console analysiert auch den Inhalt Ihrer Seite auf verschiedene Weise, einschließlich der Erkennung des Vorhandenseins von strukturierten Daten, Rich Cards, Sitelinks und Accelerated Mobile Pages.
Best Practices:
Überwachen Sie Ihre Website mit der Search Console und erkunden Sie deren Funktionen, einschließlich “Abruf wie durch Google”.
Stellen Sie eine Sitemap über die Search Console bereit Crawlen > Sitemaps. Es kann ein effektiver Weg sein, sicherzustellen, dass die Google-Suche alle Seiten Ihrer Website kennt.
Mit Schema.org strukturierten Daten annotieren
Warum? Schema.org strukturierte Daten sind ein flexibles Vokabular, um die wichtigsten Teile Ihrer Seite als maschinenlesbare Daten zusammenzufassen. Dies kann so allgemein sein wie die einfache Aussage, dass eine Seite ein NewsArticleist, oder so spezifisch wie die Angabe von Ort, Bandname, Veranstaltungsort und Ticketanbieter für eine tourende Band oder die Zusammenfassung der Zutaten und Schritte für ein Rezept.
Die Verwendung dieser Metadaten ist möglicherweise nicht für jede Seite Ihrer Webanwendung sinnvoll, wird aber dort empfohlen, wo es sinnvoll ist. Google extrahiert sie, nachdem die Seite gerendert wurde.
Es gibt eine Vielzahl von Datentypen, darunter NewsArticle, Recipeund
Product um nur einige zu nennen. Sie können auch alle
unterstützten Datentypen hier.
erkunden
Best Practices:
Überprüfen Sie, ob Ihre Schema.org-Metadaten korrekt sind, indem Sie Googles.
Testtool für strukturierte Daten
verwenden. Überprüfen Sie, ob die von Ihnen bereitgestellten Daten erscheinen und keine Fehler vorhanden sind. Vermeiden Sie die Verwendung eines Datentyps, der nicht mit dem tatsächlichen Inhalt Ihrer Seite übereinstimmt. Verwenden Sie beispielsweise nicht
Rezept für ein T-Shirt, das Sie verkaufen—verwenden Sie stattdessen Produkt .
Mit Open Graph und Twitter Cards annotieren
Warum? Zusätzlich zu den Schema.org-Metadaten kann es hilfreich sein, auch Unterstützung für das Open Graph-Protokoll von Facebook und Twitter Rich Cards hinzuzufügen.
Diese Metadatenformate verbessern die Benutzererfahrung, wenn Ihre Inhalte in den entsprechenden sozialen Netzwerken geteilt werden.
Wenn Ihre bestehende Website oder Webanwendung diese Formate nutzt, ist es wichtig sicherzustellen, dass sie für eine optimale Viralität auch in Ihrer Progressive Web App enthalten sind.
Best Practices:
Testen Sie Ihr Open Graph-Markup mit dem
Facebook Object Debugger Tool.
Machen Sie sich vertraut mit
Twitter-Metadatenformat.
Vergessen Sie nicht, diese Formate einzubeziehen, wenn Ihre bestehende Website sie unterstützt.
Mit mehreren Browsern testen
Warum? Aus Benutzersicht ist es wichtig, dass sich eine Website in allen Browsern gleich verhält. Während sich die Erfahrung an unterschiedliche Bildschirmgrößen anpassen mag, erwarten wir alle, dass eine mobile Website auf ähnlich großen Geräten gleich funktioniert, egal ob es sich um ein iPhone oder ein Android-Mobiltelefon handelt.
Obwohl das Web aufgrund der Anzahl der weltweit verwendeten Browser als fragmentiert wahrgenommen werden kann, ist diese Vielfalt und der Wettbewerb Teil dessen, was das Web zu einer so innovativen Plattform macht. Glücklicherweise waren Webstandards noch nie so ausgereift wie heute, und moderne Tools ermöglichen es Entwicklern, mit Zuversicht reichhaltige, browserübergreifende kompatible Websites zu erstellen.
Best Practices:
Verwenden Sie browserübergreifende Test-Tools wie
BrowserStack.com,
Browserling.com oder
BrowserShots.org um sicherzustellen, dass Ihre PWA
browserübergreifend
kompatibel ist. Seitenladeleistung messen
Warum?
Je schneller eine Website für einen Benutzer lädt, desto besser ist die Benutzererfahrung. Die Optimierung der Seitengeschwindigkeit ist bereits ein bekannter Schwerpunkt in der Webentwicklung, aber manchmal werden bei der Entwicklung einer neuen Version einer Website die notwendigen Optimierungen nicht als hohe Priorität angesehen.
Bei der Entwicklung einer Progressive Web App empfehlen wir, die Leistung Ihrer Seitenladegeschwindigkeit zu messen und vor dem Start der Website zu optimieren, um die besten Ergebnisse zu erzielen.
Best Practices: Verwenden Sie Tools wie
Page Speed Insights
und
Web Page Test
um die Seitenladeleistung Ihrer Website zu messen. Während der Googlebot beim Rendern etwas mehr Geduld hat,
haben Untersuchungen gezeigt,
dass 40 % der Verbraucher eine Seite verlassen, deren Laden länger als drei Sekunden dauert..
Lesen Sie mehr über unsere Empfehlungen zur Webseitenleistung und den
kritischen Rendering-Pfad hier
Vermeiden Sie es, die Optimierung als Schritt nach dem Start zu belassen. Wenn der Inhalt Ihrer Website schnell lädt, bevor Sie zu einer neuen Progressive Web App migrieren, ist es wichtig, bei Ihren Optimierungen nicht zurückzufallen.
Wir hoffen, dass die obige Checkliste nützlich ist und die richtige Anleitung bietet, um Sie bei der Entwicklung Ihrer Progressive Web Apps mit Blick auf die Indexierbarkeit zu unterstützen.
Wenn Sie anfangen, schauen Sie sich unbedingt unsere
Progressive Web App-Indexierbarkeitsbeispiele.
So setzen wir das um
We archive Search Central announcements because client questions often trace back to a change that was announced years ago. Reading the original is faster than reconstructing it from second-hand summaries.
Verwandte Leistungen