Man wäre doch nicht Amazon oder Ebay oder ähnlich großer Anbieter - solche Äußerungen kommen sehr häufig dann wenn die mangelnde Leistung einer Site angesprochen wird.
Der Mangel liegt darin das die Site es nicht schafft ihre Inhalte im Rahmen von 1..1,5 Sekunden zu präsentieren und auch nicht in der Lage ist 10..20 oder mehr Besucher gleichzeitig bedienen zu können.
Mit den Äußerungen will man zu verstehen geben das man eine Hochleistung nicht benötigt.
Selbstverständlich gibt es Webangebote die sich nur an kleine Kreise richten.
Aber schaut man sich diese an sind sie überladen mit Features, haben Ladezeiten von weit über 2 Sekunden und sind nicht in der Lage auch nur 3 (in Worten DREI) Besucher gleichzeitig innerhalb benötigter Zeitfenster bedienen zu können.
Hätte man nun ein schnelleres System oder gar ein High Speed System wäre das eine wie auch das andere kein Problem.
Man steckt einfach die überschüssige Leistung in mehr Features und verbessert die Site damit.
Das geht solange die Komplettzeit unter Last nicht über 1,5 Sekunden ansteigt.
Dann hat man eine schicke Seite die etwas bietet und hat sogar noch eine Wachstumsmöglichkeit.
Samstag, 11. Januar 2014
Mittwoch, 8. Januar 2014
Was gibt es an Power nicht zu verstehen ?
Die Frage stelle ich mir des öfteren weil andere ziemlich abstruse Vorstellungen davon haben warum ausreichend Power bei einer Internetanwendung notwendig ist und wie man sie erzeugt.
Rund 15,6 Mio. DE Domains plus jede Menge anderer Top-Level und Subdomains plus unzählige aus dem Ausland verfügbare Domains bieten alle Inhalte und das mit steigender Tendenz.
Aber die Anzahl der Surfer ist praktisch fix - schwankt nur in kleinen Bereichen.
Die Surfer haben die Qual der Wahl und lassen in der Praxis alles links liegen was ihnen die Inhalte zu langsam erscheinen lässt, ja sie brechen sogar eine Einkaufstour aus dem Grunde ab.
Eine bis 1,5 Sekunden Zeit hat ein Anbieter maximal um sich in's rechte Licht zu stellen - 1 Sekunde ist optimal - je länger es dauert desto mehr laufen weg - ab 1,5 Sekunden sogar in Mengen.
Und - natürlich - es gibt Anbieter mit Marktmacht die benötigen Performance um überhaupt den Massen an Besuchern abarbeiten zu können die auf deren Seiten zugreifen.
Die Masse an Besucher ist entscheidend - eine Applikation kann bei 1 Besucher schnell sein, bei 5 Besuchern kann sie sich sogar schon verabschieden, bei 50,100 oder gar mehr Besuchern kann sie sogar den Server sofort still legen.
Schnell ist eine Seite immer wenn sie nach dem 2. Aufruf statisch vom Browser gecacht von dem geliefert wird. Mancher Webdesigner und Webprogrammierer hat absolut keine Ahnung von den Hintergründen.
Unmöglich ? Nein - traurige Praxis.
Es ist unglaublich welche Mengen an Angeboten im Netz bereits bei kleiner Anzahl von Besuchern nicht nur sämtliche Zeitmarken sprengen ja sogar zum Stillstand gelangen.
Ein Wachstum bei der Zahl der Besucher ist bei solchen Angeboten völlig unmöglich.
Das ist die eine Seite des Internets.
Auf der anderen gibt es massive auf Internet basierende Anwendungen die ebenfalls mit technisch begrenzten Ressourcen arbeiten müssen.
Da geht es nicht um zig tausende Besucher aber immerhin um eine hohe Zahl Besucher die zudem massiv Traffic und permanent in DB Systemen auslösen.
Es gibt da Anwendungen die praktisch nur existieren und arbeiten können weil sie eben als High-Speed-System programmiert wurden.
Nun - so mancher hat die Idee man schreibe einen Power - Bootstrap der auf ein bestehendes System aufsetzt und alles in einem gewünschtem Umfang so beschleunigt das man zufrieden ist.
Das hört sich gut und simpel an - es ist aber einfach Blödsinn.
Hat man ein System das unter Performancemangel leidet dann muss man genau definieren was denn der Mangel ist und wann er erledigt ist.
Schaut man sich in einem Überblick alle verwendeten Libs und Scripte einmal an und stellt fest - die haben Jahre auf dem Buckel - dann kann man davon ausgehen - die sind überholt.
Bei einem solchen Status lohnt es sich kaum Details zu überarbeiten von denen man weiß - die machen Probleme.
Da wäre eine komplette Neukonzeption und Programmierung angesagt - ein solcher Titel ist verloren und jegliche Arbeit ohne Neukonzeption daran ebenfalls.
Dieser Ansatz trifft auch Titel in einiger Zeit die aktuell High-Speed ohne wenn und aber sind.
Performancemangel erkennen - das ist leider eine Sache die so mancher Programmierer erst dann sieht wenn man ihn mit der Nase darauf stößt.
Extrem viele Programmierer verstehen diesbezüglich nicht wo es in einer konkreten Situation darauf ankommt.
Beispiel:
$config['callback']='ob_gzhandler';
ob_start($config['callback']);
oder
$callback = 'ob_gzhandler';
ob_start($callback);
sollten eigentlich nichts ausmachen.
Aber Version 2 bringt im Benchmark bei der Gesamtapplikation über 8% mehr Leistung - völlig unerwartet aber gewaltig hoch und reproduzierbar.
Das kann unter anderen Versionen von Apache und PHP anders aussehen und es kann auch in anderen Situationen anders aussehen.
Deswegen ist Power auch immer eine Sache der Versionen und des konkreten Einsatzes.
Und man muss Methoden entwickeln und einsetzen um die Performance nicht nur über alles sondern auch in Details messen zu können.
Und natürlich - man muss auch Kompromisse eingehen.
So kann man eine Funktion besonders schnell sein - die Aufbereitung und Rückgabe des Ergebnisses kann sich aber z.B. im Format als ungünstig heraus stellen und alles ein wenig langsamer machen.
Und Performanceprogrammierung ist teuer. Je ahnungsloser Mitwirkende sind desto teurer wird es.
Je ahnungsloser Mitwirkende im Bereich der Anwender wie kleine Webdesigner bei CMS sind, desto komplizierter wird es, weil die natürlich keine Lust haben bestehende Einsätze umzubauen.
Große Anbieter haben ganze Performanceteams mit hochqualifizierte Mitgliedern die sich um diese Dinge kümmern. Das ist teuer aber kein Luxus sondern die Basis des Geschäftes.
Schaut man sich aber z.B. bei CMS Anbietern um wird da zwar vielleicht mal über Performance geredet aber getan wird da gesamtkonzeptionell nichts - bestenfalls wird an einzelnen Stellen mal etwas geschraubt und das mit geringem Erfolg.
Und - die nehmen Performancemangel persönlich - sehen es als Abstempelung minderer Programmierleistung an und reagieren bockig.
Statt so etwas als Feststellung zu nehmen und daran zu arbeiten wird geblockt und das unterstützt von Anwendern die absolut keine Ahnung haben aber der Meinung sind sie müssten irgend etwas verteidigen. Die Folge wird immer langsamer aber sehr sicherer Untergang sein.
Halten wir fest:
Rund 15,6 Mio. DE Domains plus jede Menge anderer Top-Level und Subdomains plus unzählige aus dem Ausland verfügbare Domains bieten alle Inhalte und das mit steigender Tendenz.
Aber die Anzahl der Surfer ist praktisch fix - schwankt nur in kleinen Bereichen.
Die Surfer haben die Qual der Wahl und lassen in der Praxis alles links liegen was ihnen die Inhalte zu langsam erscheinen lässt, ja sie brechen sogar eine Einkaufstour aus dem Grunde ab.
Eine bis 1,5 Sekunden Zeit hat ein Anbieter maximal um sich in's rechte Licht zu stellen - 1 Sekunde ist optimal - je länger es dauert desto mehr laufen weg - ab 1,5 Sekunden sogar in Mengen.
Und - natürlich - es gibt Anbieter mit Marktmacht die benötigen Performance um überhaupt den Massen an Besuchern abarbeiten zu können die auf deren Seiten zugreifen.
Die Masse an Besucher ist entscheidend - eine Applikation kann bei 1 Besucher schnell sein, bei 5 Besuchern kann sie sich sogar schon verabschieden, bei 50,100 oder gar mehr Besuchern kann sie sogar den Server sofort still legen.
Schnell ist eine Seite immer wenn sie nach dem 2. Aufruf statisch vom Browser gecacht von dem geliefert wird. Mancher Webdesigner und Webprogrammierer hat absolut keine Ahnung von den Hintergründen.
Unmöglich ? Nein - traurige Praxis.
Es ist unglaublich welche Mengen an Angeboten im Netz bereits bei kleiner Anzahl von Besuchern nicht nur sämtliche Zeitmarken sprengen ja sogar zum Stillstand gelangen.
Ein Wachstum bei der Zahl der Besucher ist bei solchen Angeboten völlig unmöglich.
Das ist die eine Seite des Internets.
Auf der anderen gibt es massive auf Internet basierende Anwendungen die ebenfalls mit technisch begrenzten Ressourcen arbeiten müssen.
Da geht es nicht um zig tausende Besucher aber immerhin um eine hohe Zahl Besucher die zudem massiv Traffic und permanent in DB Systemen auslösen.
Es gibt da Anwendungen die praktisch nur existieren und arbeiten können weil sie eben als High-Speed-System programmiert wurden.
Nun - so mancher hat die Idee man schreibe einen Power - Bootstrap der auf ein bestehendes System aufsetzt und alles in einem gewünschtem Umfang so beschleunigt das man zufrieden ist.
Das hört sich gut und simpel an - es ist aber einfach Blödsinn.
Hat man ein System das unter Performancemangel leidet dann muss man genau definieren was denn der Mangel ist und wann er erledigt ist.
Schaut man sich in einem Überblick alle verwendeten Libs und Scripte einmal an und stellt fest - die haben Jahre auf dem Buckel - dann kann man davon ausgehen - die sind überholt.
Bei einem solchen Status lohnt es sich kaum Details zu überarbeiten von denen man weiß - die machen Probleme.
Da wäre eine komplette Neukonzeption und Programmierung angesagt - ein solcher Titel ist verloren und jegliche Arbeit ohne Neukonzeption daran ebenfalls.
Dieser Ansatz trifft auch Titel in einiger Zeit die aktuell High-Speed ohne wenn und aber sind.
Performancemangel erkennen - das ist leider eine Sache die so mancher Programmierer erst dann sieht wenn man ihn mit der Nase darauf stößt.
Extrem viele Programmierer verstehen diesbezüglich nicht wo es in einer konkreten Situation darauf ankommt.
Beispiel:
$config['callback']='ob_gzhandler';
ob_start($config['callback']);
oder
$callback = 'ob_gzhandler';
ob_start($callback);
sollten eigentlich nichts ausmachen.
Aber Version 2 bringt im Benchmark bei der Gesamtapplikation über 8% mehr Leistung - völlig unerwartet aber gewaltig hoch und reproduzierbar.
Das kann unter anderen Versionen von Apache und PHP anders aussehen und es kann auch in anderen Situationen anders aussehen.
Deswegen ist Power auch immer eine Sache der Versionen und des konkreten Einsatzes.
Und man muss Methoden entwickeln und einsetzen um die Performance nicht nur über alles sondern auch in Details messen zu können.
Und natürlich - man muss auch Kompromisse eingehen.
So kann man eine Funktion besonders schnell sein - die Aufbereitung und Rückgabe des Ergebnisses kann sich aber z.B. im Format als ungünstig heraus stellen und alles ein wenig langsamer machen.
Und Performanceprogrammierung ist teuer. Je ahnungsloser Mitwirkende sind desto teurer wird es.
Je ahnungsloser Mitwirkende im Bereich der Anwender wie kleine Webdesigner bei CMS sind, desto komplizierter wird es, weil die natürlich keine Lust haben bestehende Einsätze umzubauen.
Große Anbieter haben ganze Performanceteams mit hochqualifizierte Mitgliedern die sich um diese Dinge kümmern. Das ist teuer aber kein Luxus sondern die Basis des Geschäftes.
Schaut man sich aber z.B. bei CMS Anbietern um wird da zwar vielleicht mal über Performance geredet aber getan wird da gesamtkonzeptionell nichts - bestenfalls wird an einzelnen Stellen mal etwas geschraubt und das mit geringem Erfolg.
Und - die nehmen Performancemangel persönlich - sehen es als Abstempelung minderer Programmierleistung an und reagieren bockig.
Statt so etwas als Feststellung zu nehmen und daran zu arbeiten wird geblockt und das unterstützt von Anwendern die absolut keine Ahnung haben aber der Meinung sind sie müssten irgend etwas verteidigen. Die Folge wird immer langsamer aber sehr sicherer Untergang sein.
Halten wir fest:
- Die 1..1,5 Sekunden gelten immer egal wer der Anbieter ist.
- Bei speziellen Internetanwendungen sind selbst 1 Sekunde deutlich zu lang
- Alte Scripte und verwendete Libs erfordern eine Generalüberholung eines Systems
- Performance ist kein Luxus sondern Geschäftsbasis
- Es gibt keine eierlegende Wollmichsau sprich Power Bootstrap - es gibt nur harte Arbeit bis in's kleinste Detail.
Montag, 6. Januar 2014
Getimagesize - eine Killerfunktion
Die PHP Funktion Getimagesize kann eine Killerfunktion sein.
Der Grund ist einfach - die Funktion liest ein zu prüfendes Image komplett ein um dann daraus die Informationen zu gewinnen.
Bei kleinen Images keine große Sache:
Sind es jedoch größere oder gar ziemlich große Images wird entsprechend viel RAM belegt.
Kommen dann auch noch die Besucher in Mengen dann wird u.U. eine kritische Masse erreicht und der Server kann abstürzen.
Bei großen Images und vielen Besuchern wird zudem wegen des verbrauchten RAM's die Sache sehr gemütlich.
Besser ist es mit eigenen Funktionen Size zu ermitteln.
Bei PNG und GIF Formaten keine große Sache - da müssen nur wenige Bytes vom Imagefileanfang gelesen werden - bei JPG jedoch die Information nicht im Headerbereich zu finden sondern nach der Kennung 0xFFC0 irgendwo im File selbst.
Eine Eigenbeschränkung auf PNG als Universalformat wäre dann sinnvoll.
Bei JPG wäre die Alternative die die Daten dem Filenamen anzuhängen um sie mit einer kleinen PHP Funktion auszulesen.
Ja sogar die Speicherung der Information in einer DB Tabelle kann erheblich günstiger sein.
Der Grund ist einfach - die Funktion liest ein zu prüfendes Image komplett ein um dann daraus die Informationen zu gewinnen.
Bei kleinen Images keine große Sache:
Sind es jedoch größere oder gar ziemlich große Images wird entsprechend viel RAM belegt.
Kommen dann auch noch die Besucher in Mengen dann wird u.U. eine kritische Masse erreicht und der Server kann abstürzen.
Bei großen Images und vielen Besuchern wird zudem wegen des verbrauchten RAM's die Sache sehr gemütlich.
Besser ist es mit eigenen Funktionen Size zu ermitteln.
Bei PNG und GIF Formaten keine große Sache - da müssen nur wenige Bytes vom Imagefileanfang gelesen werden - bei JPG jedoch die Information nicht im Headerbereich zu finden sondern nach der Kennung 0xFFC0 irgendwo im File selbst.
Eine Eigenbeschränkung auf PNG als Universalformat wäre dann sinnvoll.
Bei JPG wäre die Alternative die die Daten dem Filenamen anzuhängen um sie mit einer kleinen PHP Funktion auszulesen.
Ja sogar die Speicherung der Information in einer DB Tabelle kann erheblich günstiger sein.
Donnerstag, 2. Januar 2014
CSS Verschachtelung spielt beim Speed eine Rolle
CSS als entscheidendes Formatierungs- und Darstellungsmittel bei Webseiten ist wichtig.
Was aber so einige CSS Künstler nicht bedenken - ein Browser muss für jeden Absatz, jeden Inhalt die CSS durchgehen ob es dafür eine entsprechende Regel gibt oder nicht.
Das kostet Zeit und die läppert sich teils enorm.
Die Zeit ist zudem abhängig vom Client (Browser) und natürlich der Rechenleistung des Clientrechners.
Unter Firefox ab Version 11 gibt es die Möglichkeit sich die Verschachtelung der CSS dreidimensional anzeigen zu lassen.
Hier einmal die Ansicht einer aktiven Seite im Netz bei der unter dem Gesichtspunkt Speed so ziemlich alles falsch gemacht wurde:
Bereits bei dieser Ansicht kann man die teils enorme Verschachtelung erkennen, die ein Browser abarbeiten muss bevor er zur Sache kommen kann.
Unter FF kann man natürlich die Darstellung drehen und die Größe verändern und sich auch den HTML Quellcode anschauen der für ein Detail verantwortlich ist.
Wer nun meint das so etwas nur unbedeutende Folgen hat der irrt.
Neben den Faktoren Generierungszeit ,Datenmenge,Transferzeit, Anbindungen ist das Rendering ein ganz wichtiger Faktor.
Hier einmal die Amazon - Startseite von eben (Momentaufnahme).
Gut zu erkennen ist das die Verschachtelung ebenfalls eine ansehnliche Größenordnung hat aber anders struktuiert ist. Man versucht hier ganz klar die Verschachtelung dort zu reduzieren wo es dem Designer möglich erscheint. Der Erfolg ist dennoch verbesserungswürdig.
Und nun noch eine Seite die optimal struktuiert und dabei voll responsive ist:
Die Zeitunterschiede sind enorm.
Da sie abhängig sind vom Browser und Rechenleistung des Clients selbst ist klar, das schwächere Rechner und Browser länger brauchen um eine Seite darzustellen.
Das trifft insbesondere alle mobilen Empfangsgeräte.
Man sollte also auch bei der CSS versuchen diese möglichst einfach zu halten.
Nicht benötigte Teile sollte man entfernen.
Und bitte nicht für jeden Kleinkram eine CSS definieren.
Was aber so einige CSS Künstler nicht bedenken - ein Browser muss für jeden Absatz, jeden Inhalt die CSS durchgehen ob es dafür eine entsprechende Regel gibt oder nicht.
Das kostet Zeit und die läppert sich teils enorm.
Die Zeit ist zudem abhängig vom Client (Browser) und natürlich der Rechenleistung des Clientrechners.
Unter Firefox ab Version 11 gibt es die Möglichkeit sich die Verschachtelung der CSS dreidimensional anzeigen zu lassen.
Hier einmal die Ansicht einer aktiven Seite im Netz bei der unter dem Gesichtspunkt Speed so ziemlich alles falsch gemacht wurde:
Bereits bei dieser Ansicht kann man die teils enorme Verschachtelung erkennen, die ein Browser abarbeiten muss bevor er zur Sache kommen kann.
Unter FF kann man natürlich die Darstellung drehen und die Größe verändern und sich auch den HTML Quellcode anschauen der für ein Detail verantwortlich ist.
Wer nun meint das so etwas nur unbedeutende Folgen hat der irrt.
Neben den Faktoren Generierungszeit ,Datenmenge,Transferzeit, Anbindungen ist das Rendering ein ganz wichtiger Faktor.
Hier einmal die Amazon - Startseite von eben (Momentaufnahme).
Gut zu erkennen ist das die Verschachtelung ebenfalls eine ansehnliche Größenordnung hat aber anders struktuiert ist. Man versucht hier ganz klar die Verschachtelung dort zu reduzieren wo es dem Designer möglich erscheint. Der Erfolg ist dennoch verbesserungswürdig.
Und nun noch eine Seite die optimal struktuiert und dabei voll responsive ist:
Die Zeitunterschiede sind enorm.
Da sie abhängig sind vom Browser und Rechenleistung des Clients selbst ist klar, das schwächere Rechner und Browser länger brauchen um eine Seite darzustellen.
Das trifft insbesondere alle mobilen Empfangsgeräte.
Man sollte also auch bei der CSS versuchen diese möglichst einfach zu halten.
Nicht benötigte Teile sollte man entfernen.
Und bitte nicht für jeden Kleinkram eine CSS definieren.
Samstag, 28. Dezember 2013
Cmsmadesimple völlig unbrauchbar geworden
Das CMS mit dem Namen Cmsmadesimple kenne ich gut und das seit Jahren.
Es hat auf dem ersten Blick einige charmante Seiten
Das Spielchen kann man mit erhöhtem Einsatz wiederholen.
b. US Site
Es hat auf dem ersten Blick einige charmante Seiten
- relativ leicht bedienbar
- gute Ausbaufähigkeit durch Module und Plugins
- im ersten Schritt ist es leicht installierbar (mit Defaultinhalten und Defaulttemplates)
- Foren versprechen Hilfe.
Aber es hat bereits von Anfang an so seine Schattenseiten - hier nur einmal zwei davon die fast jedem auffallen der damit bereits gearbeitet hat
- die individuelle Einrichtung erfordert tiefgreifende Kenntnisse von Smarty und vom CMS System
- es ist langsam in der Ausführung.
Und es gibt noch andere Dinge die man kennt wenn man sich damit beschäftigt hat
- die meisten von den hunderten Modulen und Plugins sind in der aktuellen Version nicht mehr lauffähig
- die meisten von den hunderten Modulen und Plugins sind zudem schlecht gepflegt
- das System selbst ist konzeptionell veraltet und überfrachtet - so unterstützt man Mysql 4.X (die Version wird seit Jahren nicht mehr von Mysql geliefert) und verwendet Adodb light - ein Layersystem das ebenfalls seit Jahren nicht mehr gepflegt wird und auch völlig unnötig ist, da man lediglich nur noch Mysql unterstützt.
Für jeden Fliegenfurz wird eine eigene PHP Klasse genutzt. - mit jahrelanger Verzögerung hat man Smarty 3 adaptiert und zwar derart mies, das das ganze System nur über die Smarty2 - Kompatibilitätsklasse arbeitet
- Zudem hat man längst die Idee einer Templateengine verlassen (Trennung Code und Design)
Wer in den Foren Hilfe sucht der darf nicht damit rechnen das er eine Antwort bekommt.
Man kann schauen wann man will - das Limit von unbeantworteten Posts von 1000 ist immer erreicht.
Die Liste des Bug Trackers nur für die Core ist sehr lang und die Einträge ohne Action sind bis 1 1/2 Jahre alt.
Das alles ist schlimm - aber solange man ein solches System irgendwie zum laufen bringt fällt es wenigen auf.
Das alles ist schlimm - aber solange man ein solches System irgendwie zum laufen bringt fällt es wenigen auf.
Und was vielen Nutzern nicht auffällt ist der eingebaute Wachstumsbegrenzer.
Wer mit Siege z.B. die deutsche Site mit nur 30 Besuchern belastet und als Besucher 31 Webpagetest.org laufen lässt erhält folgendes Ergebnis:
Hier zum Vergleich die US Site:
Das Spielchen kann man mit erhöhtem Einsatz wiederholen.
Geht man auf 100 Besucher kann es durchaus passieren das die US wie aber auch die deutsche Site komplett absemmelt.
Hier nur zur Info wie das denn aussieht:
a. deutsche Site
b. US Site
Aber bereits bei viel kleineren Mengen Zeiten von 3,4 bis 5,8 Sekunden zu erreichen - das geht überhaupt nicht.
Nun will man sich ja nichts vormachen - jeder der eine Site mit einem System aufbaut der geht eigentlich davon aus das man 100 Besucher mal gleichzeitig bedienen können muss und rechnet nie damit das man bereits bei 30 Besuchern Zeitprobleme bekommt.
Die Grenze liegt bei 1 Sekunde komplett gerendert für optimalen Speed , darüber fällt die Besucherzahl und ab 1,5 Sekunden laufen einem die Besucher in Mengen weg.
Nun es sind nur zwei Beispiele die hier zu sehen sind - aber es sieht bei real existierenden Nutzersites im wesentlichen auch nicht besser aus.
Eine ganz schlimme Sache ist der Umstand das dieses System im Laufe der Jahre immer mehr an Leistung verloren hat.
Es wird neben Bugbeseitigung mehr an neuen Features gearbeitet - die nur wenigen überhaupt etwas bringt - es wird aber nie an wesentlichen Dingen geschraubt.
Spricht man das übrigens an dann hat man im US Forum aber auch im deutschen nicht autorisiertem Forum eine heilige Kuh geschlachtet.
Meine Meinung - Finger weg von diesem System .
Die Performance - Ergebnisse kann übrigens jedermann selbst nachvollziehen - man nimmt z.B. Siege als Programm das die Vorlast erzeugt - Webpagetest.org ist Online.
Freitag, 27. Dezember 2013
Was zum Teufel ist Speed in dynamischen Systemen ?
So manche Webdesigner und kleine Agenturen verstehen nur Bahnhof wenn jemand etwas von Seitenspeed erzählt.
Zudem bietet manche Software die Anzeige in der Art " Generated in xxx seconds" an - das wird dann mit Speed verwechselt.
Tatsächlich setzt sich der vom Besucher erlebte Speed aus diversen Faktoren zusammen.
Senden bedeutet hier - der Host drückt die Daten in die Leitungen des Netzes.
Diese Zeit ist in einem dynamischen System ebenfalls dynamisch und schwankt teils enorm.
Es macht auch keinen Sinn als Einziger mal eine Seite aufzurufen um sich dann zu sagen - die Zeit ist gut.
Man muss mit einer Anzahl X von Besuchern rechnen die gleichzeitig ein solches System belasten.
Und da sieht es sehr häufig so aus das ein System bei 100 Besuchern die gleichzeitig Aktionen unternehmen Zeiten von 30.07 Sekunden heraus kommen, der erste Besucher aber in 0.30 Sekunden seine Inhalte in die Leitung gedrückt bekommt.
Schaut man sich einen solchen Test über alles an stellt man erschreckt fest das bei solchen Systemen weit über 90 % mehr als 6 Sekunden unter dynamischer Last benötigen um ihre Inhalte zu generieren - völlig unbrauchbar, es sei denn man legt Sites an die so gut wie keine Besucher haben.
Eine deutsche Seite von Deutschland aus abgerufen ist schneller da als wenn man sie von Australien aus abruft.
Nun werden Inhalte nicht komplett abgeschickt sondern in Datenpakete aufgeteilt und die können durchaus unterschiedliche Wege nehmen - erst beim Empfänger werden sie zusammengesetzt.
Je höher das Datenvolumen desto mehr Päckchen müssen gesendet und beim Empfänger zusammengesetzt werden.
Und einzelne HTML Bestandteile wie Imagelinks, CSS Links etc. werden als einzelner Request jeweils für sich betrachtet und ebenfalls in Päckchen aufgeteilt und gesendet.
Damit wird klar - je höher das Transfervolumen in Bytes und je höher die Anzahl von Request's ist desto langsamer wird der Transport.
Und natürlich ist auch klar das der Gesamttransport abhängig ist von der Leistung von Knotenpunkt zu Knotenpunkt und natürlich auch von der Anbindung des Empfängers.
Die Dinge die ein Sender anstellen kann wird mit Pagespeed Mitteln angegangen.
Aber es sind auch jede Menge Methoden enthalten die auf die Arbeitsweise der Browser selbst eingehen um beim Empfänger selbst ein optimales Rendering zu ermöglichen.
Optimal bedeutet hier schnellstmöglich und tatsächlich - diese Methoden haben einen durchschlagenden Erfolg.
Es kommt also insgesamt darauf an das
Wenn eine Seite von dem Zeitpunkt an in maximal 1 Sekunde komplett vorhanden und gerendert wurde ist der Speed optimal.
Über 1 Sekunde bis 1,5 Sekunden ist der Wert noch akzeptabel aber man muss bereits mit Besucherschwund rechnen , d.h. Besucher verlassen die Seite ohne sie gelesen zu haben.
Über 1,5 Sekunden verlassen Besucher eine Seite schon in Mengen !
Zudem bietet manche Software die Anzeige in der Art " Generated in xxx seconds" an - das wird dann mit Speed verwechselt.
Tatsächlich setzt sich der vom Besucher erlebte Speed aus diversen Faktoren zusammen.
Die Generierungszeit
Das ist die Zeit die ein System benötigt um das HTML einer Seite zu generieren und zu senden.Senden bedeutet hier - der Host drückt die Daten in die Leitungen des Netzes.
Diese Zeit ist in einem dynamischen System ebenfalls dynamisch und schwankt teils enorm.
Es macht auch keinen Sinn als Einziger mal eine Seite aufzurufen um sich dann zu sagen - die Zeit ist gut.
Man muss mit einer Anzahl X von Besuchern rechnen die gleichzeitig ein solches System belasten.
Und da sieht es sehr häufig so aus das ein System bei 100 Besuchern die gleichzeitig Aktionen unternehmen Zeiten von 30.07 Sekunden heraus kommen, der erste Besucher aber in 0.30 Sekunden seine Inhalte in die Leitung gedrückt bekommt.
Schaut man sich einen solchen Test über alles an stellt man erschreckt fest das bei solchen Systemen weit über 90 % mehr als 6 Sekunden unter dynamischer Last benötigen um ihre Inhalte zu generieren - völlig unbrauchbar, es sei denn man legt Sites an die so gut wie keine Besucher haben.
Der Transport
Wie im realen Leben dauert ein Transport länger, je weiter der Empfänger vom Sender entfernt sitzt.Eine deutsche Seite von Deutschland aus abgerufen ist schneller da als wenn man sie von Australien aus abruft.
Nun werden Inhalte nicht komplett abgeschickt sondern in Datenpakete aufgeteilt und die können durchaus unterschiedliche Wege nehmen - erst beim Empfänger werden sie zusammengesetzt.
Je höher das Datenvolumen desto mehr Päckchen müssen gesendet und beim Empfänger zusammengesetzt werden.
Und einzelne HTML Bestandteile wie Imagelinks, CSS Links etc. werden als einzelner Request jeweils für sich betrachtet und ebenfalls in Päckchen aufgeteilt und gesendet.
Damit wird klar - je höher das Transfervolumen in Bytes und je höher die Anzahl von Request's ist desto langsamer wird der Transport.
Und natürlich ist auch klar das der Gesamttransport abhängig ist von der Leistung von Knotenpunkt zu Knotenpunkt und natürlich auch von der Anbindung des Empfängers.
Die Dinge die ein Sender anstellen kann wird mit Pagespeed Mitteln angegangen.
Pagespeed
Das sind eine Vielzahl von Methoden und Möglichkeiten die jeder Webanbieter einsetzen kann um den Transport zu beschleunigen.Aber es sind auch jede Menge Methoden enthalten die auf die Arbeitsweise der Browser selbst eingehen um beim Empfänger selbst ein optimales Rendering zu ermöglichen.
Optimal bedeutet hier schnellstmöglich und tatsächlich - diese Methoden haben einen durchschlagenden Erfolg.
Es kommt also insgesamt darauf an das
- Seiten auf der Senderseite schnellstmöglich generiert werden - es gibt da Titel die leisten über 600.000 Seiten pro Minute - andere sehr bekannte nur ein paar hundert pro Minute.
- Den Transport zu beschleunigen
- Das Rendering zu beschleunigen
Was ist ein akzeptabler Speed ?
Der Countdown beginnt wenn eine URL geöffnet werden soll.Wenn eine Seite von dem Zeitpunkt an in maximal 1 Sekunde komplett vorhanden und gerendert wurde ist der Speed optimal.
Über 1 Sekunde bis 1,5 Sekunden ist der Wert noch akzeptabel aber man muss bereits mit Besucherschwund rechnen , d.h. Besucher verlassen die Seite ohne sie gelesen zu haben.
Über 1,5 Sekunden verlassen Besucher eine Seite schon in Mengen !
Welche Messmittel gibt es ?
Es gibt eine große Anzahl von Programmen mit denen man messen kann ( http://www.opensourcetesting.org/performance.php ).
Eines der besten ist das Programm Siege.
Allerdings rendern diese Programme nicht sondern erstellen eine dynamische Last und rufen alles ab was zu senden wäre.
Damit kann man aber klar erkennen ob ein System X oder Y eine Zielvorstellung (Besuchezahl X gleichzeitig) überhaupt erfüllen kann.
Mittwoch, 25. Dezember 2013
Das neue Pagespeed Insights
Pagespeed als Plugin leistet wertvolle Dinge.
Pagespeed Insights - die Onlineversion - geht aktuell ein wenig weiter.
Auf der einen Seite ist die Version nicht so arg streng.
Ein paar hundert unnötige Bytes im HTML Quellcode (Stichwort Kommentare) wird zwar angezeigt aber nicht mit Punktabzug bestraft.
Der wesentliche Teil von Pagespeed ist unverändert geblieben.
Nur werden aber gleichzeitig die Desktop - und Mobileprüfungen vorgenommen.
Und es wird erheblich mehr wert auf eine mobile Nutzungsmöglichkeit gelegt als jemals zuvor.
Damit zieht man die Konsequenzen aus dem inzwischen überwiegend mobilen Zugriff auf Internetinhalte.
so nennt man es - es werden also Ergebnisse daraus angezeigt aber noch nicht bewertet.
Man darf damit rechnen das diese Punkte in den nächsten 6 Monaten in die Bewertung eingehen wird.
Den meisten Erstellern von Webinhalten ist das aber unbequem weil man immer ein Auge sozusagen auf die Fahrbahnmarkierungen werfen muss und denken sich meine 80 ..88 Pagespeedpunkte reichen aus.
Und tatsächlich - die meisten CMS unterstützen die Inhalteersteller nicht im geringsten.
Tatsächlich aber sind die Unterschiede z.B. von Pagespeed 88 zu 100 bedeutungsvoll.
Und das nicht nur was den gemeinsamen Zugriff von vielen Besuchern gleichzeitig betrifft sondern auch bei Nutzererlebnis und damit sehr schnell macht sich das dann bei den Positionen in den Suchmaschinenergebnissen bemerkbar.
So sieht es z.B. aus wenn man erfolgreich gearbeitet hat.
Bei den neuen Punkten bezüglich Nutzererfahrung geht es um folgendes:
Damit sind z.B. Flash, Java oder Silverlightplugins gemeint - aber auch Video- und Audioplayer anderer Art.
Browser verhalten sich da unterschiedlich und meist negativ.
Video- und Audiodateien sollte man via HTML anbieten.
Das bedeutet - ein Besucher sieht wenig bis nichts und muss heftige Aktionen ausführen um die Inhalte lesen und sehen zu können.
Man beachte - die z.Z. am meisten gebräuchliche Screenröße ist 320 x 480 deswegen testet Pagespeed exakt auf diese Größe hin.
Andere Viewports müssen mit Mediaqueries eingestellt werden.
Man beachte in dem Zusammenhang das 4k Monitore bei Desktop im kommen sind, Full HD Standard und 2560 Pixel auch bei hochwertigen mobilen Geräten existieren.
Pagespeed Insights - die Onlineversion - geht aktuell ein wenig weiter.
Auf der einen Seite ist die Version nicht so arg streng.
Ein paar hundert unnötige Bytes im HTML Quellcode (Stichwort Kommentare) wird zwar angezeigt aber nicht mit Punktabzug bestraft.
Der wesentliche Teil von Pagespeed ist unverändert geblieben.
Nur werden aber gleichzeitig die Desktop - und Mobileprüfungen vorgenommen.
Und es wird erheblich mehr wert auf eine mobile Nutzungsmöglichkeit gelegt als jemals zuvor.
Damit zieht man die Konsequenzen aus dem inzwischen überwiegend mobilen Zugriff auf Internetinhalte.
NutzererfahrungBeta
Derzeit nicht im Gesamtergebnis berücksichtigt
so nennt man es - es werden also Ergebnisse daraus angezeigt aber noch nicht bewertet.
Man darf damit rechnen das diese Punkte in den nächsten 6 Monaten in die Bewertung eingehen wird.
Pagespeed schwierig ?
Das denken immer noch viele Webanbieter - real sind es aber nur wenige Regeln die man berücksichtigen muss und es ist einfach wenn man mit denkt.Den meisten Erstellern von Webinhalten ist das aber unbequem weil man immer ein Auge sozusagen auf die Fahrbahnmarkierungen werfen muss und denken sich meine 80 ..88 Pagespeedpunkte reichen aus.
Und tatsächlich - die meisten CMS unterstützen die Inhalteersteller nicht im geringsten.
Tatsächlich aber sind die Unterschiede z.B. von Pagespeed 88 zu 100 bedeutungsvoll.
Und das nicht nur was den gemeinsamen Zugriff von vielen Besuchern gleichzeitig betrifft sondern auch bei Nutzererlebnis und damit sehr schnell macht sich das dann bei den Positionen in den Suchmaschinenergebnissen bemerkbar.
So sieht es z.B. aus wenn man erfolgreich gearbeitet hat.
Bei den neuen Punkten bezüglich Nutzererfahrung geht es um folgendes:
Avoid Plugins
Damit sind z.B. Flash, Java oder Silverlightplugins gemeint - aber auch Video- und Audioplayer anderer Art.
Browser verhalten sich da unterschiedlich und meist negativ.
Video- und Audiodateien sollte man via HTML anbieten.
Configure the Viewport
Wird der Viewport nicht konfiguriert wird ein mobiles Gerät eine Webseite als Desktop behandeln und diese dann so rendern das sie in den aktuellen Bildschirm passt.Das bedeutet - ein Besucher sieht wenig bis nichts und muss heftige Aktionen ausführen um die Inhalte lesen und sehen zu können.
Man beachte - die z.Z. am meisten gebräuchliche Screenröße ist 320 x 480 deswegen testet Pagespeed exakt auf diese Größe hin.
Andere Viewports müssen mit Mediaqueries eingestellt werden.
Man beachte in dem Zusammenhang das 4k Monitore bei Desktop im kommen sind, Full HD Standard und 2560 Pixel auch bei hochwertigen mobilen Geräten existieren.
Size Content to Viewport
Inhalte sollen horizontal ohne scrollen zu müssen auf dem Schirm passen.
Muss man eine Seite horizontal scrollen ist die Nutzererfahrung negativ - Besucher laufen weg und kommen nicht wieder.
Size Tap Targets Appropriately
Das bedeutet nichts weiter als das Buttons, Eingabefelder aber auch normale Links mit den Fingern bedient werden können - also nicht derart klein machen das man eine Stecknadel benötigt um eine Aktion auszulösen.
Use Legible Font Sizes
Bei Fontgrößen muss man bedenken das mobile Geräte viel mehr Bildpunkte auf einem Quadratzentimeter darstellen als ein Desktopgerät.
Das aber bedeutet eine Schrift von 12px wird auf einem Smartphone u.U. nicht mehr lesbar.
Es sind zwar nur wenige neue Punkte aber sie sind glasklar auf mobile Nutzung des Internets ausgerichtet.
Noch vor 2 Jahren gab es jede Menge "Fachleute" die sich deutlich damit bemerkbar gemacht haben das eine mobile Nutzung des Netzes nie die Bedeutung vom Desktopbetrieb haben wird.
Heute ist die mobile Nutzung Standard und Desktop die Ausnahme - welch ein Irrtum.
Und die Erfolgsgeschichte geht weiter.
Wer sich als Webersteller und -Anbieter nicht daran orientiert der steht auf der Verliererseite.
Abonnieren
Posts (Atom)