Webseiten Speed verbessern durch Server Upgrade

supervisior

magjagsch2160 hat geschrieben: ↑07.06.2020, 14:26 Cloudflair Workers probieren - damit schaffst Du 100 / 100.

Erklär' mal wie das gehn soll?!

magjagsch2160

workers.cloudflare.com - du musst die Webseite ohne CMS direkt coden - dann kan man diese über deren Cloudflair Workers ausliefern. Man muss halt programmieren können und deren Anforderungen erfüllen.

supervisior

Das kann man jetzt aber nicht wirklich als eine massentaugliche Lösung bezeichnen....

staticweb

> workers.cloudflare.com - du musst die Webseite ohne CMS direkt coden - dann kan man diese über deren Cloudflair Workers ausliefern. Man muss halt programmieren können und deren Anforderungen erfüllen.

Musst du nicht. Ist nur eine statische (serverless) Hosting Umgebung, mit der optionalen Möglichkeit eigene JS-Projekte über wrangler zu bauen.

"We can deploy static websites built or generated with Nuxt, Hugo, Gatsby or Jekyll directly to their network."

/Affilitiv/

magjagsch2160 hat geschrieben: ↑07.06.2020, 14:26 Cloudflair Workers probieren - damit schaffst Du 100 / 100.

Wen du Cloudflair auf einen Trabi klebst, wird die Rennpappe zum F1-Flitzer?

Rem · **Rem** » 10.06.2020, 01:00 **Webseiten Speed verbessern durch Server Upgrade**

Na ja. Ein paar generelle Optimierungsvorschläge haben ja auch weitere Tools parat, wie das hier:
https://gtmetrix.com/
Selbst habe ich z.B. einige statische Files zu Cloudfront ausgelagert, kleine Graphiken in grössere Zusammengefasst (CSS Sprites) und habe die Zahl an Rendering-Blocking-Events verringert. Mit lazy-load experimentiere ich auch rum... GZIP vs Brotli gestestet und mich für GZIP entschieden.

Ich mein, falls es von solchen Elementen abhängt, dann bringt das Server Upgrade leidig wenig.

Z.B. bringt Opcache beim Afrikaner, der 5 Sekunden auf eine 200 KByte grosse Graphik wartet, überhaupt keinen nennenswerten Gewinn. Aber für den Hostingprovider ist es natürlich easier, so eine Option vorzuschlagen...

Wobei natürlich ein überfrachtetes CMS schon rumhängen kann. LOL

Nur so nebenbei könnte man ja die Website auch auf einem nicht-öffentlich zugänglichen Origin hosten und das ganze über eine "CDN"-Lösung ausliefern, wie das oben bereits angetönt wird. Das Problem ist einfach, dass die CDNs in Abhängigkeit der Nutzung gewisse Inhalte aus dem Speicher werfen und dann eher wie ein Proxy funktionieren. Für kleine Seiten oder Files mit wenig Zugriffen taugt das insofern nichts.

Aber mit kostenlosen Testmonaten kann man problemlos herumexperimentieren.

nerd

magjagsch2160 hat geschrieben: ↑07.06.2020, 14:38 workers.cloudflare.com - du musst die Webseite ohne CMS direkt coden - dann kan man diese über deren Cloudflair Workers ausliefern. Man muss halt programmieren können und deren Anforderungen erfüllen.

Was fuer ein unsinn. Bei einem gescheiten CMS kann man die eingebunden files auch von anderen quellen aus nachladen. Oder besser noch: auf uebermaessiges einbinden von scripts, bildern, videos, social media tracker usw. verzichten die die user sowieso nur nerven.
Aber nein, bei "modernen webseiten" muss der browser muss ja beim ersten pageload erstmal komplett mit werbung, selbststartenden videos, "subscribe" popups, cookie consent meldungen und browser meldungen, ob man standort und nachrichten zulassen will vollgekotzt werden...

Und dann wundern sich die betrieber warum die eigene seite langsam ist, wenn mindestens 100 files mit 5MB ueber eine 1MBit DSL leitung ins neuland geschickt werden soll. Keine sorge, cloudflare und gzip wirds schon irgendwie richten - sagt zumindest die produktbeschreibung...

supervisior

Rem hat geschrieben: ↑10.06.2020, 01:00 Na ja. Ein paar generelle Optimierungsvorschläge haben ja auch weitere Tools parat, wie das hier:
https://gtmetrix.com/
Selbst habe ich z.B. einige statische Files zu Cloudfront ausgelagert, kleine Graphiken in grössere Zusammengefasst (CSS Sprites) und habe die Zahl an Rendering-Blocking-Events verringert. Mit lazy-load experimentiere ich auch rum... GZIP vs Brotli gestestet und mich für GZIP entschieden.

Nur für den Fall, dass sich das noch nicht zur Gänze herumgesprochen haben sollte, aber was allem voran von Google durch Pagespeed propagandiert wird, hat mit Geschwindigkeit, insbesondere mit Ladezeitgeschwindigkeit herzlich wenig zu tun. Von daher besteht der weitverbreitete Irrtum, dass man seine Webseite schneller gemacht hätte, wenn man seine Seite nach Maßgabe von Pagespeed optimiert hätte. Einmal davon abgesehen, dass Pagespeed nicht wenige Funktionen wie z.B. BROTLI oder Server PUSH nicht unterstützt, geht es bei Pagespeed maßgeblich um die Anzeigegeschwindigkeit NACHDEM alle Daten geladen wurden. Das macht Pagespeed aber nicht zur Gänze wertlos, wenngleich die bekannten Optimierungsmaßnahmen vornehmlich dazu dienen das Ladeverhalten (nicht die Zeit) zu beeinflussen, um so die Anzeige im Browser zu begünstigen, also weniger wichtiges hinten anstellen.

Das mit dem Lazy Load hat allerdings einen widersprüchlichen Haken. Verzögertes Laden, was uns eingeimpft wurde es wäre gut für die Ladezeit, wird einmal mehr von Pagespeed als negativer Faktor betrachtet, aber nicht generell. Warum? Weil es neuerdings das sog. Content Layout Shifting gibt und Lazy Load genau das begünstigt, was sich besonders bei mobilen Geräten niederschlägt. Bei Desktop Geräten hingegen möchte man das verzögerte Laden bitte haben. Klingt paradox und ist es auch, kann aber jeder bei Pagespeed Insight austesten.

Rem hat geschrieben: ↑10.06.2020, 01:00 Ich mein, falls es von solchen Elementen abhängt, dann bringt das Server Upgrade leidig wenig.

Was statische Sourcen anbetrifft in jedem Fall richtig. Kein noch so schneller XXL Server liefert solche Art Daten schneller aus als ein 5,- Euronen Shared Hosting Angebot. Ein CDN oder mod_Pagespeed macht im Fall eines CDN auch nur dann Sinn, wenn man ein globales Publikum hat. Fehlt es daran, sind die Ausgaben dafür keinen Pfifferling wert. mod_Pagespeed macht die Sache auch nicht besser. Erstens seit Jahren buggy und ist bei zu klein geratenen Hostings kontraproduktiv, weil es dann mehr Ressourcen verbraucht als man glaubt damit gewinnen zu können. Von daher erreicht man weit mehr, wenn man sich an die bekannten Optimierungsmaßnahmen hält, aber bitte nicht durch irgendwelche Plugins.

Rem hat geschrieben: ↑10.06.2020, 01:00 Z.B. bringt Opcache beim Afrikaner, der 5 Sekunden auf eine 200 KByte grosse Graphik wartet, überhaupt keinen nennenswerten Gewinn. Aber für den Hostingprovider ist es natürlich easier, so eine Option vorzuschlagen...

Naja, dazu fehlt auch der Bezug. OPcache ist ja nicht dafür gedacht das Laden von statischen Sourcen zu verbessern.

Rem hat geschrieben: ↑10.06.2020, 01:00 Wobei natürlich ein überfrachtetes CMS schon rumhängen kann. LOL

Ich für meinen Teil mache darin das größte Übel aus. Ich weiß nicht, was Programmierer gelehrt bekommen, aber es scheint in der Natur eines Programmierers zu liegen blooooß nicht zu viel zu schreiben und wann immer möglich Redundanzen zu vermeiden sind. Leider wird das in der Art missverstanden, dass man im Gegenzug auf Frameworks setzen soll. Kein Framework hat bislang dazu gedient, dass irgendwas weniger, geschweige denn dadurch schneller und besser im Sinne von besseren Funktionen wurde. Es mag sich stark herabwürdigend anhören, aber Frameworks begünstigen wenn, dann die naurgemäße Faulheit von Programmierern, die zudem ein sehr stark eingeschränktes Blickfeld haben. Letztendlich wirkt sich das in der Praxis so aus, dass die allermeisten CMS eigentlch immer nur weiter aufgeblasen wurden, aber sich funktionell nur wenig dadurch ändert. Am Beispiel von Shop Systemen wird das überdeutlich. Aktuelle Shop Systeme haben sich im Vergleich zu denen von 20 Jahren fast nur in ihrem Aussehen, aber in Sachen Funktionen nur unwesentlich verändert und rechtfertigt in keinem Fall das tonnenweise Aufblähen von Code.

Fatal ist diese Entwicklung insofern, weil sich dadurch die Systemanforderungen ver-x-facht haben, was den Providern nur recht sein kann. Und diese Provider ein weiteres Glied in der Verkettung von Übeltätern sind. Was der Laie zumeist nicht weiß, ist dass sich ein 5,- Hosting von einem XXL Server in Sachen der für die Funktion eines Internet Servers installierten Software gar nicht unterscheiden. Man bekommt v.a. bei dedizierten Servern das Gleiche an Software installiert wie bei einem 5,- Low Budget Hosting. Zu 99,99% irgendein Linux Derivat, Apache Webserver, MySQL, PHP und exim. Das wars dann auch schon. Alles OpenSource und somit kostenlos, was zunächst mal nicht schlecht ist, weil erst dadurch so auffallend billige Hostings angeboten werden können und keine Lizenzkosten anfallen.

Ein weiteres mal aber fatal, weil man damit Software bekommt deren Ursprung in den 90ern des letzten Jahrundert liegt. Zwar immer wieder verbessert, aber nicht die Architektur. Obwohl sich die Systemanforderungen an einen Server durch die oben beschriebenen Umstände von aufgeblähter Software ver-x-facht haben, soll nun also eine Software Architektur aus dem letzten Jahrtausend die aktuellen und deutlich gesteigerten Anforderungen stämmen können? Das geht schlichtweg nicht. Allen Übeln voran steht hierbei der Apache Webserver im Fokus. Da kann PHP und MySQL noch so schnell sein, aber wenn der Webserver auf Grund seiner veralteten Architektur nicht in der Lage ist Requests genauso schnell zu beantworten, sind die Ausgaben in einen vermeintlich hochwertigen Server aus dem Fenster geworfenes Geld. Einmal mehr kann das Providern nur recht sein, weil diese damit das kostenlose Argument dafür bekommen, dass Kunden gewissermaßen dazu genötigt werden ein ebenso vermeintlich besseres und dann auch teueres Hosting nutzen zu müssen.

staticweb

> Weil es neuerdings das sog. Content Layout Shifting gibt und Lazy Load genau das begünstigt, was sich besonders bei mobilen Geräten niederschlägt.

Da hast du sicher eine Beispiel-Seite um das zu überprüfen.

LCP und CLS wurde im übrigen erst neu eingeführt und Google ist sehr dynamisch. Es geht übrigens um Layout Shifts over the fold und nicht um scroll events.

> Ein CDN oder mod_Pagespeed macht im Fall eines CDN auch nur dann Sinn, wenn man ein globales Publikum hat.

CDN hat mehr Nach- als Vorteile. Da sind viele Opfer der Werbeversprechen der Anbieter.

> Leider wird das in der Art missverstanden, dass man im Gegenzug auf Frameworks setzen soll.

Man kann das Rad auch jedesmal neu erfinden. Fragt sich nur wer das bezahlt?

> Am Beispiel von Shop Systemen wird das überdeutlich. Aktuelle Shop Systeme haben sich im Vergleich zu denen von 20 Jahren fast nur in ihrem Aussehen, aber in Sachen Funktionen nur unwesentlich verändert und rechtfertigt in keinem Fall das tonnenweise Aufblähen von Code.

Es gibt immer schlechte und gute Beispiele. Unterscheiden solltest du dort aber welche Funktionalitäten wirklich für das Ausliefern von Seiten benötigt werden. Der meiste Code wird für das Management im Backend benötigt.

> Allen Übeln voran steht hierbei der Apache Webserver im Fokus.

Der Webserver Markt reguliert sich von selbst. Apache und nginx werden bald die selben Marktanteile haben.

Letztendlich geht es darum die assets zu reduzieren / optimieren. Ob da ein schnellerer Webserver hilft sollte von Fall zu Fall überprüft werden.

supervisior

staticweb hat geschrieben: ↑10.06.2020, 09:07 > Weil es neuerdings das sog. Content Layout Shifting gibt und Lazy Load genau das begünstigt, was sich besonders bei mobilen Geräten niederschlägt.

Da hast du sicher eine Beispiel-Seite um das zu überprüfen.

Ja, Deine eigene, sofern Du eine betreibst...

staticweb hat geschrieben: ↑10.06.2020, 09:07 LCP und CLS wurde im übrigen erst neu eingeführt und Google ist sehr dynamisch. Es geht übrigens um Layout Shifts over the fold und nicht um scroll events.

Ich hatte Dir schon mal gesagt, dass es für den konkreten Fall unerheblich ist, ob Google was Neues einführt. Und es geht auch nicht um den LCP, zudem dieser Wert so gut wie gar nicht bei Pagespeed ins Gewicht fällt. Es bleibt also beim CLS, das nichts mit der Geschwindigkeit zu tun hat, aber Google es für die Pagespeed Bewertung verwendet. Dieses CLS wirkt sich auf die ganze Seite aus, wenngleich es sich "over the fold" funktionell am meisten auswirkt. Der Rest der Seite bleibt dabei aber nicht verschont. Du musst probehalber nur mal die Größenangaben von Bildern, iframes, usw. im HTML Code entfernen, bzw. hinzufügen und schon bekommst Du eine andere Bewertung.

staticweb hat geschrieben: ↑10.06.2020, 09:07 > Leider wird das in der Art missverstanden, dass man im Gegenzug auf Frameworks setzen soll.

Man kann das Rad auch jedesmal neu erfinden. Fragt sich nur wer das bezahlt?

Natürlich muss das Rad nicht neu erfunden werden, was aber nicht den Rückschluss erlaubt, dass es dafür Alternativen braucht. Das Übel liegt in der Natur eines Frameworks selbst, weil man zumeist nur einen Bruchteil an Code benötigt, aber die Ressourcen für das ganze Framework beansprucht werden. Beispiele dafür gibts genügend oder warum musste man .less erfinden, um der besagten Problematik erst beizukommen?!

staticweb hat geschrieben: ↑10.06.2020, 09:07
> Am Beispiel von Shop Systemen wird das überdeutlich. Aktuelle Shop Systeme haben sich im Vergleich zu denen von 20 Jahren fast nur in ihrem Aussehen, aber in Sachen Funktionen nur unwesentlich verändert und rechtfertigt in keinem Fall das tonnenweise Aufblähen von Code.

Es gibt immer schlechte und gute Beispiele. Unterscheiden solltest du dort aber welche Funktionalitäten wirklich für das Ausliefern von Seiten benötigt werden. Der meiste Code wird für das Management im Backend benötigt.

Da stimmt so nicht und kann man so deswegen auch nicht stehen lassen. Die Bibliotheken, die ich Frontend brauche, brauche ich zumeist auch im Backend. Zustände, die Deiner Aussage entsprechen findet man wenn, dann nur noch in den 90ern bei diversen OpenSource Projekten.

staticweb hat geschrieben: ↑10.06.2020, 09:07 > Allen Übeln voran steht hierbei der Apache Webserver im Fokus.
Der Webserver Markt reguliert sich von selbst. Apache und nginx werden bald die selben Marktanteile haben.

Letztendlich geht es darum die assets zu reduzieren / optimieren. Ob da ein schnellerer Webserver hilft sollte von Fall zu Fall überprüft werden.

Wie soll sich ein Market regulieren, wenn diejenigen, die am meisten Einfluss darauf hätten, am meisten davon profitieren?

Apache war die Innovation im letzten Jahrtausend. nginx hat zwar eine Ereignis orientierte Architektur, was ihn performanter macht als den Apache, aber um aus nginx das Entscheidende herauszuholen, brauchst Du die proprietäre Version, die nur mit einem dedizierten Server läuft. Dadurch entsteht das x-fache an Kosten für das Hosting und erfordert zudem ein deutlich höheres KnowHow. Letztendlich keine Alternative, zumal nicht massentauglich. Vor dem Hintergrund, dass das "Übel" unmittelbar von diesem Widrigkeiten profitiert, stellt sich Frage von Marktanteilen, geschweige denn, dass sich irgendwas verändern könnte, überhaupt nicht.

Würde man die Funktion eines Webserver auf das reduzieren, wofür er primär gedacht ist, würde ein Webserver allein keine Lösung darstellen. Auch aufgesetzte PHP Lösungen sind keine Lösung, wenn der Webserver immer noch der Bottleneck ist. Es gibt inzwischen aber Webserver Lösungen, die mehr können als nur webservern und mit einer eigenen lsapi anstelle von mod_lsapi schon damit um 50% performanter sind. Wenn dann noch ein HTTP Cache integriert ist. dann bekommt "Lichtgeschwindigkeit" eine ganz neue Bedeutung. Das entscheidende daran ist aber, dass es unterm Strich weniger kostet als das bestmöglichst optimierte Apache Hosting und selbst die Free Version einen nginx dedizierten XXL Server in die Tasche steckt und das for free.

supervisior

Zur allgemeinen Weiterbildung und zum Verständnis, was der Knackpunkt an dem veralteten Apache Webserver ist ein Beispiel an Hand eines Coffee Shops.

**************************************************************

The Coffee Shop Analogy

Imagine for a moment that your web server is a busy coffee shop, and the customers in the shop are the requests that the web server must handle. Which type of coffee shop handles its customers more efficiently?

The Process-Based Coffee Shop (Apache)

In the process-based coffee shop, each employee serves one customer. The employee takes the order, pours the coffee, and collects the payment.

If there are three customers in the shop, there must be three employees to serve those customers, or else a line will form. This is a manageable scenario in a shop that serves few customers, or has a simple menu such as coffee and donuts.

But what happens when there are ten customers in the shop? And each of them wants a decaf soy peppermint mocha latte with no whip, and a heated croissant? The first three customers to place their orders probably get served pretty quickly, but the other seven? They will have a long wait. Many customers will not have that kind of patience, and will go elsewhere for their coffee.

In order to solve the efficiency problem in the process-based coffee shop, you need more employees. And in order to fit all of those extra employees behind the counter, you’ll need to expand your shop. You may need to move to a bigger location.

Such is the case with the process-based Apache web server. In order to deal with a large number of requests, you need more processes, and that means you’ll need to buy more hardware.

The Event-Driven Coffee Shop

Now imagine the same customer load and the same complicated orders, but in the event-driven coffee shop.

In the event-driven coffee shop, each employee serves multiple customers. One employee takes the orders and the payment, and delegates the order-filling tasks to other employees.

The employee at the register gets to all ten customers in a timely manner, because all he or she needs to do is take the order, relay instructions to the baristas on the backend, and take the payment. Meanwhile the backend baristas are pouring coffees, making lattes, and warming up croissants as needed.

This is an ideal solution that scales well, as one employee can do the work of many. You save money on retail space and wages, all while keeping your customers plied with fancy coffees and warm pastries in an efficient manner.

In the same way, LiteSpeed Web Server saves you money. With fewer processes doing the work of many, your server can handle a large number of requests quickly. And without the need for more hardware.

Conclusion

For static content like images, CSS, and HTML, the advantage of an event-driven model is clear. Instead of consuming the overhead required for a new process for each request, LiteSpeed employs its one process to handle the requests as they come in. This is faster and consumes significantly less CPU and memory than Apache.

arnego2

Ohne Angabe der Quelle hat der Schrieb weniger Glaubwürdigkeit.
Im Internet wird viel veröffentlicht.

staticweb

Ist vermutlich von hier kopiert wurden:

https://blog.litespeedtech.com/2018/04/ ... ess-based/

Ein Link hätte es auch gemacht.

supervisior

staticweb hat geschrieben: ↑10.06.2020, 17:28 Ist vermutlich von hier kopiert wurden:

https://blog.litespeedtech.com/2018/04/ ... ess-based/

Ein Link hätte es auch gemacht.

Wollte nur dem Forum etwas an Wert geben. Ihr nörgelt aber auch an allem herum....

supervisior

arnego2 hat geschrieben: ↑10.06.2020, 16:29 Ohne Angabe der Quelle hat der Schrieb weniger Glaubwürdigkeit.
Im Internet wird viel veröffentlicht.

Hauptsache der Webdesigner hats verstanden....