WooCommerce: VPS (8GB RAM) vs. GTmetrix D & F0-Fehler. Warum kein A-Grade?

croxxx69

Lt. Junior Grade
Registriert
Sep. 2007
Beiträge
441
Hallo zusammen,

ich brauche eure Hilfe bei der Optimierung meines WooCommerce-Shops.

Ich versuche, die vertraglich vereinbarten Speed-Ziele (GTmetrix Grade A / PageSpeed Mobile 80+) zu erreichen. Mein aktueller Entwickler sagt, dass die Seite nun am Leistungs-Maximum angekommen ist. Ich bin jedoch nicht überzeugt.

Aktuelle Performance-Werte:

GTmetrix: D (60%)
PageSpeed Mobile: 62 (LCP: 8.4s – Core Web Vitals nicht bestanden)

Die Seitengröße ist mit 10.5 MB immer noch viel zu hoch.

Dringendste fundamentale Server-Fehler (F0):

Server-Komprimierung (Gzip/Brotli) ist nicht aktiv.
Browser-Caching (Expires Headers) fehlt vollständig.

Mein Ziel ist es, diese F0-Fehler zu beheben und den LCP in den grünen Bereich zu bringen.

Gibt es, eurer Meinung nach, noch Spielraum für Verbesserungen, oder hat der Entwickler mit dem Erreichen des Maximums Recht? Was sollte jetzt der wichtigste nächste Schritt sein, um diese fundamentalen Fehler zu korrigieren?

Vielen Dank für eure Hilfe und Tipps!

Meine Seite:
https://jeftini-top-proizvodi.com/

VPS Server Spezifikationen (Hostinger KVM 2):

2 vCPU cores
8 GB RAM
100 GB NVMe Disk

Die Server-Auslastung ist niedrig (CPU 11%, RAM 29%).
 
Die Fehler sind doch eindeutig und das ist aus meiner Sicht erstmal Sache der Konfiguration und nicht der Hardware.
 
Kann jetzt zu der Thematik nichts beitragen, bin aber mal auf deine Seite gegangen: Während das Grundgerüst der Seite relativ schnell da war, dauerte es 3 Minuten bis mir erste Bilder angezeigt wurden. So lange wartet doch kein normaler User.
 
  • Gefällt mir
Reaktionen: Der Lord und AB´solut SiD
Holt sich die Site die Temu Angebote JustInTime oder cached da irgendwas? Reseller von Temu, sachen gibts....
 
Unterscheiden wir zunächst Performance client-seitig und server-seitig.

Client-seitig

Allein die front page lädt ~50 Stylesheets, ~60 JavaScripts, 15 Fonts + Bilder in insgesamt 3,67 MiB. Durch das zusammenfügen von CSS und JS Dateien kann man die Anzahl Requests erheblich reduzieren, wodurch die Seite sich schneller aufbauen sollte. Dafür existieren diverse Wordpress Plugins => handlungsbedarf

Komprimierung ist durchgehend aktiv soweit ich sehe, teils zstd, teils brotli. Korrekterweise werden png, jpg & woff2 nicht nochmal komprimiert => passt
Cache-Control Header sind auch alle gesetzt, ein erneutes Laden der Page überträgt hier nur noch 80 KiB (wobei 78 KiB davon zwei 404 Pages sind, siehe unten) => passt

Ferner habt ihr ja auch CloudFlare vorgeschaltet; dem cf-cache-status Header nach cached cloudflare auch alle statischen ressourcen, so dass nur die wenigsten Requests euren VPS treffen => passt

Ansonsten sind WordPress, WooCemmerce, Elementor und das Theme halt ziemlich fette Dinger die nicht auf Performance ausgelegt sind. Mit entsprechendem Know-how und Zeitaufwand kann man hier aber sicherlich noch Optimierungen finden um weniger Daten auf dem Client laden zu müssen.


Server-seitig

Die Latenz für den ersten Request liegt ständig über 300ms und auch mehrere Sekunden sind keine Seltenheit. Fühlt sich an als käme der Server schon gut ins Schwitzen.
  • Zu wenig Worker für PHP?
  • Zu kleine memory pools für MySQL/MariaDB/etc.?
  • Irgendwelche Fehlkonfigurationen in PHP? Opcache groß genug?
  • Irgendein cache der server-seitig genutzt wird? Redis/memcache/APCu?
  • Was sagt die Site Health im Admin Panel?
Ferner sollten im Optimalfall auch ganze Seitenaufrufe gecached werden. Dafür gibt es Plugins wie Total Cache, Super Cache oder wie sie alle heißen. Eventuell kann man sich hier auch Cloudflare zu Nutze machen.

Was unbedingt behoben werden sollte ist ein eingebettetes Bild das nicht existiert (https://jeftini-top-proizvodi.com/staging/wp-content/uploads/revslider/slider-tech-accessories-v3/slider-accessories-v3-bg.jpg): Dieses Bild wird 2x geladen und gibt jedes mal einen 404 Fehler, der aber von der WordPress Software generiert wird. D.h. für jeden Seitenaufruf hast du 2 unnötige zusätzliche Seitenaufrufe und somit bis zu 3x CPU-Last.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: croxxx69
AB´solut SiD schrieb:
Holt sich die Site die Temu Angebote JustInTime oder cached da irgendwas? Reseller von Temu, sachen gibts....

Vielen Dank für die Kommentare.

Ich bin etwas verwirrt über die Vermutung mit den Temu-Angeboten. Dazu eine technische Klarstellung: Meine Seite ist ein ganz normaler WooCommerce-Shop. Alle Produktdaten werden lokal in meiner Datenbank und über WP Rocket und Cloudflare gecached. Wir rufen die Angebote nicht Just-In-Time von anderen Plattformen ab.

Das bringt mich zu meinem Hauptproblem, der Ladegeschwindigkeit.

Fragen zur Geschwindigkeit (LCP & CDN)

Wenn du sagst, dass die Bilder drei Minuten zum Laden brauchen, ist das ein massives Problem und erklärt meinen schlechten LCP-Wert (8,4s).

Bei mir selbst lädt die Seite schnell:
https://drive.google.com/file/d/16px2MPqbJ3gBVTLM-wOttB579NziWuPG/view?usp=sharing
  • Kann es sein, dass die massive Geschwindigkeitsdifferenz für Nutzer außerhalb meines Landes durch Cloudflare oder die geografische Distanz verursacht wird?
  • Muss die CDN-Konfiguration (Cloudflare) für dynamische Inhalte oder Remote-Nutzer aggressiver eingestellt werden?
 
croxxx69 schrieb:
Kann es sein, dass die massive Geschwindigkeitsdifferenz für Nutzer außerhalb meines Landes durch Cloudflare oder die geografische Distanz verursacht wird?
Möglich wäre es. Ich nehme an, dass Du die Webseite in Kroatien hostest, aber da sollte die geografische Distanz meiner Ansicht nach keine große Rolle spielen, es geht ja nur um eine Webseite und nicht um einen Multiplayer-Shooter, wo es auf geringe Latenzen (Pingzeiten) ankommt. Ich bin bei der Deutschen Telekom als ISP, vielleicht spielt hier auch das oft gescholtene Peering der Telekom rein, dass das Laden bei mir so lange dauert.

Da du sehr viele Bilder auf deiner Homepage hast, die anscheinend alle gleichzeitig geladen werden sollen: Belies dich mal zum Thema "Lazy Loading", so dass Bilder erst geladen werden, wenn sie im für den Benutzer sichtbaren Bereich liegen. Vielleicht nimmt das auch noch mal ein bisschen Last weg. Ist aber nur eine Vermutung meinerseits.
 
Der Server ist in Deutschland.
Lazy Loading ist aktiviert.
Was ich komisch finde, ist das mir jetzt diese Speed Tests nicht mehr die ganze Seite anzeigen und demnach auch um die 60 von 100 anzeigen? Wenn ich es bei meinen Chrome Browser (private mode) unter Lighthouse teste (mobile test), dann bekomme ich um die 30-40... (Bilder im Anhang) Komisch oder normal?
 

Anhänge

  • Slika zaslona 2025-10-08 u 00.11.05.png
    Slika zaslona 2025-10-08 u 00.11.05.png
    906,2 KB · Aufrufe: 51
  • Slika zaslona 2025-10-07 u 18.43.01.png
    Slika zaslona 2025-10-07 u 18.43.01.png
    120,2 KB · Aufrufe: 53
Hallo zusammen,
ich habe ein Problem mit Google PageSpeed Insights und möchte eure Meinung hören:

Ich habe gestern meinen Entwickler gebeten, die Ladegeschwindigkeit meiner Website zu verbessern.

Heute zeigt PageSpeed einen Score von ca. 63 an (vorher ~20).

Im „Final Screenshot“ / Preview fehlt jedoch das Hero-Bild / der größte Content (LCP). Ich sehe nur Menü und Hintergrundfarbe.

Wenn ich die Seite selbst im Browser öffne, ist alles normal sichtbar.

Die anderen PageSpeed-Ergebnisse sind trotz eines leistungsfähigen VPS-Servers (2 vCPU Cores, 8 GB RAM, 100 GB NVMe, 8 TB Bandbreite) weiterhin auffallend schlecht.

Meine Fragen:

Kann man PageSpeed-Ergebnisse “fake-mäßig” verbessern, z.B. indem man Inhalte versteckt oder verzögert, sodass Googlebot sie nicht sieht, der Score aber steigt?

Wo genau könnte so etwas technisch passieren – JS, CSS, Lazy Load, Critical CSS oder sonstige Optimierungen?

Gibt es eine Möglichkeit nachzuvollziehen, was der Entwickler genau geändert hat, um diesen “Score-Boost” zu erreichen?

Hat jemand Erfahrung, dass PageSpeed zwar bessere Zahlen zeigt, die Seite aber für Google/SEO tatsächlich schlechter wird, weil LCP nicht geladen wird?


Danke für jede Einschätzung und Tipps, wie man das debuggen oder prüfen kann.


@Marco01_809
Die Fehler mit dem Bild wurde behoben...
 

Anhänge

  • Slika zaslona 2025-11-06 u 19.44.17.jpg
    Slika zaslona 2025-11-06 u 19.44.17.jpg
    169,9 KB · Aufrufe: 38
Zurück
Oben