Leidiges Thema Ladezeiten

Der Shop hat viele Caches für viele verschiedene Anwendungszwecke. Alle sind dafür da irgendwas schneller zu machen.

Cache ist einfach ein Wort für einen Ort, an dem man vorherige Ergebnisse von irgendwas ablegt, um beim nächsten mal, wenn dieselbe Aufgabe besteht, nicht wieder bei 0 anfangen zu müssen.

Wenn man über Caches spricht, kommt es sehr genau darauf an, zu benennen für was der Cache sein soll, dann kann man sagen obs den gibt oder nicht, wenn ja warum, wenn nein warum nicht.

Beispiel: Ein Besucher ruft eine Shopseite im Frontend auf. Als allererstes wird da der PHP Klassencache geladen, mit dem sich der Shop merkt welche Logikroutinen es im Code gibt. Dann wird die HTML Seite errechnet. Dazu werden zum Beispiel Elemente benutzt, die im Smarty Cache liegen, quasi Seitenfragmente. Vielleicht ist es ein Variantenartikel, dann werden auch Sachen aus den Variantencachetabellen benutzt. Wenn die HTML Seite fertig ist, wird die an den Browser gesendet. Darin sind dann üblicherweise zum Beispiel CSS und Javascripte referenziert, also Dinge die der Browser dann herunterladen muss. Diese Sachen werden dann, bei erstem Seitenabruf aus dem CSS und Javascript Cachedateien des Shops geladen, in denen der Shop solche Sachen fertig zusammengefasst bereitlegt. Ist es nicht die erste Seite, kommen diese Elemente eher aus dem Browsercache, mit dem der Browser sich Dinge wie CSS, JS und Bilder, Webfonts, etc. merken darf.

Was der Shop nicht hat, ist ein sogenannter Vollseitencache. Jedesmal wenn eine Seite abgerufen wird, werden diverse Kernelemente von Seiten neu erzeugt. So stellen wir sicher, dass Kunden immer den aktuellen Preis sehen, den aktuellen Bestand, wechselnde Empfehlungen, Zufallselemente der Seiten und so weiter.

Man kann auch eine fertige Tapete bauen und immer gleich ausrollen, das ist schneller, da wird nichts gerechnet. Das macht das Werbemarkt Modul. Das macht dann aber auch neue Probleme, und zwar genau an den Stellen wo normal ein Inhalt dynamisch ist. Eine Tapete ist nunmal immer gleich. Da muss man dann in die andere Richtung tricksen, um vielleicht doch noch ein paar Elemente in der Seite irgendwie grob dynamisch zu kriegen und zahlt den Preis dafür.

Was Wordpress etc angeht: Erstmal ist das meistens eher lahm, wenn da einiges drin ist. Das Problem ist da oft grösser. Zweitens sind redaktionelle Seiten meistens viel statischer. Da immer dieselbe Tapete ausrollen ist meistens einfach ohne Problem drin. Da sind nie Artikel ausverkauft oder Preise neu, das ist was anderes.

Wir glauben immer ein paar Sachen:

Der erste Glauben ist, dass wir uns generell auf einem ganz guten Kompromiss aus Geschwindigkeit und Seitendynamik bewegen, wenn der Shop ohne Extras auf einer anständigen Plattform läuft. Einen Vollseitencache zusätzlich planen wir für den Shop nicht. Wer will kann sich das Modul von Dominik reinnageln, das ist nur kein Universalrezept oder Tipp. Man muss kucken, ob man mit den technischen Kosten für genau den eigenen Fall leben kann. In manchen Shops, die wenig Dynamik haben, ist das super. In anderen Fällen macht das Usecases hart kaputt, es gibt für beides ausreichend Beispiele.

Der zweite Glauben: Eine Seite muss für einen Benutzer gut sein, das ist wichtig. Wie fühlt der sich, wenn der darüber surft? Diese Frage ist die Frage der Fragen. Die letzten Millisekunden jagen ist oft nichts anderes als grobe Zeitverschwendung und heillose Esoterik. Ja, Seitengeschwindigkeit ist such ein Ranking Faktor, aber eben nur einer von sehr sehr sehr vielen. Wenn man da viel Zeit reinsteckt, fehlt die garantiert woanders, wo es deutlich wichtiger wäre. Das Pareto Prinzip ist da gut angewandt: Soviel Zeit investieren, das es für die meisten passt. Mit 20% Aufwand befriedigt man 80% der Zielkundschaft. Dann noch viel Zeit für einen kleinen Rest anwenden... da sollte man zum nächsten Thema.

 

Wie immer sehr ausführlich und nachvollziehbar... top
Eine Frage hätte ich dennoch zu dem von Dir nicht erwähnten ;-)

Wie siehst Du das mit den Ergänzungen in der htaccess und robots.txt?
Meinst Du das bringt was?

Wenn ich alleine sehe wie groß die beiden Dateien zusammen sind, steuer ich ja damit fast auf den "First Contentful Paint" zu, Scherz.

Ich habe auch für einen Kunden den Provider gewechselt, da bei dem empfohlenen Anbieter dreistellige Userdaten vorhanden waren. Wordpress-Backend-Zeiten von 3-8 Sekunden gingen mir dann doch auf den Nerv. (frontend war ok)
Bei dem anderen Server ist es auf 50 Kunden begrenzt. Wesentlich besser!
Wordpress (statisch) ist in ner Sekunde da, Datenbank wie von dir auch erwähnt schneller, aber immer noch bremsend.
Da kommen die gambio-Shops auf dem "langsameren" Server problemlos mit.

Dennoch bastel ich da auch gerne rum auf meinem langsameren "Gambio-Server" (siehe meine letzten Tickets ;-) ).
Und auch da möchte ich mehr rausholen. Theme-Wechsel und svg-Grafiken sind das eine.
Serverbelastung minimieren das andere.

Ich weiß nicht wieviel mir das ausschließen einiger Bots zu Zeiten X auf einem shard-Server bringt in Bezug auf die Gambiodatenbank.

Hast Du da Erfahrungen mit?

 

@harryk

Vielen Dank für Deine umfangreichen Ausführungen. Könntest Du mir noch sagen, an welcher Stelle der htaccess-Datei ich die Angaben einfügen soll / muss.

Vielen Dank.

 

In aller Regel bringt das wenig.

Teuer (im Sinne von Last, es gibt technisch auch den Begriff teuer) ist nie die Dateilänge, teuer sind Reihungen komplexer Statements, die dann im Falle zum Beispiel der htaccess Datei für jeden einzelnen Request immer neu ausgewertet werden müssen.

Beispiel: Jemand leitet da 3000 URLs per Rewrite Regel um. Kann man machen, bedeutet aber absolut jeder Request muss erstmal gegen 3000 vorgegebene Ziele abgeglichen werden. Das kostet Zeit.

Dateikürze als absolutes Optimierungsargument ist also Banane, erfasste Komplexität liefert Argumente.

Die Frage ist dann beantwortbar, wenn man erstens weiss ob diese Bots überhaupt kommen, zweitens weiss was es für Folgen hat wenn die A kommen oder B nicht kommen (die kommen ja für einen Zweck) und drittens wieviel die überhaupt jeweils abfragen.

Beispiel: Wir sehen häufiger "Künstler", die viele Zugriffe von einzelnen IPs auf ihren Shops sehen. Die bauen dann kurzerhand ne IP Sperre dafür ein, weil das kann jawohl nicht sein. Hinterher sinkt das Google Ranking, weil die den Google Bildercrawler blockiert haben.

Also immer erst informieren, dann damit denken, dann und nur im Bedarf die Kanone benutzen.

 

Hallo Wilken,

vielen Dank das Du das hier so Gut erklärt hast !
Das erklärt mir schon vieles mehr.

Gruss Isabel

 

Hi Leute,

ich hab zu dem Thema auch noch ein paar Dinge in den Raum zu werfen:

1. Alles steht und fällt mit dem richtigen Hosting.
Nach vielen Stationen mit Shared Hosting auf Webhostingpaketen und Vservern, sind wir letztlich
bei einem managed dedicated Server gelandet. Das das nicht für jeden gambio Shop Sinn macht - ist mir klar.
Ab einer gewissen Artikelanzahl (bei uns aktuell 58799 Artikel) und entsprechenden Umsätzen macht es aber mehr als Sinn
und die Investition in einen eigenen Server, welcher mit niemandem geteilt wird, macht sich bezahlt.
Einen vernünftigen, leistungsstarken Server bekommt man hier: https://www.vc-server.de/agentur-server/
Wir sind bei diesem Hoster nun einige Jahre und sind top zufrieden. Klare Empfehlung von mir.
Bei der Wahl Eures Servers müsst Ihr auf folgendes achten:

1. Keine Consumerware (nur Marken-Businesshardware, getestet für den 24h Einsatz)
2. 1 GBit Anbindung, am besten redundant (100 mbit sollte der Vergangenheit angehören)
3. Nähe zum DE-CIX (Serverstandort am besten Frankfurt)
4. Ihr kennt die Verwaltungssoftware und könnt gut damit arbeiten
5. Let`s Encrypt kostenlose SSL Zertifikate stehen einfach und ohne viel Aufwand zur Verfügung
6. Im Rechenzentrum sind mehrere redundante Firewall-Server vor euren Server geschaltet
7. Mail-Security-Gateways können zugebucht werden
8. Keine versteckten Hands-on-time Kosten im Kleingedruckten
9. Hoster hat eigenen Domainrobot und günstige Domainpreise
uvm ...

2. ebay Bilder + Hotlinking (trifft auch für hood.de zu)
Wer bei ebay verkauft und die Artikel über eine Schnittstelle wie magnalister zu ebay überträgt,
wird sicher auch ein eigenes Design und Bilder in seiner ebay Artikelbeschreibung nutzen.
Beim Übertragen der Artikel müssen die Bilder für die ebay Bildergalerie aus Eurem
Bilderverzeichnis geladen werden ( z.B. images/product_images/original_images ).
Die Bilder die in Eurer ebay Artikelbeschreibung zusätzlich anzeigt werden,
müssen via Hotlink eingebunden werden.
Sowohl der Download der Bilder aus dem Bilderverzeichnis, als auch
das Hotlinking in der Artikelbeschreibung - sind Posten die auf die Serverperformance
gehen - und somit auf die Ladezeiten.
Und das gilt nicht nur für ebay - sondern alle externen Marktplätze.
Lösung:
Bilder auslagern und hochverfügbar machen. Unsere Wahl: https://www.keycdn.com/
Dort kann man Pushzonen erstellen und die Bilder via FTP hochladen.
In magnalister oder anderen Schnittstellen muss dann nur noch
das Bilderverzeichnis richtig eingestellt werden auf die externe Ressource:

Hinweis: bei keycdn kann man einzelne Länder und Standorte, wie z.B. Russland, von den eigenen Pushzonen
ausschließen, einfach den Support anschreiben und ausschließen lassen.

3. Nach und nach alle externe Ressourcen im eigenen Shop ersetzen, wie CDNs von font awesome, jquery, google fonts usw. Diese ersetzen mit lokalen Lösungen (muss ich auch noch nachholen teilweise).
Beispiel google fonts:
Von google fonts die original .woff / .woff2 Dateien herunterladen und auf
Eurem Server speichern und dann via css einbauen.
Hier eine Anleitung wie das geht.
Hier noch eine andere Anleitung
Cooler Nebeneffekt von lokalen Lösungen:
Ihr müsst Euch keine Sorgen wegen Datenschutz machen,
was ja u.a. bei google fonts problematisch ist...


4. Datenbankzugriffe minimieren
Wer externe Tools wie eine Warenwirtschaft nutzt,
sollte sich gut überlegen wie er diese an den Shop anbindet.
Die meisten werden wohl direkt an die Datenbank des Shops gehen
und so Eure Ladezeiten schmälern.
Lösung:
Tabellen wie orders oder orders_products in eine separate Datenbank spiegeln,
und die Warenwirtschaft dort auslesen lassen. Euer Shop dankt es Euch.
Wer z.B. eigene Statistiken auslesen will, kann das ganze dann noch weiterspinnen
und die mit Cronjob gespiegelte Datenbank nehmen und diese splitten,
z.B. die Tabelle orders splitten zu weiteren Tabellen orders_2021, orders_2022, orders_2023 usw. ...


Ich liege aktuell bei folgenden Ladezeiten:
Startseite: ~ 0,91 Sekunden
Artikelseite: ~ 0,69 Sekunden


Beste Grüße
Peter