Die Pixelzahl ist eigentlich gar nicht mal interessant für das, was man wissen will, das wäre nämlich im Grunde die "Informationsdichte". In erster Näherung kommt man zwar mit den Punkten pro Zoll heran, die man jetzt errechnen könnte, aber da gibts auch noch Faktoren der Skalierung... Beispiel: Meine Windowsmühle schiebt 3840x2160Pixel auf ein 27" Display. Das heisst ich hab auf einer Bildfläche von 2009,68cm² eine Pixeldichte von 163,18dpi. Ich betreibe meinen Monitor wechselnd bei einer Skalierung von 125% oder 150%, da ändere ich meine Meinung immer mal, was das Ganze dann auf 130 bzw.108 "Vergleichsdpi" herunterbricht... Und wenn man das hat, dann kann man wiederum mit den üblichen Darstellungsdichten der Browser den Daumen anlegen...
Man kann bei solchen Tests mit eigenem Server locker über 80 kommen. Einfach das hier für die Bilder durchjagen: (Link nur für registrierte Nutzer sichtbar.) Dann in der Server-Config das da berücksichtigen: Code: <IfModule mod_deflate.c> AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE text/javascript AddOutputFilterByType DEFLATE image/svg+xml AddOutputFilterByType DEFLATE image/x-icon AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript DeflateCompressionLevel 9 # Browser specific settings BrowserMatch ^Mozilla/4 gzip-only-text/html BrowserMatch ^Mozilla/4\.0[678] no-gzip BrowserMatch \bMSIE !no-gzip !gzip-only-text/html BrowserMatch \bOpera !no-gzip </IfModule> Header unset ETag FileETag None <ifModule mod_expires.c> ExpiresActive On ExpiresDefault "access plus 5 seconds" ExpiresByType image/x-icon "access plus 604800 seconds" ExpiresByType image/jpeg "access plus 604800 seconds" ExpiresByType image/jpg "access plus 604800 seconds" ExpiresByType image/png "access plus 604800 seconds" ExpiresByType image/gif "access plus 604800 seconds" ExpiresByType image/svg+xml "access plus 604800 seconds" ExpiresByType application/x-shockwave-flash "access plus 604800 seconds" ExpiresByType text/css "access plus 604800 seconds" ExpiresByType text/javascript "access plus 604800 seconds" ExpiresByType application/javascript "access plus 604800 seconds" ExpiresByType application/x-javascript "access plus 604800 seconds" ExpiresByType application/font-woff "access plus 604800 seconds" ExpiresByType text/html "access plus 600 seconds" ExpiresByType application/xhtml+xml "access plus 600 seconds" </ifModule> <ifModule mod_headers.c> <filesMatch "\.(ico|jpe?g|png|gif|swf|svg)$"> Header set Cache-Control "public" </filesMatch> <filesMatch "\.(css)$"> Header set Cache-Control "public" </filesMatch> <filesMatch "\.(js)$"> Header set Cache-Control "private" </filesMatch> <filesMatch "\.(x?html?|php)$"> Header set Cache-Control "private, must-revalidate" </filesMatch> </ifModule> Wenn man keinen eigenen Server (oder SEO-Hosting) hat, läßt sich Letzteres auch ein wenig in die .htaccess integrieren.
Die htaccess Anpassungen sind bezogen auf aktuelle Shops unnötig bis teilweise kontraproduktiv. Im Shop liegen mehrere htaccess Dateien, die 90% des Jobs schon erledigen, einige andere Sachen sollten nicht gecached werden.
WIRKLICH? Komisch, warum habe ich dann davor 50/100, und danach erst diese Werte? Ebenso überprüft der Webserver ja auch auf Modifizierung. Ich würde daher gerne wissen, welches dünne Brett hier gebohrt wird...
Waren deine .htaccess den Aktiv im Ordner Templates & Images oder waren dort keine vorhanden bzw nicht aktiv? Sieht eher so aus als sind die vorher nicht aktiv gewesen oder gar nicht vorhanden. Bei uns sind diese Aktiv. Eine Testweise Änderung deiner Modifikationen in der root .htaccess bringt 0.
Verarbeitet dein Server keine .htaccess Dateien im Seitenkontent? Das macht ein Standard Ubuntu/Debian Apache zum Beispiel per Standarddirektive nicht, heisst wenn man die nicht anpasst greifen unsere Bemühungen nicht. Debian/Ubuntu Webserver gibts viele , aber jeder normale Hoster passt das eigentlich an. Zum anderen gilt das gesagte erst für Shops ab Version 2.7.x aufwärts, in der Reihe haben wir da mehrfach die Defaults modifiziert, bei älteren Shops ist das noch nicht da.
Doch. Ohne jetzt IRGENDEINEM Entwickler nahe treten zu wollen, aber bei der Zersplitterung aller htaccess-Dateien im Gambio ist das Einzig Richtige, alle rauszulöschen (weil mehrfach redundant, und somit nur zu Lasten des Servers), und dann in eine zentrale Datei oder gleich in den vHost schreiben lassen. Code: root@debian# find -type f -name ".htaccess" ./ext/klarna_php_2.3.0/.htaccess ./.htaccess ./templates_c/.htaccess ./version_info/.htaccess ./media/content/.htaccess ./lettr/.htaccess ./images/.htaccess ./images/product_images/.htaccess ./uploads/.htaccess ./StyleEdit3/.htaccess ./StyleEdit3/assets/.htaccess ./templates/EyeCandy/css/.htaccess ./templates/EyeCandy/img/.htaccess ./templates/EyeCandy/backgrounds/.htaccess ./templates/EyeCandy/javascript/.htaccess ./templates/Honeygrid/.htaccess ./templates/Honeygrid/assets/.htaccess ./gm/seo_boost_an/.htaccess ./gm/.htaccess ./gm/customers_uploads/.htaccess ./gm/seo_boost_aus/.htaccess ./GProtector/.htaccess ./pub/.htaccess ./export/sepa/.htaccess ./export/invoice/.htaccess ./export/packingslip/.htaccess ./callback/rsmartsepa/.htaccess ./GXEngine/.htaccess ./includes/.htaccess ./includes/external/masterpayment/logs/.htaccess ./lang/.htaccess ./admin/backups/.htaccess ./admin/includes/.htaccess ./admin/includes/gm/.htaccess ./admin/html/assets/.htaccess ./admin/html/assets/images/legacy/.htaccess ./cache/.htaccess ./GXMainComponents/.htaccess ./JSEngine/.htaccess ./logfiles/.htaccess ./download/.htaccess ./shopgate/.htaccess ./shopgate/shopgate_library/.htaccess ./shopgate/gambiogx/admin/includes/img/.htaccess
Das halten wir nun gerade nicht für den richtigen Plan. Die Vhost Definitionsvariante kommt für uns nicht in Frage, weil ein überwiegender Grossteil unserer Kunden da nicht drankommt. In Shared Webhostings, und die werden vielfach genutzt, ist die Idee schlicht tot. Da wir auch für die kleinen Shops bauen, muss es anders gehen. Eine zentrale .htaccess Datei ist theoretisch machbar, aber der reale Benefit geschätzt eher gering. Der Apache wird trotzdem ständig über die Ordner iterieren und suchen, wahrscheinlich ist ein Gewinn kaum messbar, solange der Shop nicht wirklich hochfrequentiert ist. Das über die Ordner iterieren kriegt man wieder nur weg, wenn ein Kunde an die Vhost Definition kommt, sind wieder beim Thema oben. Dazu muss man ganz gehörig mit den Pfaden aufpassen, oder ein Kunde muss verstehen können wie er ein Template auf seine Umgebung anpasst. Das zu vereinfachen, so dass ein Nichtstudierter da durchblickt, dürfte schätzen wir sehr schwierig werden. Wer es aber besser als wir kann, der darf aber gerne einen Vorschlag einreichen, dann reden wir drüber.
Hallo zusammen, habe eben das "neue" google tool getestet und musste mit schrecken festellen das meine speed laut google ziemlich arm ist (poor). Kann mir jemand weiterhelfen was bei mir schief läuft? Habe dieses Wochenende auf Honeygrid umgestellt. Aber das wird nicht der grund sein. Die Werte vor der Umstellung kenne ich leider nicht. Grüße
habe eben die .htaccess gegen die original seo_boost .htaccess datei getauscht gehabt. da ist er auf server error gelaufen
Nun, zuallerst würde ich mal die Komprimierung im Shop einschalten und dann die Bilder optimieren. Eine Qualität von 80 sollte Dich schonmal um Lichtjahre nach vorne bringen.
ich habe gerade mal getestet und habe auch ein schlechtes Ergebnis, habe daraufhin mal den Code von watchdeal in die .htaccess eingefügt und das sind die Ergebnisse: vorher: 97/43/59 nachher: 73/100/100 schon seltsam!!! Nachtrag: dafür ließ sich der Shop aber nicht mehr aufrufen