Druckbare Version
Ich habe bei einigen Contao Seiten keine Kompression. In der htaccess wird diese angefordert über die if Abfrage <IfModule mod_deflate.c> und <IfModule mod_filter.c>
Wenn ich die Abfrage lösche, wird komprimiert laut google pagespeed.
Aber mit der if Abfrage geht es nicht. Das macht doch keinen Sinn oder?!
So einen Fall hatte ich auch schon. Also im speziellen war das mod_deflate Modul vorhanden, komprimiert wurde aber nur, wenn ich die Abfrage auf mod_filter deaktiviert hatte - normalerweise sollte das entweder zu einem Fehler führen oder die Dateien würden gar nicht komprimiert werden. Tatsächlich werden sie aber trotz vermeintlich fehlendem mod_filter Modul komprimiert.
Das ist bei uberspace teilweise auch so, offenbar ist da die Funktionalität Teil des Apache. Ich zitiere mal aus der dortigen Doku:
Zitat:
Bei vielen Anleitungen und Beispielen, die sich im Netz finden lassen, wird die Anweisung per IfModule mod_filter.c bedingt. Das ist dann ein Problem, wenn du auf einem unserer älteren Hosts arbeitest, auf dem Apache 2.2 läuft. In dieser Version gab es den mod_filter noch nicht, sondern die Funktionalität war im Apache fest verbaut. In dem Fall entferne bitte die Bedingung, dann klappt es auch mit der Kompression. Ab Version 2.3.7 klappt es mit dem IfModule und du musst nichts weiter tun.
Bei 1und1 ist es ebenfalls so. Zumindest bei den Shared Paketen
Huh? Hat 1&1 neuerdings mod_deflate aktiv? Die letzten Jahre gabs das da nicht wegen Performanceproblemen, lässt ja tief blicken. ;)
ach krass. Ja danke für die Info. Kam mir schon alles spanisch vor, weil deflate auf jedenfall vorhanden ist.
Dann kann ich ja gleich 6 Webseiten mal updaten und schneller machen.
Darf ich mal ganz frech was anderes fragen....
der Speedtest ist mit 60-70 wirklich fies.
Die Bilder optimieren... ja gut das muss man auch ignorieren können, so optimal kann man die nie komprimieren das die noch gut ausschauen.
Aber JavaScript und CSS-Ressourcen, die das Rendering blockieren lassen mich grübeln. Contao 3 ist ja schon flink und optimiert, aber wieso werden diese temporären Files
/assets/js/eb66dbaa7e8a.js
/assets/css/501c81ebe21c.css
vom Speedtest kritisiert ? Genau die sollen doch den Speed erhöhen.
Die Kritik an den CSS und JS Dateien basiert darauf, dass diese Dateien ja separat heruntergeladen werden müssen und deren Inhalte benötigt werden, um die Seite aufzubauen. Das heißt, der Browser hat einen Großteil des Seitenquelltexts runtergeladen oder gar alles, aber er kann nicht anfangen die Seite aufzubauen, weil er eben das CSS und/oder Javascript dafür kennen müsste. Vermeiden kann man das zum Beispiel, indem man das benötigte CSS direkt in den Quellcode schreibt, also als <style> Tag im <head>. Fürs optimieren der Bilder gibt es Tools wie JPG Mini oder auch das Plugin in Irfanview. Google pagespeed selbst bietet auch optimierte Dateien zum Download an, nachdem die Seite analysiert wurde. Das kann schon einiges an Daten einsparen.
Sieh' dir die Links von PageSpeed Insights genauer an, da geht es nicht unbedingt darum sie schlechter aussehen zu lassen. zB: https://developers.google.com/web/fu...e-optimizationZitat:
Zitat von izanagi
Genau das was Page Speed sagt: sie sind Render Blocking ;). CSS und JavaScript Ressourcen im <head> blockieren das Rendern der Seite, bis diese Ressourcen geladen sind. Idealerweise sollte nur das nötige CSS und JS im <head> geladen werden, das für den "Above the fold content" gebraucht wird.Zitat:
Zitat von izanagi
Ich bin darüber auch schon mehrfach gestolpert.Zitat:
Zitat von Spooky
Wie handhabt ihr das in der Praxis insbesondere beim css. Persönlich habe ich diese Hinweise bisher ingnoriert. Allerdings war der der Performance-Test der Seiten auch zufriedenstellend (Werte um 95% bei Pagespeed).
Gar nicht, außer der Kunde bezahlt diese Optimierung. Dann würd ich das einfach manuell auftrennen.Zitat:
Zitat von mlweb
Ich weiss was du meinst, die Grafiken hier sind aber bereits in der Konzeption gewählt und unter optimalen Bedingungen komprimiert. Zum Beispiel sind es Diagramme vom Kunden, deren Beschriftungstexte gut lesbar sein müssen, hier ist 8bit PNG die beste Wahl und bereits ein Ersparnis von 60% gegenüber jpg. Irgendwo muss man auch die Kirche im Dorf lassen. Hier steht es geht um 46KB im gesamten, verteilt auf 14 Bildern. :rolleyes:Zitat:
Zitat von Spooky
Ich habe auch Kunden mit hochauflösenden Bildern, da kannst du auch nichts machen. Insbesondere Shops sind sehr Datenlastig. Man kann auch nicht technisch einen Sprung 10 Jahre zurück machen. Bissle nervt das Thema, Google ist viel zu streng.
Eine Kollegin hat eine Contao Vereinsseite gerade fertig gemacht, die hat 22 von 100 Punkten. Die weiss von ihrem Glück noch nichts :D
Thema Renderblocking, hab ich mich bisher noch nicht drum gekümmert. Ich hatte jetzt von der Trennung des critical /noncritical CSS gelesen was ja garnicht so tragisch ist. Vielleicht reicht es auch einfach das CSS am Ende des Bodytags zu laden.
(PS: es gibt eine cssLoad Funktion die man nutzen kann, gibt es bei github.)
Bei JS bin ich nicht sicher weil viele Funktionen bereits vor Laden des Contents zur Verfügung stehen müssen. Die Aufsplittung sehe ich da eher als kompliziert.
Ganz fies sind ja externe JS und CSS Dateien für Plugins & co. Die nach ganz unten zu verlagern ist fummelsarbeit weil der Contao Core bereits an festen Positionen die Ausgabe der Plugins macht.
Also ich habe jetzt nach dem Komprimieren deflate 83/100 Punkten.
Dennoch meckert er bei der Komprimierung des "root" das dort 70% gespart werden könnte. Hö?! Wie soll das Wurzelverzeichnis komprimiert werden. Meint er die HTML Inhalte damit ?! Oder die Startseite im allgemeinen.
Antwortzeit des Server 1,3 sek. dann wieder 0.5 sek. naja :(
Die Stylesheet Ausgabe hab ich im Template nun nach unten gesetzt. Jetzt haben wir 86/100 und sind im grünen Bereich.
Die js aus dem assets konnte ich nur verlegen wenn ich die head-ausgabe im template runter setze. Brachte beim Mobile-Speedtest Besserung von 79 auf 93 Punkten.
ich sehe die Verschiebung der Head Ausgabe aber als kritisch.
Ich belasse es jetzt bei der Optimierung auf 86 Punkten Desktop und 79 Punkten Mobile. Orange ist definitiv schöner als rot.
Nein, ich meine zB die Optimierung mit optipng und jpegtran. Das kann man zwar bei den Originalbildern selbst machen, bei den von Contao generierten Bildern fehlt jedoch meist dann die Optimierung.Zitat:
Zitat von izanagi
Meistens kann man das komplette JavaScript an das ende des <body> geben (kommt halt darauf an). mit Extensions wie Theme+ oder Contao Supertheme kannst du das zB automatisch erledigen lassen.Zitat:
Zitat von izanagi
? Wie genau lautet die Meldung?Zitat:
Zitat von izanagi
Da hilft nur teurere Hosting Pakete nehmen ;)Zitat:
Zitat von izanagi
Wie bereits von Spooky geschrieben, es geht nicht darum, dass die absolute Größe der Bilder zuviel ist, du kannst auch ein 3000x2000 Bild benutzen, ohne dass Google meckert, solange es nach Meinung von Google nicht ohne Qualitätsverlust weniger Daten haben könnte. Naja, jedenfalls an dieser Stelle. 22 von 100 ist gut!! Die Galerieseite eines meiner Vereine - nicht von mir erstellt ;) - hat satte 0 von 100, mobil wie auch Desktop. Logisch irgendwie, alle Thumbnails bestehen aus den Originalbildern, die der Browser dann runterrechnet. Da ist Google dann absolut humorlos, 99,x % können eingespart werden. Da das dann bei zig Vorschaubildern so ist, lautet das Urteil: Setzen! 6! Andere, textbasierte Seiten sind aber recht gut bewertet, ist halt auch statisches HTML mit nur einem Hauch von CSS. Das ist in dem Fall auch völlig egal, wer nach einem entsprechenden Verein in dem Ort sucht, wird nur diese Seite finden, es gibt einfach keine andere. Also Konkurrenz praktisch Null. Und solange es den Mitgliedern gefällt, halte ich mich da zurück. Vielleicht schreibe ich irgendwann mal ein wenig CSS gegen Augenkrebs, mal sehen.Zitat:
Zitat von izanagi
Abgewertet wird die Site mit 86 Punkten wohl noch nicht. Von den fehlenden bis 100 sind wahrscheinlich mindestens 6-7 für deine Bilder. Je nachdem, wieviel da insgesamt eingespart werden könnte nach Googles Meinung. Google meckert manchmal auch, wenn eine 100 Byte Datei 10 Bytes zu groß ist. Aber das macht dann keinen Unterschied in der Bewertung. Wenig Einsparpotenzial - wenig Punktverlust, viel Einsparpotenzial - viel Punktverlust. Das wird also schon auch berücksichtigt.Zitat:
Zitat von izanagi
@spooky
optipng und jpegtran sind doch Kommandozeilen-Tools oder? Ich arbeite nur mit Adobe daher kenne ich die beiden nicht.
Was Google bzw. Algorythmen von "ohne Qualitätsverlust" verstehen ist so wie einem Roboter beibringen was Liebe ist :)
Mein qualitatives Auge ist schon etwas geschulter als eine Rechnung von Kompressionswerten. Ich muss mich ja darauf verlassen das es der gewünschten Qualität entspricht.
Ich lass mich aber gern von jpegtran beeindrucken wenn es da was kann.
Folgendes wird noch bemeckert:
Und die Komprimierung läuft eigentlich.PHP-Code:Entfernen Sie JavaScript, das das Rendering blockiert:
/assets/js/eb66dbaa7e8a.js
Durch die Reduzierung von http://domain.tv/ könnten 3,3 KB (18 %) eingespart werden.
Durch die Komprimierung von http://domain.tv/ könnten 13,5 KB (72 %) eingespart werden.
@tab also wenn du bei 22 Punkten schon "gut" sagst... dann bin ich aber mehr als beruhigt :D
Die restlichen Punkten zu 100 sind definitiv die Serverreaktionen und die Scripte sowie CSS Dateien.
Er wünscht sich auch z.b. komprimierungen bei uncludierten Webfonts oder auch Scripten von absoluten Pfaden dritter Anbieter (jquery, extensions, google) da hab ich keinen Einfluss ausser ich speicher die klamotte auf dem Server und da hat man wirklich keine Lust in den Templates oder den Erweiterungen rumzufummeln.
Wenn der Kunde dafür bezahlt, okey.... dann kann man da mal nachsehen.
Äh.. ne, die machen einiges, was das 'drum herum' angeht.Zitat:
Zitat von izanagi
Hier kannst du nachlesen was z.B. optipng macht: https://wiki.ubuntuusers.de/optipng/
Das entfernt also einfach nur unnötige Informationen zu dem Bild (und auch unnötige Farben, die eh nicht vorkommen). Da kannst du mit deinem geschulten Auge auch keinen Unterschied sehen, da es keinen gibt :P
Viele Grüße
Ja, das sind command line tools, gibt es aber tlw. auch mit GUI.Zitat:
Zitat von izanagi
Nein, Google und diese Algorithmen von jpegtran und optipng bspw. meinen tatsächlich ohne Qualitätsverlust. Hier geht es nicht darum das Bild "optisch" zu komprimieren, sondern bspw. unnötige Informationen aus den Dateien zu entfernen und die Datei selbst besser zu komprimieren - ohne die eigentlichen Pixelinformationen zu ändern.Zitat:
Zitat von izanagi
Poste mal deine .htaccess.Zitat:
Zitat von izanagi
Für einen Webdeveloper ist das allerdings ganz normal ;)Zitat:
Zitat von izanagi
Okey überredet, das werde ich mir mal genauer ansehen.Zitat:
Zitat von Spooky
Zitat:
Zitat von Spooky
Code:<FilesMatch "\.(tpl|html5|xhtml)$">
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
</FilesMatch>
<IfModule mod_headers.c>
<FilesMatch "\.(ttf|ttc|otf|eot|woff2?|font\.css)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>
FileETag None
<IfModule mod_headers.c>
Header unset ETag
</IfModule>
<IfModule mod_mime.c>
AddType application/javascript js jsonp
AddType application/json json
AddType audio/ogg oga ogg
AddType audio/mp4 m4a f4a f4b
AddType video/ogg ogv
AddType video/mp4 mp4 m4v f4v f4p
AddType video/webm webm
AddType video/x-flv flv
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
AddType application/vnd.ms-fontobject eot
AddType application/x-font-ttf ttf ttc
AddType font/opentype otf
AddType application/x-font-woff woff woff2
AddType image/x-icon ico
AddType image/webp webp
AddType text/cache-manifest appcache manifest
AddType text/x-component htc
AddType application/xml rss atom xml rdf
AddType application/x-web-app-manifest+json webapp
AddType text/x-vcard vcf
AddType application/x-shockwave-flash swf
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/css application/json
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE text/xml application/xml text/x-component
AddOutputFilterByType DEFLATE application/xhtml+xml application/rss+xml application/atom+xml
AddOutputFilterByType DEFLATE image/x-icon image/svg+xml application/vnd.ms-fontobject application/x-font-ttf font/opentype
<
</IfModule>
<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType text/cache-manifest "access plus 0 seconds"
ExpiresByType text/html "access plus 0 seconds"
ExpiresByType text/xml "access plus 0 seconds"
ExpiresByType application/xml "access plus 0 seconds"
ExpiresByType application/json "access plus 0 seconds"
ExpiresByType application/rss+xml "access plus 1 hour"
ExpiresByType application/atom+xml "access plus 1 hour"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType video/ogg "access plus 1 month"
ExpiresByType audio/ogg "access plus 1 month"
ExpiresByType video/mp4 "access plus 1 month"
ExpiresByType video/webm "access plus 1 month"
ExpiresByType text/x-component "access plus 1 month"
ExpiresByType application/x-font-ttf "access plus 1 month"
ExpiresByType font/opentype "access plus 1 month"
ExpiresByType application/x-font-woff "access plus 1 month"
ExpiresByType image/svg+xml "access plus 1 month"
ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
</IfModule>
<IfModule mod_headers.c>
<FilesMatch "cron\.txt$">
Header set Cache-Control "no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, no-transform"
</FilesMatch>
<FilesMatch "\.(js|css|xml|gz|svgz)$">
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^domain.de$ [NC]
RewriteRule ^(.*)$ http://www.domain.de/$1 [R=301,L]
RewriteCond %{REQUEST_FILENAME} !\.(htm|php|js|css|htc|png|gif|jpe?g|ico|xml|csv|txt|swf|flv|mp4|webm|ogv|mp3|ogg|oga|eot|otf|tt[cf]|woff2?|svgz?|pdf|gz)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .*\.html$ index.php [L]
RewriteRule ^[a-z]{2}(\-[A-Z]{2})?/$ index.php [L]
RewriteRule ^([a-z]{2}(\-[A-Z]{2})?)$ $1/ [R=301,L]
</IfModule>
In Erweiterungen anderer Entwickler einzugreifen ? An einige kommt man garnicht ran. Das Script von Alexa z.b. wird extern eingeladen und gibt es nicht lokal.Zitat:
Zitat von Spooky
Also wenn dann reden wir hier nicht über eine simple günstige Webentwicklung. Aber es sind ja hier auch nur Ausnahmefälle.
Mir fällt gerade ein ich hatte vor Jahren wegen des Pagespeed die Plugin-Url aktiv, oder zumindest Teile davon. Damals hies es das man mit dem pseudo CDN ein paar Pluspunkte bekommt.
Ist der Trick noch gang und gebe 2016 oder alter Hut ?
Unter webpagespeedtest.org sehe ich gerade das es garnicht fruchtet. Hab meine Firmenseite mal gecheckt. Note mangelhaft. Use persistent connections 10/100 und static assets 8/100.
Ich glaube das Thema muss ich nochmal neu aufgreifen.
Ist deine .htaccess aktuell? Ohne Kommentare kann ich auf die schnelle nicht feststellen, ob dem so ist ;).
Ja, darüber rede ich auf keinen Fall.Zitat:
Zitat von izanagi
Achso sorry spooky ich dachte es wäre sparender diese zu entfernen :D
Die Contao Seite von der wir reden ist die 3.4 und die htaccess ist von 2015 und original so ausgeliefert.
Ich habe zum Spass mal die Headausgabe ans Body Ende gesetzt. Direkt 90 Punkte im grünen.
Also die js Datei im assets und die mootools scripte verursachen ganz schön Punkteverlust.
Natürlich geht das Layout dadurch kaputt.
Bei einem anderen Projekt habe ich diese Blocker:
code.jquery.com/jquery-1.11.3.min.js
ajax.googleapis.com/…ootools/1.5.1/mootools-yui-compressed.js
/…oolsnav/html/mootoolsnav-uncompressed.js
Und vom googleplus Plugin noch:
apis.google.com/js/plusone.js
Da fangen die Schwierigkeiten an, zum einen ist jquery oder mootool script essentiell für dden Slider von rocksolid.
Zum anderen wird das googleplus script automatisch im header ausgegeben. Ich kann nicht den ganzen Core auseinandernehmen oder Plugins umprogrammieren, das macht doch kein Mensch.
Und selbst wenn man sich Mühe gibt, einige Scripte müssen halt vor Ausgabe des HTML geladen sein. Da müsste man ja hingehen und die ganze jquery Bibliothek splitten und auseinandernehmen.
Ich hab ein interessantes Deflate Problem.
Ausgangssituation:
- In den Backend Einstellungen sind sowohl Server- und Browsercache als auch Kompression für Markup und Skripte aktiviert.
- htaccess deflate und gzip sind auskommentiert
Die Website unter der Arbeitsadresse: http://staging.altersvorsorge-tipp.de bekommt bei Gooogle Pagespeed trotzdem 89 punkte (Mobil) und 95 Punkte (Desktop)
Laut http://www.whatsmyip.org/http-compression-test/ ist sie unkomprimiert... klar, weil in der htaccess alles auskommentiert ist. Soweit so gut.
Wenn ich in der htaccess jetzt aber die deflate Komprimierung aktiviere, geben die üblichen online Kompressions-Chrecker zwar grünes Licht, aber der Google Pagespeed sinkt dann im Mobilbereich um 8 Punkte (auf 81) und beim Desktop um 1 Punkt (auf 94) :rolleyes:
Foto Google Pagespeed vorher-nachher:
Anhang 17432
hier die htaccess dazu:
Die mod_deflate.c Bedingung muss ich übrigens auch auskommentiert lassen, sonst wird die Seite nicht komprimiert ausgeliefert.Code:<IfModule mod_deflate.c>
#<IfModule mod_filter.c>
AddOutputFilterByType DEFLATE text/html text/plain text/css application/json
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE text/xml application/xml text/x-component
AddOutputFilterByType DEFLATE application/xhtml+xml application/rss+xml application/atom+xml
AddOutputFilterByType DEFLATE image/x-icon image/svg+xml application/vnd.ms-fontobject application/x-font-ttf font/opentype
# </IfModule>
<FilesMatch "\.(js|jpg|jpeg|gif|ico|htc|png|css|txt|html)$ ">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>
Interessant finde ich besonders dass bei Mobile die das Rendering blockierende CSS-Ressource wesentlich schlimmer wiegt (rot) als im unkomprimierten zustand (orange).
Es handelt sich aber um ein und dieselbe Datei.
Warum bekommt denn die Seite mit aktivierter Kompression einen schlechteren Pagespeed?? :eek:
Beste Grüße
Chris
Also wenn ich http://staging.altersvorsorge-tipp.de/ aufrufe bekomme ich folgendes im Response Header:Der dynamisch generierte text/html Inhalt wird also komprimiert vom Server ausgegeben. Auch http://staging.altersvorsorge-tipp.d...30a5ace198.css und http://staging.altersvorsorge-tipp.d...8b9eb16bfff.js habenPHP-Code:Content-Encoding: gzip
im Response Header. Alle anderen Resourcen (Bilder, Schriften) dagegen nicht.PHP-Code:Content-Encoding: gzip
Wie sieht deine .htaccess nun aus?
Ich tippe mal auf Schwankungen durch z.B. Auslastung des Servers oder der Anbindung. Ich habe es gerade nochmal durchlaufen lassen, diesmal waren es 84/100. Bei deiner Anzeige steht ja auch noch explizit drin "Antwortzeit des Servers reduzieren". Wenn der Server "schwach auf der Brust" ist, wird die Auslieferung auch noch dadurch verzögert, dass er die auszuliefernden Ressourcen ja erst noch komprimieren muss. Es kann also durchaus auch mal mehr Zeit in Anspruch nehmen als die unkomprimierte Datei einfach auszuliefern.
1&1 begründet jedenfalls das Fehlen von mod_deflate auf deren Shared Hosting Servern mit der Verschlechterung der Performance. Naja, wenn man die Server so vollpropft wie die, dann darf man sich nicht wundern.
Ob da jetzt gelb oder rot angezeigt wird, kann auch mit der sonstigen gemessenen Performance des Servers zusammenhängen. Sieht es eh schon schlecht aus mit der Geschwindigkeit, ist die blockierende Ressource auch schlimmer. Wenn die erst nach 3 Sekunden ausgeliefert ist, dann ist das Problem eben größer, als wenn sie schon nach 0.3 Sekunden ausgeliefert ist. Blockieren wird sie beide Male, aber eben unterschiedlich lang. Manchmal ist es schon etwas kryptisch, was Pagespeed so ausspuckt und man sieht ja leider nicht alle zugrunde liegenden Messwerte.
Klar, die Serverantwortgeschwindigkeit trägt sicher seinen Teil zu bei, aber mehr als 84 Pkt is nicht drin mit aktiviertem deflate und ohne sinds immerhin 89 Pkt und zwar konstant.
Hier nochmals die komplette htaccess
Naja, die blockierende CSS-Ressource wird anscheinend unabhängig von der Servergeschwindigkeit und egal ob gerade 81 oder 84 Punkte bei rauskommen immer rot angezeigt wenn deflate aktiviert ist.Code:##
# Contao Open Source CMS
#
# Copyright (c) 2005-2014 Leo Feyer
#
# @package Core
# @link https://contao.org
# @license http://www.gnu.org/licenses/lgpl-3.0.html LGPL
##
##
# Prevent access to the Contao template files
##
<FilesMatch "\.(tpl|html5|xhtml)$">
<IfModule !mod_authz_core.c>
Order deny,allow
Deny from all
</IfModule>
<IfModule mod_authz_core.c>
Require all denied
</IfModule>
</FilesMatch>
##
# Allow access from all domains for webfonts
# @see https://github.com/h5bp/html5-boilerplate
##
<IfModule mod_headers.c>
<FilesMatch "\.(ttf|ttc|otf|eot|woff|font\.css)$">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
</IfModule>
##
# Disable ETags
# @see http://developer.yahoo.com/performance/rules.html#etags
##
FileETag None
<IfModule mod_headers.c>
Header unset ETag
</IfModule>
##
# Set the proper MIME types
# @see https://github.com/h5bp/html5-boilerplate
##
<IfModule mod_mime.c>
AddType application/javascript js jsonp
AddType application/json json
AddType audio/ogg oga ogg
AddType audio/mp4 m4a f4a f4b
AddType video/ogg ogv
AddType video/mp4 mp4 m4v f4v f4p
AddType video/webm webm
AddType video/x-flv flv
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
AddType application/vnd.ms-fontobject eot
AddType application/x-font-ttf ttf ttc
AddType font/opentype otf
AddType application/x-font-woff woff woff2
AddType image/x-icon ico
AddType image/webp webp
AddType text/cache-manifest appcache manifest
AddType text/x-component htc
AddType application/xml rss atom xml rdf
AddType application/x-web-app-manifest+json webapp
AddType text/x-vcard vcf
AddType application/x-shockwave-flash swf
</IfModule>
##
# Gzip compression
# @see https://github.com/h5bp/html5-boilerplate
##
#<IfModule mod_deflate.c>
# VORSICHT: mod_filter.c gibts in alten Apachen nicht, also die Bedingung einfach auskommentiert lassen
# <IfModule mod_filter.c>
AddOutputFilterByType DEFLATE text/html text/plain text/css application/json
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE text/xml application/xml text/x-component
AddOutputFilterByType DEFLATE application/xhtml+xml application/rss+xml application/atom+xml
AddOutputFilterByType DEFLATE image/x-icon image/svg+xml application/vnd.ms-fontobject application/x-font-ttf font/opentype
# </IfModule>
<FilesMatch "\.(js|jpg|jpeg|gif|ico|htc|png|css|txt|html)$ ">
SetOutputFilter DEFLATE
</FilesMatch>
#</IfModule>
##
# Expires headers (for better cache control)
# @see https://github.com/h5bp/html5-boilerplate
##
<IfModule mod_expires.c>
ExpiresActive on
##
# Productional website
##
ExpiresByType text/cache-manifest "access plus 0 seconds"
ExpiresByType text/html "access plus 0 seconds"
ExpiresByType text/xml "access plus 0 seconds"
ExpiresByType application/xml "access plus 0 seconds"
ExpiresByType application/json "access plus 0 seconds"
ExpiresByType application/rss+xml "access plus 1 hour"
ExpiresByType application/atom+xml "access plus 1 hour"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 month"
ExpiresByType video/ogg "access plus 1 month"
ExpiresByType audio/ogg "access plus 1 month"
ExpiresByType video/mp4 "access plus 1 month"
ExpiresByType video/webm "access plus 1 month"
ExpiresByType text/x-component "access plus 1 month"
ExpiresByType application/x-font-ttf "access plus 1 month"
ExpiresByType font/opentype "access plus 1 month"
ExpiresByType application/x-font-woff "access plus 1 month"
ExpiresByType image/svg+xml "access plus 1 month"
ExpiresByType application/vnd.ms-fontobject "access plus 1 month"
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
##
# Disable caching during development
# @see https://github.com/contao/core/issues/4364
##
#ExpiresByType text/cache-manifest "access"
#ExpiresByType text/html "access"
#ExpiresByType text/xml "access"
#ExpiresByType application/xml "access"
#ExpiresByType application/json "access"
#ExpiresByType application/rss+xml "access"
#ExpiresByType application/atom+xml "access"
#ExpiresByType image/gif "access"
#ExpiresByType image/png "access"
#ExpiresByType image/jpeg "access"
#ExpiresByType image/x-icon "access"
#ExpiresByType video/ogg "access"
#ExpiresByType audio/ogg "access"
#ExpiresByType video/mp4 "access"
#ExpiresByType video/webm "access"
#ExpiresByType text/x-component "access"
#ExpiresByType application/x-font-ttf "access"
#ExpiresByType font/opentype "access"
#ExpiresByType application/x-font-woff "access"
#ExpiresByType image/svg+xml "access"
#ExpiresByType application/vnd.ms-fontobject "access"
#ExpiresByType text/css "access"
#ExpiresByType application/javascript "access"
</IfModule>
##
# Header adjustments
##
<IfModule mod_headers.c>
##
# Disable caching during development
# @see https://github.com/contao/core/issues/4364
##
#Header unset Cache-Control
#Header append Cache-Control must-revalidate
##
# Do not cache the cron.txt file
# @see https://github.com/contao/core/issues/5105
##
<FilesMatch "cron\.txt$">
Header set Cache-Control "no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, no-transform"
</FilesMatch>
##
# Add a Vary Accept-Encoding header for the compressed resources. If you
# modify the file types above, make sure to change them here accordingly.
# @see http://developer.yahoo.com/performance/rules.html#gzip
#
# Note: If you are using a case-sensitive file system like HFS+ or ext4, you
# have to change the <FilesMatch> directive as follows:
#
# <FilesMatch "\.(?i:js|css|xml|gz|svgz)$">
#
# For more information see: https://github.com/contao/core/issues/4364
##
<FilesMatch "\.(js|css|xml|gz|svgz)$">
Header append Vary Accept-Encoding
</FilesMatch>
</IfModule>
##
# Disable MultiViews if you are having issues with requests returning the wrong
# page. Requires AllowOverride Options=All,MultiViews to be set here.
# @see https://github.com/contao/core/issues/3521
##
#Options -MultiViews
##
# URL rewriting
##
<IfModule mod_rewrite.c>
RewriteEngine On
##
# Change the RewriteBase if your Contao installation is in a subdirectoy and
# the rewrite rules are not working properly. Usage examples:
#
# RewriteBase /contao-3.0.0
# RewriteBase /path/to/contao
#
# Depending on your server, you might have to remove the line entirely.
##
RewriteBase /
##
# Uncomment the following lines to add "www." to the domain:
#
RewriteCond %{HTTP_HOST} ^meinedomain\.de$ [NC]
RewriteRule (.*) http://www.meinedomain.de/$1 [R=301,L]
#
# Uncomment the following lines to remove "www." from the domain:
#
# RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
# RewriteRule (.*) http://example.com/$1 [R=301,L]
#
# Make sure to replace "example.com" with your domain name.
##
##
# If you cannot use mod_deflate, uncomment the following lines to load a
# compressed .gz version of the aggregated Contao JavaScript and CSS files.
##
# AddEncoding gzip .gz
# <FilesMatch "\.js\.gz$">
# AddType "application/javascript" .gz
# </FilesMatch>
# <FilesMatch "\.css\.gz$">
# AddType "text/css" .gz
# </FilesMatch>
# <FilesMatch "index.html.gz$">
# AddType "text/html" .gz
# </FilesMatch>
# RewriteCond %{HTTP:Accept-encoding} gzip
# RewriteCond %{REQUEST_FILENAME} \.(html|js|css)$
# RewriteCond %{REQUEST_FILENAME}.gz -f
# RewriteRule ^(.*)$ $1.gz [QSA,L]
##
# By default, Contao adds ".html" to the generated URLs to simulate static
# HTML documents. If you change the URL suffix in the back end settings, make
# sure to change it here accordingly!
#
# RewriteRule .*\.html$ index.php [L] # URL suffix .html
# RewriteRule .*\.txt$ index.php [L] # URL suffix .txt
# RewriteRule .*\.json$ index.php [L] # URL suffix .json
#
# If you do not want to use an URL suffix at all, you have to add a second
# line to prevent URLs that point to folders from being rewritten (see #4031).
#
# RewriteCond %{REQUEST_FILENAME} !-d
# RewriteRule .* index.php [L]
#
# If you are using mod_cache, it is recommended to use the RewriteRule below,
# which adds the query string to the internal URL:
#
# RewriteRule (.*\.html)$ index.php/$1 [L]
#
# Note that not all environments support mod_rewrite and mod_cache.
##
RewriteCond %{REQUEST_FILENAME} !\.(htm|php|js|css|htc|png|gif|jpe?g|ico|xml|csv|txt|swf|flv|mp4|webm|ogv|mp3|ogg|oga|eot|woff|svg|svgz|ttf|pdf|gz)$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule .*\.html$ index.php [L]
##
# The following rules are required if you want to pass the language as first
# URL parameter (added in Contao 2.11). The first rule rewrites the empty URL
# to the front end controller, the second one adds a missing trailing slash.
##
RewriteRule ^[a-z]{2}(\-[A-Z]{2})?/$ index.php [L]
RewriteRule ^([a-z]{2}(\-[A-Z]{2})?)$ $1/ [R=301,L]
</IfModule>
##
# Persistente Verbindungen erlauben, damit erneute Seitenaufrufe schneller werden
##
<ifModule mod_headers.c>
Header set Connection keep-alive
</ifModule>
Wie geschrieben, in manchen Konstellationen kann es schneller sein, nicht zu komprimieren. Müsste man mal schauuen, ob irgendwo steht, welche Downloadgeschwindigkeit bei der mobilen Bewertung zugrunde gelegt wird. Je höher die ist, desto weniger schlimm sind ein paar KB mehr in der unkomprimierten Variante. Und je länger die Ressource blockiert, vielleicht ja gerade deshalb, weil sie erst noch komprimiert wird, desto schlimmer. Schau dir das auch mal mit den Developer Tools der Browser an in beiden Varianten. Vielleicht ist es auf deinem Server letztlich wirklich besser, auf mod_deflate zu verzichten. Wenn diese Variante reproduzierbar besser abschneidet, eventuell auch bei anderen online verfügbaren Tests, dann soll es eben so sein - oder man wechselt das Hosting ;).
Ok, jetzt entdecke ich gerade was neues... ich hatte es zuvor ja auch mal mit gzip probiert und anscheinend wurde das irgendwie irgenwo zwischengespeichert, obwohl ich gzip in der htaccess wieder auskommentiert hatte. Jetzt wo ich es von einem anderen PC aus checke rauscht die Pagespeed nämlich ohne deflate von 84 auf 63 runter anstatt auf 89 Punkte hoch. Am "fremden" Rechner bekomme ich die 89 Punkte nur mit gzip in der htaccess hin.
Es wirkt als würde mein Rechner die Pagespeed Ergebnisse mit gzip Kompression cachen und nur wenn deflate aktiv ist einen anderen Wert ausspucken?! :eek:
Ich hatte es aber mit Firefox, Chrome und dem IE unabhängig voneinander getestet.... Fragen über Fragen.
Schau halt mal rein in assets/css und assets/js zum Beispiel. Wenn da noch .gz -Versionen der aktuellen zusammengefassten Versionen existieren und in der .htaccess die RewriteConds und RewriteRules dazu aktiv sind, dann werden die auch ausgeliefert.
Spooky wie ermittelst du denn den Response Header ? Im Firebug seh ich nix, ich hab jetzt web-sniffer probiert da wird ausgegeben das gzip aktiv ist. Dennoch wird die Komprimierung bemängelt und zwar das root und die "externen" Dateien was verständlich ist da Dateien von fremden Servern ja nicht komprimiert werden können.
Gesamt sind es 750kb Scripte das ist schon echt viel. Über varvy.com bekommt man ne gute Übersicht. Prüfe mal für wortmann-partner.de das ist die aktuelle Seite an der ich optimiere. Vielleicht siehst du was was ich nicht sehe.
Auch stört mich die keep-alive Funktion welche ja starke Auswirkung auf den Speed haben sollen. Scheinbar unterstützt der Hoster das nicht :(
Habe keep-alive auch in der htaccess aktiviert. Schade.
@ chris du hast einen echt guten Score, hut ab, das bekomm ich so garnicht hin.
Async Javascript, Keep alive, browser caching, JS files, alles optimal.
Du kommst mit nur einer JS aus ? Bei mir sind es 12 js dateien die laden :/
Zitat:
Zitat von izanagi
- Firebug deinstallieren
- F12 drücken (Developer Tools öffnen)
- Performance Tab öffnen
- Seite laden
- HTML Request/Response anklicken
- Headers Tab öffnen
Danke. Der Tab Performance gibts hier zwar nicht, aber schätze "Netzwerkanalyse" soll das sein.
Wenn ich hier die HTML Ausgabe wähle und rechts auf "Kopfzeilen" dann wird mehr der Header angezeigt:
Kein defalte gzip zu sehen, was erklärt warum der speedcheck meckert beim root. da wird wohl die html Ausgabe gemeint sein. Oder spinn ich jetzt ?PHP-Code:Cache-Control: public, max-age=43200
Connection: close
Content-Type: text/html; charset=utf-8
Pragma: public
Server: Apache/2.2.15 (CentOS)
Transfer-Encoding: chunked
Vary: User-Agent
X-Powered-By: PHP/5.4.17
Weil die anderen Dateien wie css und js haben folgenden Header
Ich dachte keep-alive wäre nicht vorhanden, die Speedtests sagen das zumindest. boa ich blick hier nicht mehr durch. :DPHP-Code:Cache-Control: max-age=31536000
Connection: keep-alive, close
Vary: Accept-Encoding
1,2 MB Javascript Daten sind auch echt viel finde ich.
Der Browsercache ist aktiviert, jedoch gibts 3 Scripte von Facebook und Google die das ganze lahmlegen.
EDIT: Wow das Entfernen der facbook und google plugins hat eine Sprung von M: 66 D: 83 auf Mobile:74 Desktop 88 grün
bewirkt, hochachtung. Vielleicht muss hier eine andere Implementierung, eventuell per Hand als Inline Script, umgesetzt werden.
@MacKP ich habe mir die Kompressionsoptimierung jetzt angesehen und einige Bilder optimiert. Wie zu erwarten sehe ich dennoch Qualitätsunterschiede, ein vermehrtes Kompressionsrauschen und einige Artefakte.
Ein komprimiertes Bild sollte niemals nochmal komprimiert werden und JPEGmini entfernt hier nicht nur selektiv Informationen.
Aus dem Grund habe ich mal einen anderen Weg probiert, qualitatives Rohmaterial des Bildes genommen und geradewegs in den JPEGmini rein.
Resultat von 460 auf 160KB. Komprimierung sichtbar / mein Eindruck Note 7/10
Über Photoshop Rohmaterial als Webbild komprimiert habe ich 150kb. Komprimierung sichtbar / mein Eindruck Note 8/10
Das Webbild in den JPEGmini rein ergibt 117KB. Komprimierung stark sichtbar / mein Eindruck Note 6/10
Fazit: Datenreduzierung ist möglich wenn man verhandene Webbilder erneut komprimiert (JPEGmini) jedoch mit sichtbarem Verlust.
Weniger sichtbarer Verlust ist möglich wenn man ihm Rohmaterial zufüttert, jedoch habe ich dann die selbe Datenmenge wie mit Photoshop und die Qualität ist einen ticken schlechter.
Kleines Update. Der Hoster sagte mir das gzip standardmäßig aktiv ist und es sein kann das durch die "erneute" aktivierung per htaccess es zu Problemen kommen kann. Ich solle doch mal gzip aus der htaccess entfernen.
Habe ich auch getan, dadurch fiel der Pagespeed um 8 Punkte. Also das kanns nicht sein ;)
Das kann ich einfach nicht verstehen, weil dann muss doch gzip funktionieren sonst wäre der Speed ja nicht besser.
Aber warum sagt der Check wie gidnetwork dann das genaue Gegenteil ?!
Meine Seite Firmenseite unterstützt gzip und auch gidnetwork sagt das gzip aktiv sei.
Beim Kundenhoster hingegen sagt er "no".
Prüfe doch einfach selbst, ob gzip aktiv ist oder nicht?
Oder jage die URL nochmal durch die Google Pagespeed Seite. Wenn da nichts mehr steht von "Komprimierung aktivieren", dann ist alles gut. Wenn doch, dann wird ja haarklein aufgelistet, welche Dateien nicht komprimiert sind. Bei Verwendung von gzip werden zum Beispiel von Contao nur und ausschliesslich die zusammengefassten .js und .css mit den kryptischen Namen komprimiert. Weitere eingebundene Dateien sind dann Handarbeit, also selbst mit gzip zu komprimieren und im selben Verzeichnis auf dem Server wie das Original wieder ablegen.
@ tab
du hast recht, die Daten müssen natürlich auch als zip vorhanden sein. Bei den dynamisch erzeugten via Plugin will ich jetzt nicht rumfummeln, aber die die übrig sind könnte man verpacken.
Ich hab jetzt rausgefunden wieso die Check Tools sagen es wäre keine Kompression vorhanden und das der Speedtest sagt das Root also die Domain selbst wäre nicht komprimiert.
Die Aktivierung per htaccess wirkt sich nicht auf das Wurzelverzeichnis aus sondern nur die verlinkten, geladenen Dateien.
Beim Provider habe ich die PHP Option " zlib.output_compression" gefunden diese war auf "off".
Nachdem ich sie nun aktiviert habe, verschwand der Kompressionshinweis aufs Root beim Pagespeed Test. Und auch die Check Tools sagen jetzt grünes Licht bei Komprimierung.
Fazit: Die Komprimierung lässt sich zwar per htaccess aktiviert, wirkt aber nur bei "Dateien" die geladen werden und nicht das HTML Gerüst.
So würd ich das erklären :D