Hinweis: DIESER ARTIKEL WIRD AKTUELL ÜBERARBEITET UND IST NICHT VOLLSTÄNDIG!
Nicht alles muss zutreffen, es ist von Website zu Website anders! Jeder Website ist einzigartig.
Facebook und Social-Sharing Buttons raus!
Facebook-Widgets verlangsamen Seiten im 1‑Sekunden-Bereich. Social-Links verursachen globalen Site-Drag.
Sie verdoppeln oder verdreifachen die Ladezeiten für alle Seiten. Das muss nicht sein.
Es gibt Alternativen: Schnellere statische Bild-Links anstelle von dynamischen Zählern sind besser als die langsamen Widgets von Drittanbietern.
Google Analytics
Big Data (Tonnen von Metriken) ist in den Meisten Fällen reine Zeitverschwendung. Großartig für gewisse Zwecke, jedoch sehen viele Website-Besitzer sie sich nicht an – niemals. Sie wissen auch nicht, wie man sie abrufen oder sie interpretieren kann.
Diese Google Analytics-Skripte und Beacons verlangsamen die Seiten der Website erheblich. Besonders wenn die Google Cloud die Verbindung nicht ohne Verzögerung herstellt.
Google Analytics macht etwas, was sehr fragwürdig ist:
Die Google-Stats-Abteilung empfiehlt, den Tracking-Code in den WordPress-Header zu setzen. So gehen keine "Daten verloren", wenn jemand Ihre Seite verlässt bevor sie vollständig geladen ist.
Die "Performance"-Abteilung von Google empfiehlt jedoch, den Tracking-Code zuletzt – am Ende – einzufügen. Dies eliminiert "javascript render blocking".
Google Analytics-Skripte haben außerdem eine ungewöhnlich kurze Cache-Verfallszeit von 2 Stunden. Das ist keine Best Practice und führt zu schlechten Geschwindigkeitswerten bei Tests. Eine weitreichende Verfallszeit ist am besten auf 365 Tage eingestellt. Google nutzt nicht die Best Practices, die sie bei ihren eigenen PageSpeed Insights empfehlen.. Seltsam!
Welcher Weg ist also der beste?
Ich empfehle: In die Fußzeile, für schnellere Ladezeiten. Wenn Sie der Meinung sind, dass Sie Google Analytics verwenden müssen, installieren Sie das Complete Analytics Optimization Suite (CAOS) Plugin. Es ermöglicht Ihnen die Optimierung von Google Analytics.
Content Delivery Network (CDN)
Viele WordPress-Seiten nutzen kostenlose CDN-Dienste. Der Irrglaube ist, dass davon ausgegangen wird, dass die Dinge besser und schneller laufen werden mit einem CDN. Jedoch verursacht es viele Arten von Verzögerungen und Serverfehlern, da es in den meisten Fällen falsch konfiguriert ist. Also wenn Sie nicht wissen was Sie tun, dann Finger weg von CDN’s.
Google Fonts
Externe Schriftskripte wie Typekit oder Google Fonts verlangsamen die Geschwindigkeit der Website erheblich. Typekit ist das schlechteste für die Geschwindigkeit.
Google Fonts verursacht eine 1‑sekündige Verzögerung.
Genau wie Font Awesome. Warum das so ist? Niemand weiß es. Fragen Sie Google.
Und, natürlich, je mehr Schriften Sie aufrufen, desto langsamer werden die Seiten. Google ruft seine CSS-Dateien jedes Mal auf, da diese Schriften mit einer Verfallszeit von einem Tag zur Verfügung gestellt werden. Google nennt dies “Font freshness”.
Weiterhin wird gesagt: "Es ist für die schnelle Unterstützung von Schriftartänderungen." Jede Schriftart ändert sich jeden Tag? Tägliche Updates? Echt jetzt? So schnell geht das nicht.
Ironischerweise fallen die Google Fonts bei Googles eigenem PageSpeed-Test durch. Er generiert einen Fehler: "Eliminieren Sie Render-Blocking-JavaScript und CSS in above-the-fold-Inhalten."
Google behauptet, den PageSpeed zu befürworten. Aber sie cachen nicht einmal ihre eigenen Schriftarten! Warum? Eine schöne Gelegenheit zum Erfassen von Daten. Wachen Sie auf. Es ist zu deren Vorteil – nicht zu Ihrem.
Die eigentliche Theorie: Wenn Millionen von Websites alle auf dieselben Schriftarten verlinken, werden diese "idealerweise" zwischengespeichert. Nachdem die erste Schriftart geladen wurde, sollte sie "sofort" auf allen anderen später besuchten Seiten erscheinen. Das ist aber nicht in allen oder sogar in den meisten Fällen der Fall. Google sieht eine CSS-Anfrage pro Schriftfamilie, pro Tag, pro Nutzer, pro Browser.