Mehr Pagespeed geht nicht - SEOkomm 2015

8.271 Aufrufe

Veröffentlicht am

Mein Vortrag der SEOkomm 2015 in Salzburg, u.a. rund um Webfonts, asynchrone Scripte, Prefetching und Prerendering, AMP, HTTP2 und mehr!

Veröffentlicht in: Technologie
1 Kommentar
28 Gefällt mir
Statistik
Notizen
  • peakace.de and #growthhacking ;-) - gerade das Kompliment vom Google Webmaster Trend Analyst John Müller auf G+ gelesen. Will ich hier nicht vorenthalten: "If you're keen on making a wicked-fast website, it's almost (?) worth learning German to read through +Bastian Grimm 's presentation from SEOkomm this year. It touches upon so many things that sites can do to improve their usability by being instantly available to their users." 
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier
Keine Downloads
Aufrufe
Aufrufe insgesamt
8.271
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
895
Aktionen
Geteilt
0
Downloads
5
Kommentare
1
Gefällt mir
28
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Mehr Pagespeed geht nicht - SEOkomm 2015

  1. 1. Bastian Grimm, Peak Ace AG | @basgr Mehr (Page-) Speed geht nicht… Ein Blick in die Zukunft der Ladezeiten-Optimierung
  2. 2. Ich bin ein extrem ungeduldiger Mensch… Ladezeit ist ein User Experience Thema!
  3. 3. Anderer Budgettopf! Warum ist das wichtig?
  4. 4. 5 Fakten in max. 2 Minuten…! Keine Basics, aber ein kurzer Recap:
  5. 5. Google nutzt Ladezeit als Ranking Signal… … und das bereits seit 2010! Mehr lesen: http://pa.ag/1t4xVs6
  6. 6. Die Top-4 sind deutlich schneller als der Wettbewerb! Seiten mit “gutem SEO” kümmern sich offenbar auch um Sitespeed? Searchmetrics Ranking Factors 2014 (US): http://pa.ag/10cZuU2
  7. 7. Die Erwartungshaltung eurer User ist klar: Langsame Ladezeiten bedeuten sofort einen Trafficverlust! “A report from Nielsen has revealed that 47% of people expect a website to load within 2 seconds, and 40% will leave a website if it does not load fully within 3 seconds.” Mehr lesen: http://pa.ag/1Rk8dIf
  8. 8. Quelle: http://pa.ag/1w8IYwq Bereits 100ms machen einen (großen) Unterschied! Amazon = 1%+ mehr Umsatz pro 100ms 1 Sekunde Verzögerung = -11% Pageviews & -7% Conversions
  9. 9. Google misst die Return-to-SERP-Rate… In Kombination (CTR, ToS) ist diese ebenso ein (indirekter) Rankingfaktor!
  10. 10. …und forciert das Thema Site Speed immer wieder: Quelle: http://pa.ag/1cWFCtY
  11. 11. Die Themen des letzten Jahres sind weiterhin wichtig: Zu den Folien auf Slideshare: http://pa.ag/seokomm-speed • Optimierung des Critical Rendering Path (Google interessiert zu aller erst der direkt sichtbare Bereich!) • CSS & JavaScript Dateien verkleinern (minify) • Bilder optimieren: Sprites verwenden und Overhead bei JPG & PNGs reduzieren (Metadaten, etc.) • Effektives Caching & serverseitige Komprimierung • Schlankes Mark-Up (keine Kommentare, inline von CSS / JS nur wo es wirklich sinnvoll ist) • CDN bzw. Asset-Server (sowie Cookie-less Domains) zum Parallelisieren von Downloads verwenden • etc.
  12. 12. … dennoch drei kurze Anmerkungen dazu: Wir sprechen heute nicht über Tools…
  13. 13. Google PageSpeed Insights als Startpunkt Freies, web-basiertes Tool von Google, um eine Seite anhand diverser Regeln und Best-Practices zu messen Jetzt ausprobieren: https://developers.google.com/speed/pagespeed/insights/
  14. 14. Was wirklich zählt? Zeit statt Note! Vollständiger Artikel: http://pa.ag/1KjZuQQ
  15. 15. webpagetest.org – mit allen Funktionen: Alles auf einen Blick: TTFB, Keep-Alive, Compression & Caching, Image Usage, CDN & Wasserfall-Diagramme
  16. 16. Wenn schon Google Daten, dann aus der Search Console Habt diese Daten immer im Blick, sowas sollte nicht passieren! Seiten / Tag Zeit / Download
  17. 17. Kostenloses Dashboard von sitespeed.io Daten im zeitlichen Verlauf, Wettbewerbsvergleich, uvm. Jetzt ausprobieren: http://pa.ag/1PuN012
  18. 18. Genug davon, auf geht‘s!
  19. 19. Anzahl von Requests, Blocking vs. non-Blocking, Asynchron, etc. #1 HTTP Anfragen optimieren
  20. 20. Wenn man 23 CSS & JS Dateien lädt, ist das Scheisse! Deichmann AT verschwendet ~3 Sek. auf Blocking-Ressources…
  21. 21. Konsolidieren bzw. Kombinieren (JS, CSS) und Sprites wo möglich! Weniger ist mehr!
  22. 22. Für alles andere: Asynchrone Requests wann immer mgl. HTML5 async, JS Workarounds und / oder Loader verwenden: Mehr: http://pa.ag/18o8War
  23. 23. Schön, abwechslungsreich, bunt und… langsam! #2 Custom Webfonts
  24. 24. 57% aller Webseiten nutzen nicht-Standard-Schriften Das Ergebnis: 114 KB Datenvolumen bei avg. zus. 2,9 HTTP Requests! Quelle: http://pa.ag/1BRUnbe
  25. 25. Klassisches Szenario: Einbinden als (externes) CSS File Sehr einfach einzusetzen, großer Nachteil: CSS ist Render-Blocking!
  26. 26. Custom Font mittels Fontloader laden webfont.js ist Googles Lösungsvorschlag (Asnyc JS lädt dann CSS):
  27. 27. Leider mit wenig Erfolg und einem anderen Problem: FOUT (Flash of unstyled Text) = nerviges Flackern! Fighting the FOUT: http://pa.ag/1BRWMmu
  28. 28. Credits: http://pa.ag/1GakitY & http://pa.ag/1NDXCVi
  29. 29. Gezieltes „vorab laden“ von DNS, Ressourcen & ganzen Seiten #3 Pre-Fetching & -Rendering
  30. 30. The Pre*-Party at-a-glance: Stolen from Ilya Grigorik: http://pa.ag/1MV4KAk
  31. 31. NetDoktor.de Request Breakdown (Waterfall-View) Der DNS-Lookup auf den Asset-Server (static.netdoktor.de) dauert 333ms
  32. 32. DNS Pre-Fetching im <head>: 81ms = 75% Ersparnis Super nützlich für Ressourcen anderer Hosts, die später genutzt werden!
  33. 33. Chrome lädt eure Top-10 Hosts bei jedem Start! Einfach mal mit chrome://dns eure Top Destinations anschauen:
  34. 34. Noch einen Schritt weiter: Pre-Connect bei HTTPS Nicht nur den DNS auflösen; auch den TLS-Handshake durchführen:
  35. 35. Gezieltes Vorladen von einzelnen Ressourcen Prefetch (für Folgeseiten ): • Wird nur im Browser-Leerlauf (mit geringer Prio) ausgeführt • Einsatz: Bilder, JS & CSS herunterladen & cachen. • Bei langsamen Verbindungen werden große Dateien u.U. ignoriert. Subresource (für die aktuelle Seite): • Funktioniert derzeit nur im Chrome • Möglichst zu Beginn im Mark-Up nutzen • Analog zu Prefetch, aber hohe Prio, daher nur verwenden, wenn das File wirklich nötig ist!
  36. 36. Das nächste Bild in einer Bildergalerie / großes Bild in einem Zoom HTML Fragmente (bspw. Boxen / Layer) für kritische Ziele (Signup / -in) Was könnte ich prefetchen?
  37. 37. Pre-Rendering: Vorladen ganzer Websites! Wenn ich weiß, wohin mein Besucher navigieren wird: Prerender: • Aktuell nur im Chrome & IE/Edge möglich • Lädt die Folgeseite inkl. aller Ressourcen und legt diese in den Cache • Nur für GET-Requests und extrem ressourcenintensiv – use with care! Prefetch & Prerender: • Kombinierte Verwendung für bessere Browser Kompatibilität • FF führt Prefetch aus, Chrome & IE nutzen die Prerender Anweisung
  38. 38. Den Warenkorb (od. Checkout), wenn ein Artikel hineingelegt wird. Die Folgeseite eines mehrseitigen Artikels. Was könnte ich prerendern?
  39. 39. Eine JavaScript API für Sichtbarkeitszustände des Browsers #4 Page Visibility API
  40. 40. visibilitychange-Events für Sichtbarkeitszustände Schaut der User meine Website an oder ist diese nur im Hintergrund offen? “The API lets you know when a webpage is visible or in focus. […] there is a reasonable chance that any given webpage is in the background and thus not visible to the user. When the user minimizes the webpage or moves to another tab, the API sends an event regarding the visibility of the page.” Mehr lesen: http://pa.ag/1Nysd6K
  41. 41. Die Pre*-Party kann euch euer Analytics ruinieren! Akkurateres Tracking
  42. 42. JS erst ausführen, wenn die Seite wirklich sichtbar ist (non-Prerender). Eventbasiertes Laden von Elementen
  43. 43. Browser Support für die Page Visibility API Vollständiger Support in allen wichtigen Browsern! Quelle: http://caniuse.com/#feat=pagevisibility
  44. 44. Top Qualität, effiziente(re) Komprimierung, kleinere Dateien, etc. #5 Neue Bildformate
  45. 45. 62% des Webtraffics sind Bildmaterial! … und 51% aller URLs laden mehr als 40 Bilder (pro Aufruf) Quelle: http://pa.ag/1SGDOEo
  46. 46. WebP: Googles Alternative zu JPEG, PNG & GIF Lossy & lossless Komprimierung, Transparenz, Metadaten & Farbprofile, Animationen & deutlich kleiner (30% vs. JPEG, 80% vs. PNG)! Alles zu WebP: : http://pa.ag/1EpFWeN
  47. 47. Wir sind noch nicht „ganz“ da… Derzeit nativ leider nur für Chrome, Opera und auf Android Browsern! Quelle: http://caniuse.com/#feat=webp
  48. 48. WebP trotzdem nutzen: On-the-fly Replacement PNG & JPEG Bilder per Rewrite (z.B. via .htaccess) austauschen:
  49. 49. WebP trotzdem nutzen: On-the-fly Replacement PNG & JPEG Bilder per Rewrite (z.B. via .htaccess) austauschen: VS.
  50. 50. Bei neuen Templates: HTML5 & <picture> verwenden! Browser, die <picture> nicht unterstützen, ignorieren selbiges & auch <source> Browser, die WebP nicht unterstützen, verwenden das Fallback <img> Weitere Infos: http://responsiveimages.org/
  51. 51. Das letzte Wort ist noch nicht gesprochen: FLIF, BPG, etc. (Links: Dateigröße im Vergleich zum Original-PNG) Mehr lesen: http://pa.ag/1S5OQmX
  52. 52. Insbesondere zwei Themen sind aktuell „hot“…! Was gibt‘s Neues? #perfmatters
  53. 53. Google‘s „Accelerated Mobile Pages“ für schnellere, mobile Webseiten #6 Das AMP Projekt
  54. 54. AMP: Kastriertes HTML für maximale Performance! Google ist Geschwindigkeit deutlich wichtiger als (HTML-) Features Mehr: https://www.ampproject.org/ • Modifiziertes HTML Mark-Up mit diversen Änderungen • Herkömmliche HTML Tags, wie <script> sind verboten, andere wie bspw. <img> werden durch spezielle AMP Tags, z.B. <amp-img> ersetzt • AMP Funktionalität durch standardisierten Dokument- aufbau und eine AMP JS Library für maximal effizientes Pre-Rendering bzw. Caching
  55. 55. Ein Standarddokument mit AMP HTML Mark-Up: Vordefinierter Aufbau sowie diverse Restriktionen: How to write AMP Mark-Up: http://pa.ag/1MN9I1X • start with the doctype <!doctype html>. • contain a top-level <html> tag (<html amp> is OK as well). • contain <head> and <body> tags • contain a <link rel="canonical" href="$SOME_URL" /> tag inside head that points to the regular HTML version or to itself if no such HTML version exists • contain a <meta charset="utf-8"> tag as the first child • contain a “meta viewport” & “initial-scale=1” • contain a <script async src="https://cdn.ampproject.org/v0.js"></script> tag as the last element in their head. • contain a <style> attribute setting various defaults
  56. 56. Wie sieht das in den Suchergebnissen aus? Testlink öffnen, Schlagzeilen suchen, swipen (keine Schlagzeilen = keine AMPs) Testlink (nur auf Mobilgeräten): http://g.co/ampdemo
  57. 57. Restriktionen?! Gefühlt wie damals mit HTML 2.0! Restriktionen: http://pa.ag/1ObU4fH
  58. 58. It doesn‘t feel open, it feels very closed! Sehr lesenswerter Artikel von Joost de Valk: There are, for instance, specific tags for YouTube and Twitter. To get your tag in AMP you’ll have to apply […]. The same is true for most advertising formats: only 5 ad platforms are supported, 2 of which are owned by Google. Currently there is no info to be found on […] the process of applying for new tags or ad formats, or other things […] It doesn’t feel “open”, it feels very closed. Mehr lesen: https://yoast.com/weekly-seo-recap-41/
  59. 59. Mehr lesen: http://pa.ag/1WW4uaN & http://pa.ag/1H4NacR
  60. 60. Und das Allerschlimmste? Meine Prognose: Im Laufe von 2016 wird Google Folgendes ankündigen: We are using AMP in mobile search rankings: You may have heard that here at Google we're obsessed with speed. As part of that effort, today we're including a new signal in our search ranking algorithms: The usage of accelerated mobile pages (AMP) for even faster results in mobile search results!
  61. 61. Das neue Protokoll des WWWs #7 Das HTTP/2 Protokoll
  62. 62. Browser Support: HTTP/2 ist angekommen! 1 = IE nur mit Win 10; 2 = nur mit HTTPS Quelle: http://caniuse.com/#feat=http2
  63. 63. Server Support: HTTP/2 mit 80%+ Marktabdeckung Apache 2, nginx, IIS, Netty, Jetty, Squid & 50 andere sind verfügbar! Quellen: http://pa.ag/1Pwa8fy & http://pa.ag/1Pwa8fy
  64. 64. Demo-Time: 200 „kleine“ Bilder im Protokollvergleich: Bspw. priorisierte Bundles von Requests bringen massive Verbesserungen! Ausprobieren: http://www.http2demo.io/ & https://http2.akamai.com/demo
  65. 65. Was bringt‘s für eure Website? Einfach ausprobieren: Alle Assets werden heruntergeladen & im Direktvergleich ausgeliefert. Ausprobieren: http://http2.loadimpact.com/entry/
  66. 66. Googlebot mit HTTP/2 Support zum Jahreswechsel! Noch(!) kein Vorteil bei der Auslieferung an Googles Crawler, aber: Quelle: http://pa.ag/1HTJCF4
  67. 67. Bastian Grimm bg@peakace.de twitter.com/peakaceag facebook.com/peakaceag peakace.de http://pa.ag/seokomm2015 Folien zum Herunterladen:

×