@marmoles geh mal mit der Maus auf die Zeile wo vorne Status steht (egal wohin) dann rechte Maustaste da hast du Auswahlfelder
Hallo Leute! Ich bin mal so frei und klinke mich hier auch kurz ein. Da ich im Moment auch wieder viel Zeit in unsere Homepage stecke und auch erstmal an der Geschwindigkeit bastel, ist mir aufgefallen das unsere Seite www.eusch.de anfangs ca 6-7 Sekunden brauchte um geladen zu werden. Genutzt habe ich https://www.pagespeed.de/ Ich habe es geschafft durch Einstellungen und Bilder Komprimierungen es auf ca 2-3 Sekunden zu senken. ( weitere Bilder komp. folgen, ich weiss die sind alle recht gross ) Nun habe ich aber durch irgendeine Einstellung, die ich leider nicht mehr finde es geschafft das er nun 10 sekunden+ braucht um unsere Startseite www.eusch.de aufzurufen. Aus irgendeinem Grund scannt er alle unsere Artikel, obwohl ich nur die Startseite aufrufe. Jemand eine Idee? Unter den Systemeinstellungen ist die Kompression an! Das Kompressionslevel auf 9 und die HTML Kompression an
(Link nur für registrierte Nutzer sichtbar.) damit bekommst ganz gute Zahlen und siehst was lange braucht und nicht nur Startseite bewerten, sondern auch Kategorie und Artikelseiten. Optimal 2-3 mal messen mit paar min. abstand. Damit man Mittelwert hat. Solange deine Startseite 73 MB !!!!!! groß ist, wird da nix schneller Komm unter 2 MB
Ja, hab ich. Dein Problem sind die Bilder im Kategoriemenü. Du hast da überall grosse Bilder eingefügt, die dann auf mini skaliert im Seitenmenü angezeigt werden. Da sind also so grob 800x800px Bilder, die auf grob 25x25 Pixel gedrückt werden. Die Menübox sieht man auf der Startseite zwar nicht, da die auf anderen Seiten aber angezeigt wird, ist die trotzdem im Code. Das hat mit der Funktionsweise zu tun: Ist die irgendwo an, wird die immer eingebunden, und auf Seiten ohne per CSS ausgeblendet. Der Trick ist also: Icons abschalten oder wirklich Icons in Icongrösse einfügen.
Die Bilder im Kategorie Menü habe ich gar nicht bedacht, da die bei den ersten Tests komischerweise nicht mit auf der Startseite waren. ( und nicht mit bewertet wurden ) Aber die muss ich definitiv kleiner machen, das stimmt. Irgendeine Einstellung im Hintergrund, die ich aktiviert habe hat dies geändert. Vielen Dank euch
Ich wollte auch nochmal ausholen zu: Dazu muss man mal was sagen, das geht nur nicht in kurz. Fangen wir einfach mal irgendwo an: Seitengeschwindigkeit ist ein für uns relativ müßiges Thema, weil man das vielfach oft nicht wissenschaftlich diskutiert bekommt. Da kommt jemand zu uns und sagt "meine Seite ist zu langsam". Wenn jemand das sagt, muss man eine Messlatte dranhalten, und herausfinden ob die Seitenladezeiten in Ordnung sind, und da irgendwie ja oder nein sagen. Solange es keine konkrete Messlatte gibt, wird man nie auf einen Punkt kommen. Grundsätzlichkeiten dazu: Wir sind uns alle einig, dass schneller immer besser ist. Man muss aber auch im Kopf behalten, dass eine geforderte Funktionalität ("Ich brauche eine Startseite mit 87 Artikeln und Beststellerbox und 348 Kategorien im Menü und...") zusammen mit einer gegebenen Menge an Ressourcen (Serverleistung, Leitung, Endgerät...) eine Grenze von einer besten Zeit x setzt. Mehr ist dann einfach nicht. Wenn man der gerade genannten Zeit X nahe kommt, auch wenn man sie nicht ganz erreicht, ist die Welt gut. Ich werde mal wieder kurz bildlich: Wenn ich von Bremen nach München fahren will, brauche ich mit einem Kettcar 14 Tage und mit einem normalen Auto 7,5 Stunden. Wenn ich statt dem normalen Auto einen Lamborari SLK 750i (irgendwas hochgezüchtetes...) nehme, kann ich mich vielleicht noch auf 6,5h steigern, aber das ist kein unglaublich signifikanter Sprung mehr. Den Anspruch, den wir an uns stellen, können wir dabei noch definieren: Wir müssen aufpassen, dass eure Shops keine Kettcars sind, wir haben den Anspruch allermindestens das Auto zu sein. Wir haben sogar den Anspruch an uns selbst, besser zu sein als ein Standardauto, aber nicht um jeden Preis. Was nämlich auch gilt: Pagespeed ist einfach beileibe nicht unser einziges Kriterium, im dem wir für euch und mit euch gut sein wollen. Es geht auch um das Anbieten einer ansprechenden und funktionalen Lösung, die gut konvertiert. Es geht um den SEO-Wert von Seiten und vom gesamten Shop. Es geht um Erweiterbarkeit und Zukunftsfähigkeit, und vieles anders. Wenn eine Optimierung an irgendeinem der genannten Themen die Möglichkeiten bei anderen Themen massiv einschränkt oder die Erreichung kräftigst erschwert, setzen wir die wahrscheinlich nicht um, es sei denn die ist richtig hoch bewertet. Manchmal machen wir das dann auch langsam und Stück für Stück. Wir können nur nicht für einen einseitigen Fokus andere Sachen kaputt machen, das hilft keinem, es braucht eine gesunde Balance. Ihr könnt euch vielleicht auch vorstellen, dass manche Leute in der Kundschaft einseitige Steckenpferde haben. Dem einen Shopbetreiber ist sein Design seine heilige Kuh, egal wie das sonst performed. Anderen die Seitengeschwindigkeit, anderen irgendwelches sonstiges SEO Zeug. Sprich da wird manchmal einseitig fokussiert. Da kommen dann häufiger mal Eingaben im Forum oder per Ticket bei heraus, die wir versuchen in ein Gesamtbild zu verarbeiten, und das dann zu bewerten. Und dabei kommt auch mal heraus, dass wir finden bei jemandem ist alles gut. Wenn das aus unserer Sicht der Fall ist, dann "schmettern" wir das Anliegen ab. Das hat dann wenig mit pauschalem Dauerabschmettern aus Prinzip zu tun. Das kann man uns da natürlich leicht mal vorwerfen, das ist auch schnell gemacht. Der Beweis des Gegenteils fällt uns dann genauso schwer, wie euch der Beweis der "Schuld". Schöner Käse. Wie gehts besser: Wenn jemand sagt "meine Seite ist langsam, dann nennt erstens die gemessene(n) eigenen URLs, die Art der Messwertermittlung und die gemessene Zeit. Meine Seite ist langsam bedingt immer eine gemessene Zeit x auf einem Gerät des Typs y (Desktop/Handy,...) mit einem Browser z. Es ist echt so explizit: Ihr habt keinen Messwert? - Wir haben keine wirklich Diskussionsgrundlage um das hier zu bewerten. Daraus wird dann ohne ein Stammtisch-irgendwas Konvolut bei Beiträgen ohne Ergebnis, die Diskussion wird relativ sicher im Sand verlaufen und alle finden sich doof. Erzeugt also wirklich was ihr an Grundlage liefern könnt. Wir bemühen uns auch wenn nichts da ist dann oft darum Messwerte anzubringen, wenn eure Methodik aber gänzlich anders ist als unsere, kommen wir auch oft genug auf keinen grünen Zweig. Macht also eine Diskussion möglich. Da will ich auch nochmal rein. Da tut sich leider nix heisst ja Gambio kümmert sich nicht um Performance. Das ist falsch, Gambio tut was. Vergleicht mal einen GX 3.0 Shop mit einem GX3.2, der GX3.2 ist schneller. Vergleicht einen GX3.2 mit einem GX3.4, der neuere ist schneller. Vergleicht einen GX3.4 mit einem GX3.6, der neuere ist schneller. Und das kann man so auch fortsetzen... Wenn jemand einen Vortrag darüber will oder die gerade genannte Behauptung anzweifelt, kann ich dazu jeweils Abhandlungen schreiben. Es wird zwar nicht jedes Tuning bei jedem ankommen, wenn wir zum Beispiel die Einbindung von Boxen ins Template tunen und jemand hat alle Boxen aus, dann merkt der nichts, aber wir werden da genug allgemeine Einschläge finden. Wir machen also immer wieder Sachen, um mehr herauszuholen. Bei Performance gibt es eigentlich nie das eine Ding, es gibt die grosse Menge von Stellschrauben. Wir nehmen uns immer wieder Funktionsblöcke vor und optimieren die. Sind wir am Ende angelangt, machen wir das von vorne. Eigentlich jedes mal fällt uns irgendeine Idee ein wo was gehen müsste, jedesmal klemmen wir uns dann dran und probieren das auf die Beine zu stellen. Wenns klappt, kommts in ein Release. Ich schliesse mal meinen Vortrag mit ein paar Dingen ab, die da frisch unterwegs sind, um das gesagte zu unterlegen: Aus GXModules heraus können Entwickler Frontend-Boxen überladen. Bei jedem Seitenaufruf wird aktuell das gesamte GXModules Verzeichnis durchsucht ob solche Überladungen da sind. Bei einigen Hostern merkt man davon nichts in der Performance, bei einigen anderen Mittelklasse Hostern haut das erkennbar ins Kontor. Es wird mit 3.8.3.0 und 3.9.3.0 ein neuer Boxencache eingeführt, der die dauernden Verzeichnisscans beseitigt. Der Effekt ist in einigen Shops nicht messbar, in anderen bei ca. 500ms messbar. Im Footer gibt es eine Rekursion um nach Elementen zu suchen, die relativ viele Funktionen immer wieder neu anschiebt. Dieses anschieben kostet bei manchen Hostern messbar Zeit, die Funktion wurde darum neu und umgebaut und wird so in GX 3.11 kommen. Der gemittelte Gewinn ist in einem Standardhsoting bei ca 50ms. Boxen im Frontend werden teilweise häufiger als nötig berechnet. Das bedeutet die werden auch für Seiten erzeugt, in denen die gar nicht sichtbar sind, wenn auch in anderen. Durch eine bessere Methodik wird das ab GX3.11 seltener der Fall sein, der Effekt liegt je nach Mustershop für betroffene Seiten zwischen 0ms und 500ms. Wir erwarten weitere Effekte aus weiteren Ideen, zum Beispiel Aufräumvorgänge nach dem Ende von Eyecandy, die noch nicht materialisiert sind, etc. Ich bin mir ziemlich sicher, dass wir damit auf gutem Kurs liegen und das Thema Performance gut bearbeiten. Wenn jemand Fragen oder Einwände hat, immer rein damit, wir reden dann darüber.
Lieber Wilken, lukas_nowrot hat hier anfangs gefragt was er machen kann um seine Ladezeit zu verbessern, von dir kam nichts von mir ein paar mögliche Tips, wo was möglich ist und woran es bei ihm hapert. Weiterhin habe ich auch gesagt das viele sich die Bremsen selbst einbauen und das Pagespeed nicht alles ist, da viele Faktoren ebend eine Rolle spielen. Das war bis zu dem Punkt auch kein Vorwurf und keine Kritik an dich oder an Gambio, ich war ledeglich hilfsbereit. Nachdem du dann warum auch immer meinen Vorschlag an lukas_nowrot zitiert und mit nicht hilfreichen Kommentaren versehen hast, habe ich dich mal mit den Tatsachen konfrontiert so wie sie ein Nutzer sieht und wie es auch bei Ihm zu Problemen geführt hat. (Manche wissen eben nicht wo man was einstellt und das Bilder auch für Weibseiten optimiert werden müssen). Es ging mir bei meinen Beiträgen aber nie darum zu sagen bei Gambio ist alles blööd und alles zu langsam und die machen nichts in Sachen Performance, im Gegenteil ich weiß sehr wohl das bei euch viel gemacht wird und das Ihr oder euer Team viel Zeit und Mühe investiert. Was aber grundlegend nervt ist, (vieleicht bilde ich mir das auch nur ein) das du manchmal wie auch hier in den ersten Antworten vorschnell Kommentare abgibst die nicht sinnvoll und nicht hilfreich sind und dann nach einigen Diskusionen wenn man dich auf die Palme gebracht hat, endlich die Antwort gibst die du vieleicht schon am Anfang hättest geben müssen. Und nein, ich wiederhole es gerne auch hier nochmal, ich hab nichts gegen dich und ich bin auch niemand der jetzt weil du mal zu meinen Kommentaren was blödes geschrieben hast ein Rachfeldzug startet. Ich kann das sogar nachvollziehen, Threads wie diese gibt es sicherlich hunderfach und die werden auch immer wieder auftauchen, dass das manchmal nervt ist klar, das man nicht immer alle glücklich machen kann und jeder andere Wünsche hat ist mir auch klar. Aber Antworte doch bitte gleich wie z.B. Marco oder Torben ordentlich, versuch nicht etwas zu wiederlegen was nicht wiederlegt werden kann und diskutier nicht erst paar Stunden rum. So und jetzt ganz vorwurfsloses Feedback für dein Merkzettel das sind von Anfang an bis jetzt die Problemstellen: - Bilder, die hochgeladen werden sind und werden nicht richtig für das Web optimiert. - Sehr viele Scripte von Haus aus, die geladen werden müssen. - Sehr umfangreiches CSS wobei fraglich ist ob vieles davon schon auf der Startseite mitgeladen werden muss. Dieses sind nunmal nicht weg zu diskutierende Punkte die die Ladezeit blockieren ohne das überhaupt eigene Eingriffe gemacht wurden. Und wenn Ihr was ich glaube zu einem der besten Shopsysteme werden wollt müsst Ihr hier nochmal ansetzen und was ändern damit auch noch Freiraum für eine Gestaltung und Produktdarstellung bleibt. Ich danke dir aber nochmal für die investierte Zeit und den sehr ausführlichen Blick auf das von euch angestrebte Ziel.
Hier hak' ich mal eben ein: Wir hatten schon mal Versuche unternommen ein CSS-Paket zu erstellen, welches nur die Infos enthält, die notwendig wären um das Grundgerüst sauber darstellen zu können. Der fertige Code war dann aber so groß, dass es echt nicht sinnvoll gewesen ist, diese auszuliefern, weil es keinen nennenswerten Vorteil gebracht hätte. Der Tipp, Inline-CSS für das Grundgerüst der Seite zu liefern, damit das Ganze schneller läd, lässt sich aber eigentlich auch nur auf einfache Webseiten anwenden, die nicht so komplex und groß wie ein gesamtes Shoptemplate sind, welches zudem auch noch responsiv ist. Ich weiß, dass Google Pagespeed Insights das wahnsinnig gerne überall haben möchte, aber oft ist die Realität einfach eine andere und bringen tut es letztlich kaum etwas. Vieles kann man doch über die Bildoptionen einstellen, sodass das Imageprocessing die Bilder entsprechend generieren kann oder fehlt da deiner Meinung noch etwas? Man muss da aber auch die richtige Mitte aus komprimierten Bildern und Qualität finden. Komprimiert man die Bilder zu stark, laden sie schnell, sehen aber nicht mehr ansprechend aus, komprimiert man sie nicht, sehen sie gut aus, laden aber langsamer. Dabei ist auch zu beachten, dass die Google Bildersuche lieber größere Bilder hat und das ein nicht zu unterschätzender Rankingfaktor sein kann, was für eine Qualität die Bilder haben. Das was Google Pagespeed da als "optimierte" Version der Bilder zurück gibt, kann man aber alles andere als ansprechend nennen. Das ist mehr eine Anhäufung von Pixeln. Ich gebe dir recht, es gibt sehr viele JavaScripte im Shop. Da besteht bestimmt auch noch Optimierungsbedarf und auch da arbeiten wir dran, dass die das Laden der Seite nicht künstlich ausbremsen.
Beim abschicken zeigt mir das Forum gerade Torben hat auch geschrieben. Weil wir nicht ganz deckungsgleich sind und viele eigene Punkte in den jeweiligen texten sind, poste ich meinen trotzdem noch. Eben doch! Das ist ja der Haken. Nehmen wir mal als Beispiel das CSS. In einem Shop mit Standardkonfiguration wird das CSS in eine einzelne Cache-Datei aggregiert, die dann als main.min.css im Shop liegt. Diese Datei enthält in einem Stück das gesamte CSS für alle Frontendseiten und hat dann eine Grösse von etwa 500kb auf der Serverfestplatte. Über die Leitung müssen dann üblicherweise ca 60kb, weil ein Standardwebserver die Datei aufgrund unserer Voroptimierungen gzipped an den Browser sendet. Vermuten wir den gängigen Worstcase, lahmes DSL: 60kb verursachen bei DSL 1000 (entspricht 125kb/Sekunde) eine Ladezeit von etwas unter 0,5 Sekunden. Diese eine CSS Datei wird dann im Browsercache gelagert. Wenn der Kunde von der Startseite in eine Kategorie oder ein Produkt oder wohin auch immer surfed, wird die daher nicht mehr neu geladen, sondern komplett aus dem lokalen Browsercache auf dem Kundengerät gezogen. Wir haben dann also 0 Wartezeit, denn auch dafür haben wir den Shop voroptimiert. Wenn wir das CSS jetzt weiter zerpflücken, wir haben damit gespielt, wird das schnell viel schwieriger zu warten. Die Anforderungen an uns und an den Shopbetreiber werden höher, wobei die an uns noch recht egal wären. Das Problem ist, dass CSS Anweisungen einmalig für die richtigen Seiten und Elemente da sein sollen. Wir müssen dann mehr Orte einbauen, wo man CSS gezielt einsetzen kann, der Shopbetreiber muss sich für den richtigen Ort entscheiden und die Kompetenz dazu bilden. Gehen die Styles redundant an mehrere Orte, weil der Nutzer nicht weiss wo er hinmuss, erzeugen die Duplikate und Komplexität schnell soviel Overhead, dass jeder Nutzen dahin ist. Das führt zu: Wir haben im Moment nicht vor, dass CSS aufzusplitten. Wir sehen "Kosten/Nutzen" als in keinem Verhältnis stehend. Thema Inline Styles im HTML: Jetzt lassen wir den Browser einmal unser 60kb Stylepaket holen und cachen das für alle Folgeseiten. Wenn die Styles im HTML ausgegeben werden, dass wir zwangsweise für jede einzelne Unterseite die aufgerufen wird neu ausgeben müssen, wird jede Seite um den Faktor der Grösse des CSS auf der Leitung grössera, also langsamer Geht ein Nutzer für einen Kauf im optimalen Fall über grob 10 Seiten, laden 9 von 10 um den Faktor CSS Ladezeit langsamer. Nur bei der 1 von 10 haben wir einen leichten Spareffekt, weil ein Client-Server-Request nicht stattfinden muss. Dazu kommt noch, dass wir das CSS immer beim Seitenerzeugen von PHP lesen lassen müssen und mit in die Ausgabe drücken lassen müssen. Das kostet erstaunlich viel Zeit, selbst wenn das als fertige Datei auf der Serverplatte liegt, üblicherweise ein dreistelliger ms Betrag. Wir hatten schon, dass 9 von 10 Seiten durch Inline CSS langsamer werden, jetzt wirds aber spannend: Seite 1 von 10 wirds auch, durch die zusätzliche Verarbeitung. Eine Verbindung aufbauen und für einen schnellen Transfer von Daten einrichten (Webserver liefert statische CSS Datei ohne mit PHP reden zu müssen...) geht normal schneller, als PHP die Styles liefern zu lassen. Damit haben wir final das Ergebnis, dass 10 von 10 Seiten langsamer sind. Das führt zu: Wir raten Shopbetreibern, dass CSS NICHT Inline auszugeben, und die Standardvoreinstellung im Shop hier zu belassen. Das steht bewusst und bekannt in Kontrast zu den z.B. Empfehlungen von Google Pagespeed Insights. Dann das Thema Bildergrösse: Je kleiner die Bilder, desto schneller die Ladezeit. Dem entgegen steht die Aussage einiger vertrauenswürdiger SEO Leute die sagen je kleiner die Bilder, desto geringer der Seitenwert für Google. Ja was denn nun? Was man immer tun kann, ist die Bildkompression für sich passend einzustellen. Dazu gabs mal einen langen Artikel im Blog von mir, findet man dort noch. Wir haben uns aber an einigen Stellen entschieden in Pixel grössere Bilder als "nötig" im Shop darzustellen, dass ist eine SEO-Massnahme. Das führt zu: Für Kategorien und die Startseite kann in den Template Optionen auf die Verwendung kleiner Bilder umstellen, standardmässig sind grössere Bilder aktiv. Dies ist so auch unsere Empfehlung. Thema sehr viele Scripte von Haus aus, die geladen werden müssen Ja, wir laden relativ viel Javascript. Wir haben schon mal einen Teil rausgeworfen, aber es ist immernoch nicht wenig. Wir glauben aber, dass wir da nicht völlig falsch liegen. Der Punkt ist: Sehr viele verschiedene Leute wollen sehr viele verschiedene Dinge mit dem Shop tun. Es wird Bootstrap, Jquery, JqueryUI und vieles andere erwartet, damit die Leute sich austoben können, also muss all das da sein. Wir verwenden RequireJS um nach Möglichkeit Dinge auch mal nur bei Bedarf zu laden, wer also das Template entspeckt gewinnt ein wenig. Wir wollen keine Fettschwarte liefern, die Reduktion auf nahe 0 Javascript ist bei uns aber auch kein Ziel. So funktioniert das Web nicht mehr, daran hegen wir auch kein Interesse. Worauf man achten kann: Der eigene Webserver sollte HTTP2.0 unterstützen und anbieten. Das gibt einen spürbaren Performanceboost aufgrund effizienterer Übertragung gerade in unserem Fall hier. Jetzt nochmal kurz zum nicht wegdiskutieren können oder eben doch: Egal wie felsenfest jemand etwas glaubt, es muss real nicht felsenfest sein. Das gilt für unsere Meinungen genauso wie für externe Meinungen wie deine. Du klingst hier ziemlich exakt wie Google Pagespeed Insights, von dem Tool halten wir aber für den Laien eher ziemlich wenig. Es sieht einfach aus was da rauskommt, es liest sich gut, es passt nur oft nicht zur Welt. Warum das so ist, hat Torben auch mal einen langen Blogbeitrag in unserem Blog geschrieben, der gilt noch und ist da lesenswert.
Wir benutzen Google Pagespeed aber nicht. Wir nutzen dieses hier (Link nur für registrierte Nutzer sichtbar.) mit der detallierten Seitenanalyse und da dürft ihr gerne mal unsere Shop Adresse (Link nur für registrierte Nutzer sichtbar.)eingeben. LG und schönen 1 Mai
Gerade mal die Seite angeschaut. Laut Auskunft in deren Impressum nutzen die Google Pagespeed Insights für Ihre Auswertungen und stellen die nur optisch anders dar. Zitat aus dem Impressum:
So, wie angedroht, habe ich jetzt Netdexx zur Hilfe gezogen und mir ein Template gekauft. Die Leute bei dieser Firma sind sehr sehr nett und helfen so lange bis das ganze in Zufriedenheit ausartet. Witziger weise ist jetzt der Shop um mehr als die hälfte schneller geworden. Denke mal es liegt wohl am Template selbst. War vorher bei gleichem Inhalt bei ca. 2,56 sek. und jetzt unter 0,5 sek!!! Das ist echt ein Unterschied.