Übermässiger Verbrauch von Serverressourcen (Apache - Simultane Verbindungen pro IP-Adresse)

Wir finden den Unterschied nicht signifikant.

Du misst nicht das Skript, du misst irgendwas anderes. Was wäre zu klären, aber der Schluss kann so nicht aufgehen:

Javascript funktioniert so: Du lädst ein HTML Dokument. Darin sind andere Assets wie Javascripts referenziert ("verlinkt") die der Browser dann nachlädt. Der muss ja erstmal wissen was er nachladen soll. Das Javascript von PayPal lädt man unter einer statischen Adresse, da muss nichts errechnet werden, darum ändert sich die Aufbereitungszeit für das HTML Dokument sehr nahe 0. Und wenn die sich nicht ändert, verschiebt sich die Time to first byte nicht. Und die wiederum würde auch nicht berücksichtigen, wieviel das Javascript eine Gesamtladezeit, also HTML und dann alle Asets, effizient bremst.

 

Was soll ich sagen: Dass ist der gemessene Effekt.

 

Hinweis:
Ich messe gar nichts, gtmetrix misst und ich weiß auch nicht was deren Definition von TTFB ist
Aber an der Anzeige in gtmetrix sieht man es am schnellsten und an dem Hinweis: "Reduce inital server response time".

Ich finde rd 0,5 Sekunden Unterschied sind durchaus signifkant, wenn man ein Script lädt, dass man an der Stelle (zumindest offensichtlich für mich) nicht braucht.

Vorgehensweise:
gtmetrix laufen lassen => langsamer
"Direkt zu PayPal" ausschalten
gtmetrix laufen lassen => schneller (siehe oben)
"Direkt zu PayPal" einschalten
gtmetrix laufen lassen => langsamer

Das ist der Ausschnitt aus dem gtmetrix Waterfall, erklärt das was?


Bei uns werden knapp 60% aller Zahlungen per PayPal ausgeführt. Da wir nicht wissen welcher Anteil auf "Direkt zu PayPal" entfällt, möchten wir das auch nicht einfach ausschalten.

Kann man den Anteil von "Direkt zu PayPal" an allen PayPal Zahlungen feststellen?

 

Das müsste man in analytics sehen können anhand der Klickzahlen und Klickziele von einer Seite - da geht der FLuss ja entweder zum WK durch den checkout oder eben zu PP. Da könntest sicher auch nen Funnel für erstellen.

Das JS wird ja nicht am Start geladen sondern parallel mitten drinnen. Daher ist das für die Darstellung und TTFB eigentlich nicht relevant. Siehst ja auch das es nicht blockierend vorne ist, sondern parallel läd.

Kunden Browser laden das ja normal auch nur 1x und nicht bei jedem Aufruf nochmal, da ja im cache normal liegt dann.

Klar ist jedes Byte das geladen wird optimierbar wenn esicht gebracht wird, aber ob das jetzt beim 1. Seitenbesuch oder später geladen wird macht doch normal kaum einen Unterschied aus.

Und ich würde auch stark vermuten, dass Google und Co wissen, das das JS kein abstrafungsfaktor ist, da es ja eigentlich alle Onlineshops brauchen.

 

Ich wiederhole es noch einmal gerne:
Dass ist der gemessene Effekt zwischen Direkt zu PayPal an oder Direkt zu PayPal aus.
Das kann ich mit unterschiedlichen Ergebnissen in ähnlichen Größenordnungen, immer wieder reproduzieren.
Das kann man doch nicht wegdiskutieren ...

 

Time to first byte ist klar definiert: Du sendest eine Anfrage an einen Server und wartest wie lange es dauert bis du anfängst etwas zu bekommen. Die TTFB ist vor allem für das eigentliche HTML Dokument als zwangsweise erstem, blockierenden Schritt relevant eines Seitenabrufs relevant. Bevor das eine Dokument nicht da ist, geht genau gar nichts weiter.

Der Shop ist durchaus so gestrickt, dass er viele Dinge im Hintergrund für die Seite erzeugt, bevor erste Daten des Dokuments geschickt werden, daher gibt es auch viele Sachen, die auf diese Latenz eine Wirkung haben. Simples Beispiel: Wenn man eine Kategorie mit 300 Artikeln pro Seite anzeigen lassen will, werden beim Seitenaufruf die Eckdaten von 300 Artikeln nachgesehen. Das dauert deutlich länger, als wenn man das für 24 macht, die TTFB steigt also bei 300 Artikeln massiv und messbar an.

Wenns aber um PayPal geht, und ob man deren Javascript einbindet, sollte das ziemlich genau 0 an der TTFB ändern, in meinen Laborshops passiert da auch genau gar nichts. Ich hab gerade nochmal 1-2 Shopbetreiber gebeten eine Vergleichsmessung in ihren Liveshops zu machen und erwarte Feedback, aber ich glaub da werden wir nichts finden. Sollte sich das bestätigen, ist deine Messung krumm oder dein Shop ein Sonderfall.

 

@Wilken (Gambio)
Danke für die Erklärung und den zusätzlichen Test.

Mir geht es auch gar speziell um den Begriff "TTFB", den habe ich nur benutzt, da man den Unterschied in gtmetrix an der Stelle am ehesten sehen kann.

Es geht darum, dass man einen (m.E. signifikanten) Unterschied in der Ladezeit feststellt, je nachdem ob der an ist oder nicht.
Wenn man nur den Button "Direkt zu PayPal" im Artikel oder Warenkorb konfiguriert hat, braucht man den auch nur dort und sollte ihn auch dann erst laden. Wenn man Banner anzeigen will, dann meinetwegen auch noch woanders.
Wir nutzen "Direkt zu PayPal" nur im Warenkorb, da kommen viele ja ggf. gar nicht hin, aber trotzdem haben alle das Script geladen und ggf. länger warten müssen. Schon klar, dass das nur kleiner Teil ist, der Performance ausmacht, aber letztlich besteht diese aus vielen Teilen.

Wenn das nicht anders geht, dann ist das eben so. Aber wenn man da was optimieren kann (mit angemessenem Aufwand) sollte man das tun. Dasselbe gilt für das Thema CLS, dafür gibt es ja nun auch ein Ticket.

 

Aber der TTFB ist ein definierter Wert der die Zeit von der Anfrage bis zur Antwort definiert.
Quasi wenn ich jemanden etwas frage ist das die Zeit bis zum ersten Laut aus seinem Mund.
Die Denkzeit wird nicht länger weil mitten in der Antwort ein Nebensatz gesagt wird oder nicht. Also das JS wird ja nicht blockierend geladen sondern parallel und bleibt dann normal im Cache des Browsers.

Wenn dein Wert TTFB sich ändert wäre das merkwürdig.

Meinst du die gesamte Ladezeit bis ALLES geladen ist ist das ein anderer Wert
Oder die Zeit bis der Browser die Seite darstellt, im Hintergrund aber noch Daten läd

Dein TTFB hängt von Leistung des Servers, Cache, DNS ab wenn ich es richtig im Kopf habe.

Wenn eine Seite aus dem Cache kommt sollte es egal sein ob mittendrinnen noch JS parallel geladen wird.

Die Frage ist also um welchen Messwert geht es dir wirklich?

Und wie sehen die aus wenn z.B. im DEV vom Chrome oder Pingdom misst?

 

Das tut er... (wenn man gtmetrix glauben schenken mag), aktull der Unterscheid eher moderat, aber war auch schon deutlich weiter auseinander. Ich checke das auch mal mit den chrome dev tools und pingdom, dauert aber ein wenig, da ich das bisher nicht so intensiv benutzt habe.

==
Direkt to Paypal an


Direkt to Paypal aus


und wieder an


ein wenig gewarte und wieder aus

und wieder an

 

Ich habe das nun auch mal getestet und doch erheblich was an Zeit rausgeholt...

Von

First View
(12.031s)
Mit PayPal Buttons

auf

First View
(8.817s)
Ohne PayPal Buttons

(Startseite gestestet wo die Buttons oder PayPal eh keine Funktion haben / nicht zu sehen sind. Nur im Warenkorb)


Getestet mit (Link nur für registrierte Nutzer sichtbar.)


Ich werd den PayPal Button im Warenkorb jetzt erstmal deaktiviert lassen. Ich finde den Performance Gewinn doch beträchtlich und der Nutzen des PayPal Buttons.... na ja.

Hatte über die Zeit auch schon einige Anrufer/Kunden die dieser Button verwirrt hat. Waren zwar nur rund 5-10 Leute aber die Dunkelziffer kennt man ja auch nicht.

 

Ich greife hier mal folgendes Zitat auf "ESTUGO ist nicht so optimal, weil es in jedem Paket eine Begrenzung der PHP-Zugriffe pro IP auf zu knappe 30 gibt" (Seite 1 dieses Threads)

Das es bei ESTUGO eine Limitierung von 30 Verbindungen pro IP gibt ist natürlich nicht korrekt weder in der Zahl, noch in der Vermutung des Mechanismus das IP Zugriffe gezählt werden. Schönes Szenario um DoS und DDoS Angriffe im Keim zu ersticken, jedoch nicht wie wir arbeiten.

Der einzige Kontext in dem "30" auf unseren Shared Servern relevant ist, sind die simultanen Datenbankverbindungen pro DB-User. Externe IP Adressen oder Besucher im Shop haben hiermit exakt nichts zu tun und sind nicht limitiert.

 

Ok... ich weiß jetzt auch nicht mehr gerade wie ich darauf komme, aber ich dachte gelesen zu haben, dass DrGuu Estugo-Kunde ist. Offenbar dann nicht, sorry. Habe eine entsprechende Bemerkung in meinem Post auf der ersten Seite gemacht.

 

@Wilken (Gambio)

Gibt es schon eine Rückmeldung?