PageSpeed, Kompression & Co

[neelix]

Hallo zusammen,

ich verzweifel hier gerade mit einem 1&1 Hosting eine vernünftige Punktzahl bei PageSpeed zu bekommen (mit > 80 wäre ich ja schon zufrieden). Aber ich kann machen was ich will, Google behauptet steif und fest Komprimierung wäre nicht aktiv. Dabei melden alle möglichen anderen Test, dass sie durchaus aktiviert ist.
Könnte das bitte mal jemand neutral prüfen. Danke.

Das Paket ist ein 1&1 Business 5.0 (macht es Sinn auf ein neueres Produkt zu wechseln? Oder besser gleich den Hoster?)

URL: http://www.coachingundberatung.eu/cms-dev

Der 1&1 Website Check ist durchaus zufrieden mit der Seite.

Danke & Gruß

Neelix

[tab]

Das ist wohl das alte 1&1 Lied ... Das hier funktioniert bei meinen Kunden ...
https://community.contao.org/de/show...l=1#post331026

Hierbei ist zu beachten, dass nicht von Contao erzeugtes bzw zusammengefasstes Javascript und CSS NICHT von Contao komprimiert wird. Da muss man selbst ran mit gzip. Das betrifft bei dir alle angemeckerten Ressourcen bis auf das zusammengefasste CSS. Es werden natürlich durch die Direktiven in der .htaccess nur komprimierte Dateien ausgeliefert, die auch als .gz vorliegen. Fehlt die komprimierte Datei, wird die unkomprimierte Version ausgeliefert. Ganz ehrlich, wenn man viele Javascript-Dateien ausliefern muss, macht das nicht wirklich Spass. Aber es funktioniert wenigstens.
Die jQuery Bibliothek selbst kannst du ja lokal ausliefern lassen und dann auch selbst komprimieren.

In neueren Paketen soll es wohl mod_deflate geben, ich habe aber selbst noch keins gesehen. Allerdings habe ich mit den letzten zwei "Generationen" von 1&1 Shared Hosting Paketen auch nicht gearbeitet bzw immer gleich automatisch gewohnheitsmäßig den Workaround genommen und es deshalb eventuell gar nicht bemerkt. Frag mal beim 1&1 Support nach, ob es da jetzt mod_deflate gibt. 1&1 Business 5.0 ist ein Paket aus 2004, da kann man schon davon ausgehen, dass es selbst bei 1&1 mittlerweile was Besseres gibt. Persönlich würde ich es bevorzugen den Hoster zu wechseln, aber wenn es mit einem Paket-Upgrade auf ein neueres 1&1 Paket zu lösen ist, sparst du dir eben den gesamten Umzugsaufwand.

[neelix]

Das habe ich alles schon durchprobiert.

Wo müssten die Gzip-Versionen der Dateien liegen, ich finde nämlich keine im Dateisystem.
Mein CSS habe ich komplett über den internen Editor erstellt.

[tab]

Die Gzip-Versionen müssen im selben Verzeichnis sein wie die unkomprimierten. Bis auf die eine, die von Contao erzeugt wird, musst du alle selbst mit gzip komprimieren.

[neelix]

also unter assets/css, da liegt aber nix.

[tab]

In den Einstellungen im Backend ist Skripte komprimieren aktiviert? Dann eventuell mal neu erzeugen lassen in der Systemwartung.

[neelix]

So, also mod_deflate greift 100% nicht. Sonst müsste er die min.js von JQuery on thy fly komprimieren.
Meine eigene CSS liefert er jetzt zumindest schon mal als gz aus.

[tab]

Ja, alle anderen musst du von Hand auf der Kommandozeile oder lokal mit gzip komprimieren. die jQuery kannst du umstellen, so dass sie auch vom Server ausgeliefert wird und nicht vom CDN und dann die entsprechende ausgelieferte Datei ebenfalls komprimieren.

[neelix]

Das JQuery aus dem CDN meckert er gar nicht an, das kommt nämlich als gzip.

In neueren Paketen soll es wohl mod_deflate geben, ich habe aber selbst noch keins gesehen. Allerdings habe ich mit den letzten zwei "Generationen" von 1&1 Shared Hosting Paketen auch nicht gearbeitet bzw immer gleich automatisch gewohnheitsmäßig den Workaround genommen und es deshalb eventuell gar nicht bemerkt.

Kann da jemand was zu sagen? Unterstützen die neuen Hostingtarife bei 1&1 jetzt auch mod_deflate und am besten noch mod_cache?

[folkfreund]

@tab: Danke für den Link mit der Beschreibung für Anpassungen, die bei uberspace nötig sind.
Wie sieht es denn bei Contao 4.4 aus? In der .htaccess gibt es ja den betreffenden Abschnitt nicht mehr...

[tab]

Ich denke das Fehlen vieler Abschnitte aus der "alten" .htaccess aus Contao 3.5 liegt nicht daran, dass man diese nicht mehr brauchen würde oder dass sie nicht mehr funktionieren würden. Es ist einfach so, dass man das in Contao 4 weitgehend dem Web-Developer selbst überlassen hat. Viele der jetzt "fehlenden" Abschnitte machden durchaus auch für Contao 4 noch Sinn.