Hallo zusammen, ich bin grad ein bisschen sauer, was die Performance meines Shops angeht. Als ich zu 5.0 gewechselt bin, wurde ich von Google Page Speed Insights noch mit über 60 Pkt für Desktops bewertet, das sind nun nur noch 45. Der Shop hat sich seitdem von ca. 400 Artikeln auf vielleicht 500 vergrößert. Angeblich sei die Komprimierung nicht an, folgendes steht aber in der htaccess # Enable gzip compression<ifmodule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file .(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifmodule># Enable deflate compression<ifmodule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
</ifmodule> Die htaccess-Datei liegt im home-Verzeichnis von Shopware. Der Shop liegt auf einem Managedserver von Hetzner. Ich verwende PHP 5.5. And zend extensions sind nur der ioncube loader sowie der OPcache aktiviert. HTTP-Cache in Shopware ist ebenfalls aktiviert. Wie kann ich überprüfen, ob die Komprimierung gescheit läuft bzw. wie kann man an der Performance schrauben? 500 Artikel ist ja ein Witz für Shopware, oder? Das Ergebnis des Tests sieht man hier: klick Viele Grüße
[quote=„mwhardware“]Als ich zu 5.0 gewechselt bin, wurde ich von Google Page Speed Insights noch mit über 60 Pkt für Desktops bewertet[/quote] Was auch schon ziemlich schlecht ist, ein nicht optimierter Testshop auf nem Shared Hosting kommt out-of-the-box bei mir auf 83… [quote=„mwhardware“]Angeblich sei die Komprimierung nicht an[/quote] Ist sie auch nicht. Ich habe schon mehrfach festgestellt, dass die Komprimierung von mit php generierten Seiten nicht über die .htaccess steuerbar ist - warum auch immer. Helfen sollte if (substr\_count($\_SERVER['HTTP\_ACCEPT\_ENCODING'], 'gzip')) { ob\_start("ob\_gzhandler"); } else { ob\_start(); } am Anfang der shopware.php. Oder kann man das mittlerweile irgendwo im Backend einstellen? Hab irgendwie nichts gefunden… [quote=„mwhardware“]Wie kann ich überprüfen, ob die Komprimierung gescheit läuft[/quote] Mit den Dev-Tools den Response-Header anschauen ob dieser ‚Content-Encoding: gzip‘ enthält.
Hey, danke erstmal für deine Hilfe. Ich habe beim surfen noch was gesehen bzgl gzip und deflate. Ich glaube die quint essenz war, dass Deflate ab Apache 2.0 eingesetzt wird, korrekt? Oder sollte man beides einsetzen? Ich frage mich, ob Hetzner da einen Riegel vorschiebt und es deswegen nicht geht. Habe hier im Forum schon beide Varianten gefunden, wo Leute bei Hetzner die Komprimierung am laufen hatten und jene, bei denen nichts passiert ist, wie bei mir. Ich probiere das mal. Vielleicht hat einer vom Shopware-Team noch gute Ideen bzw. pragmatische Lösungsvorschläge, das Ranking ist echt viel zu bitter für so einen kleinen Shop auf einem Managed Server der nicht mal annähernd an seine Grenzen kommt. Viele Grüße
Habe nun mit Hetzner gesprochen. Sie haben es wohl standardmäßig deaktiviert und man kann es durch eine Supportanfrage freischalten lassen. Deine Methode hat leider garnichts geändert. Laut diversen Websites zum checken für die Kompression, ist gzip aber auch damit noch inaktiv. Habe das erstmal wieder rückgängig gemacht. Ich nehme an, mit der htaccess kann man dann hier auch nichts dran machen. In meiner phpinfo ist auf jeden Fall zu sehen, wass es eigentlich aktiviert ist. aus der phpinfo: \_SERVER["HTTP\_ACCEPT\_ENCODING"] gzip, deflate gzip compression enabled \_ENV["HTTP\_ACCEPT\_ENCODING"] gzip, deflate Viele Grüße
[quote=“mwhardware”]danke erstmal für deine Hilfe. Ich habe beim surfen noch was gesehen bzgl gzip und deflate. Ich glaube die quint essenz war, dass Deflate ab Apache 2.0 eingesetzt wird, korrekt? Oder sollte man beides einsetzen?[/quote] mod_deflate ist das modernere Modul. Ich weiß nicht mal, ob mod_gzip mit Apache2 überhaupt noch läuft. [quote=“mwhardware”]Deine Methode hat leider garnichts geändert.[/quote] Was komisch ist, weil die setzt ja auf php-Ebene an und nicht auf Webserver-Ebene. Aber vielleicht haben sie es auch da ausgeschaltet. Ich kann das verstehen, dass man sowas im Shared Hosting macht, um nicht in Performance-Probleme zu rennen, aber bei einem dedizierten Managed-Server? Ich weiß schon, warum wir nicht mehr bei Hetzner sind…
Die Server können wohl nur deflate, mal sehen wie es aussieht, wenn sie es aktiviert haben. Wo hostest du deinen Shop? War grad mal am schauen was es da noch so gibt, Zahlen halt im Moment nichts. Viele Grüße
Hallo, ich hatte/habe exakt das gleiche Problem bei Shopware 4 und 5 mit Hosteurope Einfach diesen Part in die htaccess eintragen (kann ganz unten stehen):
SetOutputFilter DEFLATE
Nachdem ich diesen Code eingefügt hatte, war die Komprimierung wieder aktiv und bei Pagespeed und einigen anderen Performance Testseiten wurde dies dann auch so bestätigt. Ich hoffe ich konnte weiterhelfen… Viel Glück
Hi, danke für den Tipp! Haben die Komprimierung nun via Support-Ticket für dynamische Inhalte freischalten lassen, wird nun auch von Google angezeigt und nach einer Optimierung der Bilder habe ich nun 59 Pkt beim PageSpeed, zu vor 45. Davon sind aber nur 5 zusätzlich durch die Komprimierung entstanden. Jetzt frage ich mich, ob 128 MB Memory für PHP genügen, wo kann ich sehen, wieviel davon aktuell von PHP gebraucht werden? EDIT [code]<?php function convert($size)
{
$unit=array(‘b’,‘kb’,‘mb’,‘gb’,‘tb’,‘pb’);
return @round($size/pow(1024,($i=floor(log($size,1024)))),2).’ '.$unit[$i];
}
echo convert(memory_get_usage(true)); // 123 kb
?>[/code] zeigt folgendes an: 256 kb Ist ja weit weg von den 512 M, die ich nun zugewiesen habe 
Viele Grüße
Dann noch was: APCu wird vom Server nicht angeboten, würde das sehr viel mehr Performance bringen? Jage grad noch die PNGs durch OptiPNG und schaue, dass ich die JPEGs auch nochmal kleiner kriege, aber daran kann´s doch nicht nur liegen. Viele Grüße
Entschuldigt, dass ich hier wieder rumjammere, aber: Google PageSpeed zeigt an, dass ein Bild um 120 KB (ist ein PNG-Bild) verkleinert werden könnte, durch Größenanpassungen und Komprimierung. Was hat Shopware damit zu tun? Ganz einfach: dieses Bild wird überhaupt nicht mehr geladen. Es ist nicht auf der Startseite zu sehen und auch nicht im Quelltext auffindbar, wieso denkt Google also, es wäre da? Hat das was mit dem Cache zu tun? Sollte ich vielleicht mal den Inhalt des Ordners Cache komplett leeren? Viele Grüße
*hochschieb* 
Wir stehen auch irgendwie gerade vor dem Problem Hetzner -> Sw5 … Anscheinend entgegen unserer Recherchen ist Hetzner wohl doch nicht soooo der gute Hoster für Shopware. mir wurde gesagt wenn man alles optimal zum laufen bekommt ist der shop wesentlich schneller als das was unserer momentan hergibt.
Was habt ihr für eine Bewertung? Mögen sich mal alle die melden, die ein geiles Hosting haben 
Ich verste´h nicht, wieso beim Pagespeed ein Bild geladen wird, was nirgens angezeigt wird
Ich liege bei 84 punkten bei google in der Desktopansicht, kämpfe gerade noch mit folgender Meldung: JavaScript- und CSS-Ressourcen, die das Rendering blockieren, in Inhalten "above the fold" (ohne Scrollen sichtbar) beseitigen Hoste bei Centron und konnte mit deren Maßnahmen von 49 auf 84 aufsteigen.
Mit „deren Maßennahmen“ heißt? APCache? PHP Version? GZIP/DEFLATE? Wir sind durch unsere Maßnahmen nun von 45 auf 60, aber das hier: Durch die Komprimierung und Größenanpassung von https://www.domain.de/…ge/thumbnail/ai\_family\_final\_600x600.png könnten 171,5 KB (82 %) eingespart werden. macht´s glaube ich kaputt. Viele Grüße
[quote=„mwhardware“]Mit „deren Maßennahmen“ heißt? APCache? PHP Version? GZIP/DEFLATE? Wir sind durch unsere Maßnahmen nun von 45 auf 60, aber das hier: Durch die Komprimierung und Größenanpassung von https://www.domain.de/…ge/thumbnail/ai\_family\_final\_600x600.png könnten 171,5 KB (82 %) eingespart werden. macht´s glaube ich kaputt. Viele Grüße[/quote] Ich sage schneller machen, die sagen ok mod_expire, APCu Aktiviert, deflate Am meisten hat das aktivieren des http-caches gebracht.
Ok. Zur Info: wenn ich zwei PNG-Dateien umbenenne, sodass Google sie garnicht erst laden kann, dann hab ich nun statt 60, 71 Pkt
Wie hast du das mit den JavaScript- und CSS-Ressourcen gelöst?
Hier irgendwelche Zahlen zu vergleichen, bringt ja eigentlich garnichts. Die Werte hängen ja auch davon ab, welche Seite geladen wird, und welche Inhalte die Seite hat. Aber wenn wir dabei sind: All-Inkl. Business - http-cache an, aber keine anderen Caches, gzip an, vorgewärmt: Startseite: 2x Banner, Bannerslider mit 18 Bildern, 2x Blog-Boxen, 1x HTML-Box: Desktop: 88 / Mobil 74 Unterseite mit Einkaufswelt: 3x HTML-Box, 8x kleinere Banner, 1x Bannerslider, “zuletzt gesehen” Desktop: 87 / Mobil 70 Kategorielisting: Desktop: 90 / Mobil 74 Stichprobe Artikel: Desktop: 86 / Mobil 73 Kompression, Produktiv-Modus, HTTP-Cache und “Vorwärmen” dürften das meiste bringen. Anmerkung zu All-Inkl.: Wie sind in einem Jahr 2 auf einen anderen Server umgezogen. Hatten immer wieder Probleme mit “Timeouts” beim ersten Seitenaufruf. Nach einigen Emails, Androhungen den Vertrag zu kündigen etc. haben die irgendwas an dem Server geschraubt. Seit dem läuft es überwiegend rund.
Hi, ich rede immer von der Startseite, die Unterseiten sind ja schwer abhängig, aber die Einstiegsseite sollte schon vernünftig laden/ranken. Ich habe das garnicht gelöst Neben dem, wird bei mir noch bemängelt, dass Inhalte nicht priorisiert sind, Jacasccript reduziert werden soll und dass das Caching nicht an sei, das gilt aber anscheinend wohl nur für ein paar Module, wie z.B. das Käfuersiegel vom Händlerbund. Auf meiner Startseite sind - 4 große Banner - über 50 Thumbnails durch Newcomer Artikel und Empfehlungen - 3 mittel große Grafiken Ich würde mal gerne wissen, wieso Google denkt, dass ich ein 42 KB JPEG Bild, was schon komprimiert wurde, um 90% VERLUSTFREI komprimieren könnte … wtf? Viele Grüße