Was Sie beachten sollten um die Ladezeiten Ihrer WordPress Webseite zu verbessern

Hinweis: DIESER ARTIKEL WIRD AKTUELL ÜBERARBEITET UND IST NICHT VOLLSTÄNDIG!
Nicht alles muss zutref­fen, es ist von Website zu Website anders! Jeder Website ist einzigartig.

Facebook und Social-Sharing Buttons raus!

Facebook-Widgets ver­lang­sa­men Seiten im 1‑Sekunden-Bereich. Social-Links ver­ur­sa­chen glo­ba­len Site-Drag.
Sie ver­dop­peln oder ver­drei­fa­chen die Ladezeiten für alle Seiten. Das muss nicht sein.

Es gibt Alternativen: Schnellere sta­ti­sche Bild-Links anstel­le von dyna­mi­schen Zählern sind bes­ser als die lang­sa­men Widgets von Drittanbietern.

Google Analytics

Big Data (Tonnen von Metriken) ist in den Meisten Fällen rei­ne Zeitverschwendung. Großartig für gewis­se Zwecke, jedoch sehen vie­le Website-Besitzer sie sich nicht an – nie­mals. Sie wis­sen auch nicht, wie man sie abru­fen oder sie inter­pre­tie­ren kann.

Diese Google Analytics-Skripte und Beacons ver­lang­sa­men die Seiten der Website erheb­lich. Besonders wenn die Google Cloud die Verbindung nicht ohne Verzögerung herstellt.

Google Analytics macht etwas, was sehr frag­wür­dig ist:

Die Google-Stats-Abteilung emp­fiehlt, den Tracking-Code in den WordPress-Header zu set­zen. So gehen kei­ne "Daten ver­lo­ren", wenn jemand Ihre Seite ver­lässt bevor sie voll­stän­dig gela­den ist.

Die "Performance"-Abteilung von Google emp­fiehlt jedoch, den Tracking-Code zuletzt – am Ende – ein­zu­fü­gen. Dies eli­mi­niert "java­script ren­der blocking".

Google Analytics-Skripte haben außer­dem eine unge­wöhn­lich kur­ze Cache-Verfallszeit von 2 Stunden. Das ist kei­ne Best Practice und führt zu schlech­ten Geschwindigkeitswerten bei Tests. Eine weit­rei­chen­de Verfallszeit ist am bes­ten auf 365 Tage ein­ge­stellt. Google nutzt nicht die Best Practices, die sie bei ihren eige­nen PageSpeed Insights emp­feh­len.. Seltsam!

Welcher Weg ist also der beste?

Ich emp­feh­le: In die Fußzeile, für schnel­le­re Ladezeiten. Wenn Sie der Meinung sind, dass Sie Google Analytics ver­wen­den müs­sen, instal­lie­ren Sie das Complete Analytics Optimization Suite (CAOS) Plugin. Es ermög­licht Ihnen die Optimierung von Google Analytics.

Content Delivery Network (CDN)

Viele WordPress-Seiten nut­zen kos­ten­lo­se CDN-Dienste. Der Irrglaube ist, dass davon aus­ge­gan­gen wird, dass die Dinge bes­ser und schnel­ler lau­fen wer­den mit einem CDN. Jedoch ver­ur­sacht es vie­le Arten von Verzögerungen und Serverfehlern, da es in den meis­ten Fällen falsch kon­fi­gu­riert ist. Also wenn Sie nicht wis­sen was Sie tun, dann Finger weg von CDN’s.

Google Fonts

Externe Schriftskripte wie Typekit oder Google Fonts ver­lang­sa­men die Geschwindigkeit der Website erheb­lich. Typekit ist das schlech­tes­te für die Geschwindigkeit.

Google Fonts ver­ur­sacht eine 1‑sekündige Verzögerung. 
Genau wie Font Awesome. Warum das so ist? Niemand weiß es. Fragen Sie Google.

Und, natür­lich, je mehr Schriften Sie auf­ru­fen, des­to lang­sa­mer wer­den die Seiten. Google ruft sei­ne CSS-Dateien jedes Mal auf, da die­se Schriften mit einer Verfallszeit von einem Tag zur Verfügung gestellt wer­den. Google nennt dies “Font freshness”.

Weiterhin wird gesagt: "Es ist für die schnel­le Unterstützung von Schriftartänderungen." Jede Schriftart ändert sich jeden Tag? Tägliche Updates? Echt jetzt? So schnell geht das nicht.

Ironischerweise fal­len die Google Fonts bei Googles eige­nem PageSpeed-Test durch. Er gene­riert einen Fehler: "Eliminieren Sie Render-Blocking-JavaScript und CSS in above-the-fold-Inhalten."

Google behaup­tet, den PageSpeed zu befür­wor­ten. Aber sie cachen nicht ein­mal ihre eige­nen Schriftarten! Warum? Eine schö­ne Gelegenheit zum Erfassen von Daten. Wachen Sie auf. Es ist zu deren Vorteil – nicht zu Ihrem.

Die eigent­li­che Theorie: Wenn Millionen von Websites alle auf die­sel­ben Schriftarten ver­lin­ken, wer­den die­se "idea­ler­wei­se" zwi­schen­ge­spei­chert. Nachdem die ers­te Schriftart gela­den wur­de, soll­te sie "sofort" auf allen ande­ren spä­ter besuch­ten Seiten erschei­nen. Das ist aber nicht in allen oder sogar in den meis­ten Fällen der Fall. Google sieht eine CSS-Anfrage pro Schriftfamilie, pro Tag, pro Nutzer, pro Browser.