webcore vitals-sites need improvement, lcp, inp issues

[Hanzo2012]

Direkt ist immer schneller als jede noch so blitzschnelle CDN.

Nein, eben nicht! Immer diese unfundierten pauschalen Aussagen.
Liest du eigentlich, was andere dir schreiben?
Ich bin's jetzt ehrlich gesagt auch leid, mit dir zu "diskutieren", da kann ich ja genauso gut mit der Wand reden.

Wer hat denn das Geld um sich was auszubauen wie Amazon oder Otto?

CDNs musst du nicht selbst aufbauen, Anbieter gibt's wie Sand am Meer. Du zahlst normalerweise nur für den Traffic, den du wirklich brauchst, also z. B. super bei saisonal hohem Traffic, wo dein Server sonst in die Knie gehen würde und du dir nicht die Mühe machen willst, für diese Zeit einen zweiten Server zu mieten.

[arnego2]

Nein, eben nicht! Immer diese unfundierten pauschalen Aussagen.
Liest du eigentlich, was andere dir schreiben?
Ich bin's jetzt ehrlich gesagt auch leid, mit dir zu "diskutieren", da kann ich ja genauso gut mit der Wand reden..

Dann antworte nicht, es existiert kein Antwortzwang und es ist oft weiser wenn man eine Mütze Schlaf vor dem erwidern genießen konnte.

Der Myth über CDN wird auch nicht nur hier diskutiert:
Vor Jahren schon.


Plus weitere infos zum Thema

It's worth noting that while this was true for a long time, it's really not the case anymore. There are still real benefits from using CDNs (for example: files are served from a location in close physical proximity to the consuming end-user - on large, globally distributed CDNs), but the cross-domain resource caching is no longer a benefit.

UPDATE: Browsers No Longer Support Cross-site Caching
As of 2022-01-25

https://stackoverflow.com/questions/425 ... s-vs-local

Dazu kommt das dynamische IP auch gern, die verwechselt werden. Venezolanische IP Range 192 war vor Jahren Usus hier
Der Irrglaube beruft sich auf dass durch die IP dem Nutzer seine Scripte aus Bibliotheken geliefert werden. Nur geht der Request von der Homepage die sofort alles Lokal geliefert und das CDN die Scripte, in der korrekten Version, erst einmal raus suchen muss um sie dann auszuliefern

Wer Infos sucht, bekommt so gut wie immer nur Auskünfte, die sich auf weltweit operierende Mega-Seiten beziehen.

CDN behindern häufiger, als dass sie helfen. Sie fallen auch gern mal aus. Nicht zu vergessen die allseits beliebte Latency:
https://www.ioriver.io/terms/cdn-latency

[Hanzo2012]

https://stackoverflow.com/questions/425 ... s-vs-local

Was du zitierst ("not the case any more"), ist aus dem Kontext gerissen und bezieht sich auf einen zusätzlichen Vorteil, den CDNs früher hatten, aber jetzt nicht mehr, da Browser ihr Verhalten geändert haben. Diesen Vorteil habe ich gar nicht erwähnt, da ich weiß, dass er nicht mehr existiert. Der Hauptvorteil bleibt aber weiterhin bestehen, also wenn du schon zitierst, dann zitiere bitte auch alles:

It is still beneficial to use a CDN, and it is still for your users' benefit, but the benefit is in reduced latency with geo-located servers, not in general performance due to a hot cache hit.

Es ist immer noch vorteilhaft, ein CDN zu benutzen.

Nur geht der Request von der Homepage die sofort alles Lokal geliefert und das CDN die Scripte, in der korrekten Version, erst einmal raus suchen muss um sie dann auszuliefern

Eben nicht "sofort", jede Ressource benötigt einen eigenen HTTP-Request.
Und "lokal" heißt lokal auf dem Webserver, aber eben nicht unbedingt lokal beim User. Wenn der User weit weg vom Webserver ist oder der Webserver überlastet ist, dann ist das Laden vom Webserver langsamer als von einem CDN, das nah beim User einen Server stehen hat.
Der CDN-Server muss auch nicht mehr "raussuchen" als der Webserver. Der kriegt eine URL angefragt und antwortet, fertig - kein bedeutender Unterschied.
Meistens haben die CDNs auch noch Unterstützung für moderne (deutlich schnellere) Protokolle, die ein oller Webserver beim Hoster um die Ecke für 2,49 € pro Monat nicht kann.

Wer Infos sucht, bekommt so gut wie immer nur Auskünfte, die sich auf weltweit operierende Mega-Seiten beziehen.

Ich nutze ein CDN für gewisse Ressourcen (third-party libraries), eben weil mein Server ansonsten in gewissen Stoßzeiten überlastet wurde. Lokale Kopie gibt's immer noch als Fallback, ist aber selten nötig.

CDN behindern häufiger, als dass sie helfen.

Beleg? Quelle?
Du nutzt wahrscheinlich täglich Seiten, die CDNs benutzen, und merkst es gar nicht.

Sie fallen auch gern mal aus.

Seltenst, und wenn, dann kann man immer noch eine "lokale" Kopie liefern.
So mache ich das jedenfalls.

Nicht zu vergessen die allseits beliebte Latency:
https://www.ioriver.io/terms/cdn-latency

Verstehst du die Ironie? Du führst Latenz als Argument gegen CDNs an?
Ausgerechnet das, wo dein Webserver niemals mit einem CDN mithalten kann?!

Du tust so, als ob die Latenz deines eigenen Webservers egal wäre, wenn du die Ressourcen "lokal" einbindest. Ist sie aber nicht! Die Ressourcen kommen nämlich entgegen deiner Vorstellung nicht auf magische Weise während des Seitenaufrufs vom Webserver zum User, sondern der Browser muss sie sich alle einzeln holen. Steht dein Server in Amerika und der User ist in Australien, dann sind das gerne mal 200 ms, die bei einem Protokoll wie HTTP mehrfach zuschlagen, und das für jede einzelne Ressource. Ein CDN-Server direkt vor der Tür ist da viel schneller.

Ich kann dir wirklich nur empfehlen, mal F12 zu drücken, "Netzwerk" anzuklicken und anzuschauen, wie das Laden einer Seite eigentlich funktioniert. Dir scheinen in dieser Hinsicht die Grundlagen zu fehlen, und das meine ich jetzt nicht böse. Gerade wenn man sich als "SEO-Mensch" und Web-Entwickler positioniert, sollte man doch genau wissen, wie das Laden von Webseiten technisch funktioniert.

PS: Deine eigene Webseite nutzt ein CDN! Wusstest du es? Script: https://cdn.ywxi.net/js/1.js

PPS: Das Favicon auf deiner Seite funktioniert nicht, die URL ist falsch. (mit der Entwickler-Konsole (F12 drücken!) fällt sowas übrigens direkt ins Auge ...) Und dann gibt's noch einige Fehler wegen falschem MIME-Typ!

[staticweb]

> Steht dein Server in Amerika und der User ist in Australien, dann sind das gerne mal 200 ms, die bei einem Protokoll wie HTTP mehrfach zuschlagen, und das für jede einzelne Ressource. Ein CDN-Server direkt vor der Tür ist da viel schneller.

Sorry, aber die Zeiten sind seit HTTP2 vorbei, wo nur eine Verbindung aufgebaut wird. Das Problem existiert auch maximal beim initialen Document, wenn es dynamisch generiert wird. Ist Caching im Spiel reden wir von anderen Zeiten. Außerdem könnte man die wichtigen Sachen in das Document packen und das sekundäre nachladen.

Meiner Meinung ist ein CDN für eine normale deutsche Website, mit vorwiegend deutschen Besuchern nicht notwendig. Anders ist das bei hochfrequenten Seiten wo die eigene Technik nicht ausreicht oder unterschiedlichen Standorten, wie es der TE hat.

[Hanzo2012]

Ja, HTTP/2 hat die Art, wie Ressourcen geladen werden, definitiv verbessert.

​Allerdings bleiben die physikalischen Grenzen der Latenz (Round-Trip Time) bestehen. Ein weit entfernter Server führt auch mit HTTP/2 zu einem spürbar langsameren TTFB.

​Hinzu kommt: Die Parallelisierung hat ihre Grenzen. Oft laden Skripte dynamisch weitere Ressourcen nach, z. B. CSS-Dateien, Schriften oder andere Skripte. So entstehen Abhängigkeitsketten. Jeder Schritt in dieser Kette muss auf den vorigen warten und wird durch die volle Latenz zum Server verzögert. Ein CDN, das nah am User ist, verkürzt diese Wartezeit bei jedem einzelnen Glied der Kette und beschleunigt so den gesamten Ladevorgang spürbar.

Ressourcen direkt inline im HTML einbetten kann man natürlich machen, ist aber auch eine Abwägung, da es die zu ladende Datenmenge erhöht, das Parsing verzögert und Caching verhindert.

Insbesondere für internationale Seiten, wie du schon geschrieben hast, wie die des TE (Medizintourismus), ist es von Vorteil, dass die Seite von überall aus schnell lädt, von wo die Leute kommen.

[staticweb]

> Ressourcen direkt inline im HTML einbetten kann man natürlich machen, ist aber auch eine Abwägung, da es die zu ladende Datenmenge erhöht, das Parking verzögert und Caching verhindert.

Wer auf ein CDN oder GeoLocationHosting verzichten will oder muss, für den ist es eine Alternative. Natürlich muss man das Seiten Management dann etwas anpassen. Serverseitiges Caching wird deswegen aber nicht verhindert.

[Hanzo2012]

Meine Tastatur hat "Parsing" in "Parking" verwandelt ...

Es war natürlich gemeint, dass die Ressourcen nicht vom Client gecached werden können, wenn man sie direkt inline einbettet.

[staticweb]

> Meine Tastatur hat "Parsing" in "Parking" verwandelt ...

Hatte mich schon gefragt ob ich wieder Wissenslücken habe.

> Es war natürlich gemeint, dass die Ressourcen nicht vom Client gecached werden können, wenn man sie direkt inline einbettet.

Den Rest schon, der nicht für das initiale Laden der Seite benötigt wird.

[arnego2]

Beleg? Quelle?
Du nutzt wahrscheinlich täglich Seiten, die CDNs benutzen, und merkst es gar nicht.

Moinsen
Ich nutze so gut wie keine CDN, wenn es sich vermeiden lässt.
Failures der CDN:

https://www.forbes.com/councils/forbest ... f-failure/

Danke für die Fehlersuche

Was du zitierst ("not the case any more"), ist aus dem Kontext gerissen und bezieht sich auf einen zusätzlichen Vorteil, den CDNs früher hatten, aber jetzt nicht mehr, da Browser ihr Verhalten geändert haben. Diesen Vorteil habe ich gar nicht erwähnt, da ich weiß, dass er nicht mehr existiert. Der Hauptvorteil bleibt aber weiterhin bestehen, also wenn du schon zitierst, dann zitiere bitte auch alles:

Es gibt in dem Faden genug Infos, die das Für und Wider der CDN debattieren.
Was ich mir da raus gepickt habe ist dafür da dich dazu zu bewegen, sich den ganzen Faden durchzulesen.

Für Mega Seiten kann es ein Vorteil sein, für die große Masse ist es unnötig. IMHO.

Ich tue auch nicht so, als ob. Das ist reine Interpretation. Ich schreibe nicht nur für den Faden und seine Teilnehmer, sondern versuche, dass auch Leser etwas davon haben.