Spaces. Smartes Cloud Hosting für anspruchsvolle Webprojekte. Loslegen und Spaces testen. Von Mittwald.
Andreas Hecht 18. August 2016

Behoben: Google Analytics und die Warnung “Leverage Browser Caching”

Google Analytics: “Leverage Browser Caching” Warnung beheben

Wenn du dei­ne Website auf Speed opti­mierst und dabei nach den Richtlinien von GooglePage Speed Insights vor­gehst, dann kennst du die­se Warnung. Aktiviere »Leverage Browser Caching« für das Google Analytics Script. Oftmals ist es gera­de die­se Warnung, die es ver­hin­dert, die berühm­ten 100 von 100 PageSpeed Punkte zu erhal­ten. Genau da liegt das Problem, wie kann man eine Datei cachen, die sich nicht auf dem eige­nen Server befin­det? Wir bie­ten dir heu­te drei Lösungsansätze.

Google Analytics: “Leverage Browser Caching” Warnung beheben

Google Analytics ist eine fei­ne Sache und immer noch das Tool der Wahl für jeden Nutzer, der den Traffic auf sei­ner Website genau­es­tens unter die Lupe neh­men möch­te. Allerdings kann das Script auch eini­ges Kopfzerbrechen berei­ten, wenn man sei­ne Website gern auf die berühm­ten 100 Punkte von GooglePage Speed opti­mie­ren möch­te.

Problematisch ist, dass eini­ge der von Google gewünsch­ten und emp­foh­le­nen Punkte dei­nen Blog nicht beschleu­ni­gen wer­den und daher nicht emp­feh­lens­wert sind. Wenn du zum Beispiel dein kom­plet­tes CSS (zumeist meh­re­re Dateien inklu­si­ve der Plugin Stylesheets) in das HTML inli­ne ein­fügst, dann gra­tu­liert Google dir zu die­ser Entscheidung.

Wenn du jedoch nur ein klei­nes und durch eine Versionierung her­vor­ra­gend cach­ba­res Stylesheet im Header hast und den Rest des CSS im Footer, dann ver­sucht Google dir mit­zu­tei­len, dass dies dei­ne Seite lang­sa­mer macht. Natürlich ist das Gegenteil der Fall.

So ver­hält es sich auch bei dem Google Analytics Fehler. Das Script wird von Google für zwei Stunden gecacht. Google möch­te jedoch einen län­ge­ren Zeitraum haben. Das erhöht die Geschwindigkeit dei­ner Website eben­falls nicht.

google-analytics-leverage-browser-caching

Google bemän­gelt hier das zu kur­ze Caching des eige­nen Analytics-Scripts und zeigt daher nur maxi­mal 99 der begehr­ten 100 Punkte an. Um die­ses Problem zu lösen, bie­ten sich meh­re­re Möglichkeiten an. Drei davon stel­le ich Dir heu­te vor.

Bevor wir beginnen: Stelle sicher, dass du Browser Caching nutzt

Solltest du in dei­ner .htac­cess-Datei noch kei­nen Code für ein Caching ver­wen­den, dann wird es höchs­te Zeit. Denn ein­fa­ches Browser-Caching kom­bi­niert mit einer Kompression der Dateien sorgt bereits für einen ordent­li­chen Geschwindigkeitsschub. Hier fin­dest du den benö­tig­ten Code, füge ihn in die .htac­cess im Hauptverzeichnis dei­nes Blogs ein.

Lösung 1: Hoste das Analytics-Script lokal

Hoste das Script auf dei­nem Server. Diese Lösung ist ambi­va­lent. Auf der einen Seite behebt es den Fehler sofort und du bekommst die 100 Punkte läs­sig. Auf der ande­ren Seite ist es etwas auf­wän­dig, weil du sicher­stel­len musst, dass das Script upge­da­tet wird.

Mir erscheint die­se Lösung als sehr gut, denn ers­tens wird das Script auf mei­nem Server schnel­ler aus­ge­lie­fert, zwei­tens lässt es sich mit etwas Aufwand durch­aus auto­ma­tisch updaten – wenn du einen rich­ti­gen Cronjob auf dei­nem Hosting-Paket star­ten darfst.

Schritt 1: Analytics.js herunterladen

Lade dir das im Google Analytics Code ver­wen­de­te Script auf dei­nen Computer her­un­ter. Die URL ist die fol­gen­de:

https://www.google-analytics.com/analytics.js

Lade das Script in das Hauptverzeichnis von WordPress. Der neue Pfad zur Datei könn­te dann so aus­se­hen:

https://deinewebsite.de/analytics.js

Suche nun dei­nen Google Analytics Code im Theme oder in dei­nen Plugins. Solltest du ein Plugin ein­set­zen, dass dei­nen Analytics-Code dem Theme hin­zu­fügt, deak­ti­vie­re das auto­ma­ti­sche Hinzufügen in dein Theme. Ansonsten suche in der header.php oder der footer.php. Eventuell wirst du auch in der functions.php dei­nes Themes fün­dig.

Ersetze die Original-URL gegen dei­ne URL. Siehe Script:

Füge den bear­bei­te­ten Code in den Footer dei­nes Themes ein – in die footer.php ober­halb oder unter­halb von wp_footer();. Lade die Datei anschlie­ßend wie­der in dei­nen Theme-Ordner hoch.

Schritt 2: Erstelle ein Script, das dein lokales Script aktuell hält

Erstelle eine lee­re Datei und nen­ne sie analytics-update.php. Füge den fol­gen­den Code in die Datei ein.

Nun musst du die­se Update-Datei noch um den abso­lu­ten Pfad zu dei­ner Google-Analytics-Datei ergän­zen. Hierzu muss Zeile 6 der PHP-Datei ergänzt wer­den.

Um den abso­lu­ten Pfad zu ermit­teln, erstel­le eine lee­re Datei namens dir.php und kopie­re fol­gen­den Code hin­ein:

Kopiere die­se Datei in das Hauptverzeichnis dei­nes WordPress und rufe die Datei im Browser auf:

http://deinewebsite/dir.php

Der unte­re Pfad ist kor­rekt, kopie­re ihn und erset­ze damit die Angaben in der analytics-update.php in Zeile 6.

Lösche die dir.php im Anschluss wie­der von dei­nem Server, sie stellt ein Sicherheitsrisiko dar. Stelle nun sicher, dass bei­de Dateien auf dem Server beschreib­bar sind. Die Dateirechte CHMOD 755 soll­ten okay sein und funk­tio­nie­ren.

Nun musst du nur noch einen Cronjob erstel­len, der die analytics-update.php Datei ein­mal in der Woche auf­ruft. Das funk­tio­niert bei jedem Hoster und Betriebssystem anders, daher pos­te ich für die­sen Job kei­nen Code.

Sollte dein Webhoster kei­ne Cronjobs zulas­sen, dann nut­ze einen exter­nen Dienst wie zum Beispiel cronjob.de.

Weiterführende Informationen:

HowTo: Add Jobs To cron Under Linux or UNIX?

Das Endergebnis unserer Bemühungen

Durch das Hosten der Datei auf dem eige­nen Server kann die­se vom Browser in den Cache beför­dert wer­den und GooglePage Speed Insights zeigt nun die gewünsch­ten 100/100 Punkte an.

Der behobene Fehler des Google Analytics JavaScripts.

Lösung 2: Nutze ga-lite.js anstatt Google-Analytics.js

ga-lite ist eine abge­speck­te Version des Scripts von Google Analytics. Es wur­de auf Speed und opti­ma­les Browser-Caching ent­wi­ckelt und opti­miert. Es funk­tio­niert tadel­los und zeich­net die Grundfunktionen des Original-Codes von Google Analytics auf. Ein wei­te­rer Vorteil: das ga-lite.js Script lädt wesent­lich schnel­ler als das Original.

Wenn du nicht nur Google über­lis­ten willst, son­dern wirk­lich etwas für die Performance dei­ner Website tun willst, dann ist ga-lite rich­tig für dich.

Allerdings hat es zur­zeit auch Nachteile. Es kön­nen kei­ner­lei benut­zer­de­fi­nier­te Notierungen ver­wen­det wer­den. Die Bounce-Rate kann nicht ange­passt und Links nicht getrackt wer­den. Die IPs las­sen sich mitt­ler­wei­le jedoch anonym aus­zeich­nen.

Die Installation von ga-lite:

Füge den fol­gen­den Code in die footer.php dei­nes Themes ein, ober­halb oder unter­halb von wp_footer().

Auch mit ga-lite wirst du nun das gewünsch­te Ergebnis bei GooglePage Speed erhal­ten.

Lösung 3: Wir überlisten Google

Du ver­wen­dest einen ange­pass­ten Analytics-Code und die bei­den Lösungen oben kom­men nicht für dich infra­ge? Du willst alles so behal­ten wie es ist, aber trotz­dem die begehr­ten 100 Punkte für dein Ego?

Kein Problem, auch die Ego-Lösung ist im Angebot. Dazu ver­wen­den wir eine klei­ne PHP-Funktion, der den Google Analytics Code für PageSpeed Insights ein­fach »unsicht­bar« macht. Damit funk­tio­niert das Analytics.js pro­blem­los, außer auf der Seite von Google PageSpeed.

Ergänze dei­nen Analytics-Code fol­gen­der­ma­ßen:

Auch die­ser Code sorgt für die gewünsch­ten 100 Punkte, beschleu­nigt dei­ne Website jedoch nicht. Dieser Code ist nur für dein per­sön­li­ches Ego und erreicht die 100 Punkte ohne gro­ße Modifikationen.

Fazit:

Lösung eins erscheint mir per­sön­lich als die Beste, wird aller­dings nicht von Google emp­foh­len. Einsetzbar ist sie nur mit einem Cronjob, der die loka­le Datei immer aktu­ell hält. Ohne die­sen Schritt des Updates ist Lösung eins kei­nes­falls zu emp­feh­len. Lösung zwei ist ide­al, wenn du bis­her noch kei­ne Anpassungen am Google Analytics-Code gemacht hast und nur die Standard-Funktionen der Analyse-Software nutzt. Diese bekommst du wei­ter­hin ohne Probleme und schnel­ler wird dei­ne Website eben­falls.

Lösung drei funk­tio­niert eben­falls, ist jedoch aus mei­ner Sicht nicht zu emp­feh­len. Ich per­sön­lich wür­de lie­ber mit 99 Punkten oder weni­ger leben. Die Hauptsache ist doch, mei­ne Websites laden deut­lich unter­halb einer Sekunde.

Quelle: KeyCDN

Andreas Hecht

Andreas Hecht

entwickelt WordPress-Websites und bietet dir einen Website Sicherheit Service und einen Performance Service für deine Website. Außerdem ist er Spezialist für Onpage SEO und bringt Deine Website in die Top-Suchergebnisse von Google. Auf seinem Blog schreibt er über WordPress, SEO und Content SEO.

10 Kommentare

  1. Hallo Andreas,
    ich habe die Probleme mit goog­le-ana­ly­tics (2 Stunden). Jetzt habe ich dein Script aus­pro­biert “ga-lite”.
    Funktioniert lei­der nicht. Kommt die glei­che Meldung: https://www.googletagmanager.com/gtag/js?id=UA-109558606–2 (15 Minuten)
    https://ssl.google-analytics.com/ga.js (2 Stunden)
    https://www.google-analytics.com/analytics.js (2 Stunden)

    Muß ich an dem script irgend­was ändern, also evtl. die Laufzeit? Aber wo?

    vie­len Dank im Voraus
    Steffen

  2. War ein­fa­cher als gedacht. Mein Factoring Portal lädt jetzt 1 Sekunde schnel­ler, naja sagt zumin­des­tens die Analyse. Bei Pagespeed gab es 10 Punkte mehr. Danke für die Hilfestellung!

  3. Danke für die Informationen, wird gera­de umge­setzt.

  4. Hallo Torsten,
    man kann den Code des Ladens von GTM aus analytics.js mit einem str_replace über­schrei­ben beim Laden des Files per Cronjob. Dann ein­fach einen zwei­ten Cronjob für den GTM hin­zu­fü­gen und den ent­spre­chen­den Pfad inkl. Domain der Resource im str_replace ein­bau­en. Habe das bereits für Typo3 so gemacht und es funk­tio­niert.
    Natürlich muss das jeweils im 1. Cronjob wie­der gemacht (also immer dann, wenn analytics.js gezo­gen wird).

  5. Hallo,

    erst mal vie­len Dank für die­sen Artikel, sehr nice und bringt einen wei­ter. Vor allem Möglichkeit 1 fin­de ich soli­de und sau­ber.

    Aber ich habe eine Frage dazu: Ist das kon­form mit den Google-Richtlinien?

    Ich wür­de das näm­lich auch ger­ne für die Datei https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js machen, habe aber natür­lich wenig Bock, das das gegen irgend­wel­che “Terms of Use” oder so ver­stößt und einem dann der Account sus­pen­diert wird oder so…

    Weiß da jemand genaue­res? :)

    Viele Grüße!

    • Meines Wissens nach ver­stößt das loka­le Hosten der Dateien gegen kei­ne Google-Richtlinien, denn sie wer­den ja unver­än­dert wei­ter­ge­nutzt. Nur eben nicht mehr von Google direkt auf­ge­ru­fen.

  6. Hi Andreas,
    soweit so gut. Den Code für’s Caching ins htac­cess instal­liert, Website nun wirk­lich schnel­ler!
    Deine Erklärungen zum Leverage Browser Caching sind gut erklärt. Jedoch hat jede Deiner Lösungsvorschläge klei­ne Nachteile, die ich nicht unbe­dingt berück­sich­ti­gen will. Daher ver­zich­te ich lie­ber auf die 100 Score-Punkte (im Augenblick sind es GTmetrix 84% PageSpeed und YSlow 80%). Die ande­ren Mängel soll­te ich in den Griff bekom­men. Jedenfalls teilt mir GTmetrix neben Google Analytics noch unter Leverage Browser Caching mit, dass der “Google Tag Manager” 15 minu­tes eben­falls ange­passt wer­den soll­te. Fällt die­se Lösung dafür eben­falls in die Optimierung des Scripts?

    Zwar hat­te ich irgend­wann mal den Tag Manager instal­liert, jedoch noch kei­ner­lei prak­ti­sche Ansätze für mich und mei­ne Website ent­de­cken kön­nen. Hatte wohl nicht die Muße zum Studieren der Vorteile des Tag Managers. Denke da ans “ganz Verzichten” des Tag Managers. Obwohl mei­ne Seite irgend­wann mal meh­re­re hun­dert Unterseiten haben wird. Was meinst Du?

    Grüße,
    Torsten

    • Google Tag Manager: Wie willst Du etwas auf Deinem Server mit­tels .htac­cess opti­mie­ren, das nicht auf Deinem Server liegt? Da schlägt doch schon die Logik zu :-) Und ob Du den Kram brauchst musst Du Dir beant­wor­ten. Die per­sön­li­chen Anforderungen an eine Website sind halt sehr ver­schie­den.

      • Danke für Deine promp­te Antwort. Ich hat­te ledig­lich von Pingdom + GTmetrix die Meldung erhal­ten, dass der Tag Manager auf mei­ner Website eine zu kur­ze “fresh­ness life­time” hat. Wie ich die­sen Fall nun zu opti­mie­ren habe, dar­über bin ich mir eben nicht im Klaren, wie das anzu­stel­len ist. Genau das war halt mei­ne Frage an Dich. Falls ich kei­ne nach­zu­voll­zie­hen­de Lösung fin­de, schmei­ße ich ihn wahr­schein­lich raus.

      • Du kannst kei­ne Lösung auf Deinem Server fin­den für ein Script, das NICHT auf Deinem Server liegt. Genau das schrieb ich Dir doch eben:-)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.