nicht angemeldet
Rendering-Engine
Auge
Orlok
marctrix
Matthias Scharwies
JürgenBHallo,
Ich interessiere mich um den zeitlichen Ablauf bei der Darstellung von sehr langen Seiten. Aktuelle Webseiten nutzen ja dynamisches Nachladen mit Hilfe vvon Javascript. Wie sieht das aber aus, wenn kein Javascript eeingesetzt wird. Rendern die Maschinen von Firefox und Chrome zuerst die komplette Seite, bevor alles dargestellt wird? Oder was wird zuerst dargestellt, Gibt es eine Reihenfolge?
Wäre dankbar, wenn jemand Kenntnis dazu hat, wie das gemacht wird.
-
Hallo
Ich interessiere mich um den zeitlichen Ablauf bei der Darstellung von sehr langen Seiten. Aktuelle Webseiten nutzen ja dynamisches Nachladen mit Hilfe vvon Javascript. Wie sieht das aber aus, wenn kein Javascript eeingesetzt wird. Rendern die Maschinen von Firefox und Chrome zuerst die komplette Seite, bevor alles dargestellt wird? Oder was wird zuerst dargestellt, Gibt es eine Reihenfolge?
Es wird immer alles gerendert, was geladen wurde. Voraussetzung ist, dass es sich (abgesehen von den Fehlerkorrekturen der Browser) um ein vollständiges Dokument handelt. Im Falle des nachladens mit JavaScript wird halt das bereits vorher vollständige Dokument bei eintreten gewisser Events an vorher definierten Stellen um weiteren Inhalt ergänzt.
Tschö, Auge
--
Eine Kerze stand [auf dem Abort] bereit, und der Almanach des vergangenen Jahres hing an einer Schnur. Die Herausgeber kannten ihre Leser und druckten den Almanach auf weiches, dünnes Papier.
Kleine freie Männer von Terry Pratchett -
Hallo Torsten
Ich interessiere mich um den zeitlichen Ablauf bei der Darstellung von sehr langen Seiten. Aktuelle Webseiten nutzen ja dynamisches Nachladen mit Hilfe von Javascript. Wie sieht das aber aus, wenn kein Javascript eingesetzt wird. Rendern die Maschinen von Firefox und Chrome zuerst die komplette Seite, bevor alles dargestellt wird? Oder was wird zuerst dargestellt, Gibt es eine Reihenfolge?
Das ist ein einigermaßen komplexes Thema. :-)
Grundsätzlich gilt, dass Browser Webseiten seit langer Zeit inkrementell rendern. Das bedeutet, dass ein Teil der Seite bereits zur Anzeige gebracht werden kann, während der Rest der Seite noch über das Netzwerk geladen wird. Es wird also nicht darauf gewartet, bis das Dokument vollständig übertragen wurde, bevor mit dessen Verarbeitung begonnen wird. Diese Vorgehensweise hat den Vorteil, dass Inhalte schneller zugänglich gemacht werden und Benutzer früher mit der Seite interagieren können, als wenn erst nach dem vollständigen Laden des Dokuments mit der Verarbeitung begonnen würde.
Ein grobes Schema für den Ablauf beim Rendern eines Dokuments:
+----------------------------+ | | | Network | | | +-------------||-------------+ _||_ \ / +-------------\/-------------+ | | | HTML Parsing | | | +-------------||-------------+ _||_ \ / +-------------\/-------------+ | | | Render Tree Construction | | | +-------------||-------------+ _||_ \ / +-------------\/-------------+ | | | Layout | | | +-------------||-------------+ _||_ \ / +-------------\/-------------+ | | | Painting | | | +----------------------------+Wird per HTTP Response ein Dokument empfangen, dann wird direkt mit der Verarbeitung begonnen. Dabei reicht die Netzwerk–Komponente des Browsers die eingehenden Daten an den HTML Parser weiter – und zwar sobald genug Bytes empfangen wurden, dass dieser sinnvoll damit arbeiten kann. Das Parsing selbst ist dann auch wieder in mehrere Abschnitte unterteilt. Welche Regeln dabei eingehalten werden müssen, insbesondere auch in dem Fall, dass das Dokument nicht den Anforderungen an ein valides HTML Dokument genügt, kannst du im Abschnitt Parsing HTML Documents der Spezifikation nachlesen.
Bevor mit dem eigentlichen Parsing begonnen werden kann, also der Transformation des Markups in eine entsprechende Objektrepräsentation, schlägt aber erstmal die Stunde des Decoders. Das ist die Komponente, die dafür zuständig ist herauszufinden, wie das Dokument kodiert wurde, um daraus dann wieder Text zu generieren den der Parser lesen kann. Im Idealfall sollte der Browser die Kodierung des Dokuments einem HTTP Header der Response vom Server entnehmen können, aber es gibt natürlich keine Garantie, dass eine solche Angabe auch hinzugefügt wurde. Gibt es auch kein Byte Order Mark am Anfang des Dokuments, dem Informationen entnommen werden können, dann muss der Browser raten. Wenn’s dumm läuft stellt er später fest, dass er falsch geraten hat, dann ist der Parsing–Fortschritt zu diesem Zeitpunkt nichtig und es muss von vorn begonnen werden.
Hat der Browser aufgrund entsprechender Angaben oder auf Basis einer Heuristik eine Entscheidung getroffen, wie das Dokument zu dekodieren ist, dann wird mit dem Lesen der empfangenen Daten begonnen. Wie üblich, ist der Prozess des Parsings dabei konzeptionell in zwei Hauptabschnitte aufgeteilt: Die lexikalische Analyse, bei der Zeichen gelesen und den Wörtern der Sprache zugeordnet werden, wobei Wort im Kontext formaler Sprachen einfach als eine endliche Folge von Symbolen zu verstehen ist, und syntaktische Analyse, bei der gemäß den Syntax–Regeln der Sprache ein Ableitungsbaum erzeugt wird. In modernen Browsern gibt es vor der lexikalischen Analyse noch einen vorgeschalteten Preparsing–Prozess, bei dem das Dokument nach Referenzen auf externe Ressourcen durchsucht wird. Preparsing und lexikalische Analyse können aber auch in einem Schritt erfolgen.
Das Parsing des Dokuments lässt sich schematisch etwa so darstellen:
+----------------------------+ | | | Preparsing | | | +-------------||-------------+ _||_ \ / +-------------\/-------------+ | | | Tokenization | | | +-------------||-------------+ _||_ \ / +-------------\/-------------+ | | | DOM Construction | | | +----------------------------+Während des Preparsings werden die dekodierten Zeichen nach Elementen durchsucht, die weitere Dateien wie beispielsweise Bilder referenzieren und die gegebenenfalls Anweisungen enthalten, mit welcher Priorität diese Ressourcen vom Browser geladen werden sollen. Auch das ist wieder eine Maßnahme, um Benutzern Inhalte möglichst schnell zugänglich zu machen. Würde das Dokument nicht auf diese Weise vorab gescannt, könnte es passieren, dass sich während des regulären Parsings herausstellt, dass weitere Ressourcen vom Server geladen werden müssen, die eigentlich schon früher hätten geladen werden können.
Bei der lexikalischen Analyse transformiert der Browser den eingehenden Zeichenstrom in Token. Das sind Zeichenketten, die im Kontext der Sprache eine besondere Bedeutung haben, zugeordnet zu bestimmten Typen, von denen es in HTML aber nicht so furchtbar viele gibt. Das ist also eine Klassifizierung von erkannten Wörtern. Ein Beispiel für ein Token wäre die Zeichenkette <body> vom Typ 'start tag'. Außer dem jeweiligen Typ können auch weitere Metainformationen zu dem erkannten Wort gespeichert werden. Implementiert ist das Ganze als endlicher Automat mit einer beachtlichen Menge von Zuständen. Nachzulesen im Kapitel Tokenization der Spezifikation.
Aus den Token wird dann die Objektrepräsentation der Seite generiert, das bedeutet, es werden gemäß der Spezifikation des DOM verschiedene Objekte erzeugt, die beispielsweise Elemente, Attribute oder textuelle Inhalte repräsentieren. Diese Objekte werden dann in eine Baumstruktur eingefügt, deren Wurzel das HTML-Element darstellt. Auch dieser Vorgang ist inkrementell. Es wird also nicht erst darauf gewartet, dass der vorliegende Abschnitt des Dokuments in Token übersetzt wurde, sondern sobald ein Token zur Verfügung steht, wird es vom Tokenizer an die Komponente weitergereicht, die für die Konstruktion des DOM–Baums zuständig ist, damit die nötigen Objekte direkt erzeugt werden können. Zu diesem Zeitpunkt kann es dann auch passieren, dass Skripte in den Prozess eingreifen, die weiteres Markup produzieren, das geparst werden muss. In diesem Fall muss der ursprüngliche Vorgang natürlich unterbrochen werden.
Neben der Konstruktion des DOM wird außerdem eine Repräsentation der Styles der Seite erzeugt, das CSSOM. Hier wird im Prinzip erstmal genau so vorgegangen wie beim Lesen des HTML–Dokuments. Das heißt, eingebettete oder geladene Stylesheets werden erstmal in Token zerlegt und dann weiterverarbeitet. Hier wird der Browser alles was er an Stilen findet in eine gemeinsame Datenstruktur werfen, die dann auch Regeln aus dem Browser–Stylesheet und gegebenenfalls Stilangaben des Benutzers enthält. Das wird dann danach sortiert, welche Regeln Vorrang haben, nach Herkunft, Spezifität und Reihenfolge im Dokument. Dabei werden auch Werte berechnet beziehungsweise in andere Einheiten umgewandelt. Für Stylesheets und die darin notierten Regeln werden Objekte erzeugt, auf die dann mittels JavaScript zugegriffen werden kann, ebenso wie beim DOM der Seite.
+---------------+ +---------------+ | | | | | DOM | | CSSOM | | | | | +-------||------+ +------||-------+ _||_ _||_ \ / \ / +-------\/-----------------\/-------+ | | | Render Tree | | | +-----------------------------------+Aus DOM und CSSOM wird schließlich der Render Tree für die Seite gebaut, der Grundlage für Layout und Painting ist, also grob gesagt die Berechnung der Größe und die Anordnung von Boxen, sowie das anschließende Hinzufügen von Farbe, Schatten und was es sonst noch so an Gestaltungsmöglichkeiten gibt. Dabei werden nur solche Objekte eingefügt, die für die Darstellung der Seite relevant sind. Aus diesem Baum werden dann am Ende mehrere Bitmaps generiert, die auf dem Bildschirm angezeigt werden können, wobei auch berücksichtigt werden muss, ob und wenn ja welche Teile der Seite mehr als einmal gerendert werden müssen, etwa wegen Animationen. Auch der Render Tree wird inkrementell erzeugt.
Wir können also zusammenfassen, dass definitiv nicht die komplette Seite verarbeitet wird, bevor sie dem Benutzer angezeigt wird. Das wäre aus Sicht der Benutzer eine Katastrophe. Die Seite wird vielmehr Stück für Stück aufgebaut. Es ist aber zu beachten, dass es dabei keine strikte Reihenfolge gibt. Es ist nicht vorherzusehen, welche Elemente zuerst auf dem Bildschirm erscheinen. Zwar wird prinzipiell sichtbarer Inhalt relativ am Anfang des Dokuments mit großer Wahrscheinlichkeit vor Inhalten an dessen Ende zur Anzeige gebracht, aber es ist nicht gesagt, dass ein Element, das der direkter Nachfolger eines anderen Elements ist, auch in jedem Fall nach diesem gerendert wird. Jede Rendering–Engine hat ihre eigenen Strategien, wie mit unvollständigen Informationen umzugehen ist.
Viele Grüße,
Orlok
-
Das bedeutet, dass ein Teil der Seite bereits zur Anzeige gebracht werden kann, während der Rest der Seite noch über das Netzwerk geladen wird. ... hat den Vorteil, dass Inhalte schneller zugänglich gemacht werden und Benutzer früher mit der Seite interagieren können
Mit solchen Seiten muss ich auch gelegentlich interagieren.
Meistens indem ich dem gewünschten Inhalt nachrenne, der durch die inzwischen üblichen mindestens 15 Scripte, Tracker und Werbeeinblendungen im Sekundentakt weiter herunter geschoben wird 😀Spaß beiseite, ein sehr ausführlicher Artikel! Den muss ich mir nach der Arbeit nochmal in Ruhe ansehen.
-
Hallo encoder
Mit solchen Seiten muss ich auch gelegentlich interagieren.
Meistens indem ich dem gewünschten Inhalt nachrenne, der durch die inzwischen üblichen mindestens 15 Scripte, Tracker und Werbeeinblendungen im Sekundentakt weiter herunter geschoben wird 😀Das kenne ich nur zu gut. Die Performance der meisten Seiten die ich besuche ist eine Katastrophe. Wenn ich mit dem Smartphone im Internet bin, geht regelmäßig der Bildschirm in Stand-by, bevor die Seite bedienbar ist. Das ist unterirdisch. Dazu kommt dann das von dir beschriebene Verhalten, dass nach dem initialen Rendern der Seite durch Skripte in großem Umfang neue Elemente eingefügt werden, was zu einer Kaskade von Reflows und Repaints führt.
Besonders schön ist das natürlich, wenn das zugrundeliegende Dokument mit den begehrten Inhalten relativ zügig geladen und gerendert wurde, die Skripte aber etwas länger auf sich warten lassen. Dann gibt es ein Zeitfenster, in dem die Seite so aussieht, als wäre sie bedienbar. Just in dem Moment, in dem man dann eine Aktion ausführen will, wird dann aber das Layout neu berechnet und man klickt versehentlich auf ein anderes Element, wie beispielsweise einen Werbebanner. 😠
Fast immer ist das dann die letzte Aktion, die ich als Besucher der Seite ausführe. Für mich sind solche Seiten nicht bedienbar. Ich habe heutzutage, genervt durch das ständige Warten, sogar noch weniger Geduld mit Webseiten als früher. Will sagen, wenn eine Seite nicht in drei bis fünf Sekunden responsiv ist, bin ich üblicherweise weg. Andere sehen das vermutlich genauso. Für die meisten Webentwickler ist das aber offenbar kein Grund, das eigene Handeln kritisch zu hinterfragen. Performanz und damit auch Bedienbarkeit genießen bei den meisten Projekten anscheinend keine Priorität.
Die Verbreitung von JavaScript–Frameworks wie React oder Vue hat meiner Ansicht nach auch einen großen Anteil an den von dir beschriebenen, häufig anzutreffenden Problemen. Statt mehr oder weniger fertige Dokumente an den Client auszuliefern, werden heute große Teile der Seite, oft sogar fast alles, mittels JavaScript erzeugt. Auch wenn das aus fachlicher Sicht meistens Unsinn ist. Es genügt also nicht mehr, das Laden des Dokuments und eines Stylesheets abzuwarten, sondern es muss darauf gewartet werden, dass alle erforderlichen Skripte geladen und fehlerfrei ausgeführt wurden, bevor die Seite bedient werden kann. Falls sie bedient werden kann.
Sowohl React als auch Vue sind vom Konzept her deklarativ, was ja erstmal nicht schlecht ist. Leider hat das zur Folge, dass prinzipiell nicht vorgesehen ist, am bestehenden DOM der Seite Veränderungen vorzunehmen. Was React oder Vue vom Entwickler erwarten, ist die Bereitstellung von Templates für Komponenten. Daraus wird dann ein virtuelles DOM erzeugt, also im Wesentlichen eine Abstraktion des realen DOM, aus dem dann unter der Haube die richtige DOM–Repräsentation der Komponente generiert wird. Das heißt, es werden in jedem Fall neue Elemente erzeugt und der Seite hinzugefügt, selbst dann, wenn es einen Fallback für die Komponente gibt, dessen DOM hätte wiederverwendet werden können. Ein solcher wird dann üblicherweise wieder aus dem DOM entfernt und an dessen Stelle die neuen Elemente eingefügt. Die Folgen sind Reflow und Repaint.
Mit unobtrusive JavaScript hat das alles nichts mehr zu tun. Ich halte das auch für ein konzeptionelles Problem, sprich, schnellere Netzwerke und Prozessoren werden diesbezüglich keine spürbaren Vorteile bringen. Je schneller die Daten verarbeitet werden können, desto mehr Daten werden übermittelt. Der Schlüssel zu performanteren Webseiten ist, die Stärken der involvierten Technologien zu erkennen und sich ihrer zu bedienen.
Die Browser sind heute verdammt gut darin, empfangene HTML–Dokumente und Stylesheets schnell zu verarbeiten und dem Benutzer zugänglich zu machen. Das Ziel sollte also sein, sie möglichst ungestört ihrer Arbeit nachgehen zu lassen, damit den Besuchern der Seite die Basisfunktionalität so schnell wie möglich zur Verfügung steht. Mit JavaScript kann dann zusätzliche Funktionalität bereitgestellt werden, wobei aber darauf geachtet werden sollte, nicht alles über den Haufen zu werfen, sondern nach Möglichkeit mit dem zu arbeiten, was bereits vorhanden ist.
Viele Grüße,
Orlok
-
Sowohl React als auch Vue sind vom Konzept her deklarativ, was ja erstmal nicht schlecht ist. Leider hat das zur Folge, dass prinzipiell nicht vorgesehen ist, am bestehenden DOM der Seite Veränderungen vorzunehmen. Was React oder Vue vom Entwickler erwarten, ist die Bereitstellung von Templates für Komponenten. Daraus wird dann ein virtuelles DOM erzeugt, also im Wesentlichen eine Abstraktion des realen DOM, aus dem dann unter der Haube die richtige DOM–Repräsentation der Komponente generiert wird. Das heißt, es werden in jedem Fall neue Elemente erzeugt und der Seite hinzugefügt, selbst dann, wenn es einen Fallback für die Komponente gibt, dessen DOM hätte wiederverwendet werden können. Ein solcher wird dann üblicherweise wieder aus dem DOM entfernt und an dessen Stelle die neuen Elemente eingefügt. Die Folgen sind Reflow und Repaint.
Das ist nicht ganz richtig. Zum Virtual DOM gehört in der Regel auch ein Diffing-Algorithmus, der merkt sich welche Knoten im DOM vorhanden sind und berechnet bei einem Update eine möglichst kleine Menge an Änderungen, die im DOM vorgenommen werden müsen, um den neuen Zustand auf den Bildschirm zu bringen. Diese Menge an Änderungen wird dann dem Framework-Renderer übergeben, der optimiert dann noch weiter, zum Beispiel werden Änderungen, die einen Reflow- oder Repaint auslösen gebatcht, also in einer einzigen DOM-Operation anstelle mehrerer abgearbeitet. Meiner Erfahrung nach ist der zusätzliche Overhead das meistens wert, zumindest wenn man in hinreichend komplexen, dynamischen Web-Anwendungen arbeitet. Das fällt schwer zu glauben und außer aus meiner eigenen Erfahrung kann ich da wenig belastbares Material zu liefern, außer vielleicht dieser Todo MVC Benchmark, da ist Vue sogar schneller als Vanilla.js.
Ein Problemfall ist der erste Framwork-Rendering-Vorgang, den hattest du vermutlich auch beim Schreiben im Hinterkopf. Da gibt es zwei Fälle zu unterscheiden, jenachdem ob der Server schon das statische HTML für den initialen Anwendungszustand geliefert hat oder nicht. Im zweiten Fall ist man verloren, denn da muss das Framework den kompletten Rendering-Vorgang selbst übernehmen, da gibt es noch nichts zu diffen, alles muss vom Framework in das DOM eingefügt werden. Das ist leider bei vielen SPAs so. Im ersten Fall kann man aber was machen. Vue.js zum Beispiel kann das statische HTML weiterbenutzen und wie oben beschrieben sofort den Diffing-Algorithmus einsetzen, um nur minimale Änderungen vorzunehmen. Das nennt sich in Vue.js Client Side Hydration. Das geht aber auch nicht ohne zusätzliche Vorkehrungen, das statische HTML muss Vue.js diverse Zusatzinformationen mitliefern, damit Vue.js sich richtig initialisiert. Das muss man nicht zu Fuß machen, für Vue gibt es Pakete um serverseitig entsprechendes Markup zu rendern, und man kann dafür die clientseitigen Templates auch wiederbenutzen. Das bringt sogar noch ein paar Goodies mit, zum Beispiel kann kritisches CSS von Vue direkt geinlined werden, um das Laden noch schneller zu machen.
-
Wenn man sich ansieht was NoScript alles findet wird einem schlecht. Da ist kein Wunder dass alles stinkend langsam ist. Zum Teil weit über 10 externe Scripts und sonstiges, damit man auch wirklich überall mit Werbung vollgepflastert und ausspioniert wird.
Vielleicht sollte mal jeder den betroffenen Seiten die Meinung sagen, wer weiß eventuell ändert sich ja dann was dran.
-
-
-
-
Servus!
Hej Orlok,
@Matthias Scharwies — dafür finden wir sicher ein warmes Plätzchen im Wiki, oder?
Evtl. als Unterseite von Browser?
Oder bei Grundlagen ?
Und dann verlinkt von Parser und Renderingengine (Diesen Begriff würde ich mit Bindestrich oder getrennt schreiben.).
Herzliche Grüße
Matthias Scharwies
--
"I don’t make typos. I make new words."-
Hej Matthias,
@Matthias Scharwies — dafür finden wir sicher ein warmes Plätzchen im Wiki, oder?
Evtl. als Unterseite von Browser?
Oder bei Grundlagen ?
Finde beides schwierig. Grundlagen sind die, mit denen ich anfange, wenn ich etwas neues lerne. Ich finde, dazu muss man das hier geschriebene nicht von Anfang an wissen.
Vielleicht wäre es sinnvoll neben HTML, CSS und JS noch einen Einstieg in den technischen Hintergrund des WWW zu geben. Da wären dann Client-Server-Architektur, DNS, vielleicht auch unterschiedliche Übertragungstechniken wie WLAN, LTE, DSL usw erklärt, wie Suchmaschinen funktionieren, woher die Standards kommen und eben auch, wie die Browser prinzipiell funktionieren. Alles wichtig irgendwo, aber um eine Webseite zu erstellen (zumal so lange nur HTML und CSS im Spiel sind) nicht unbedingt von Anfang an nötig.
Marc
-
Servus!
Hej Matthias,
@Matthias Scharwies — dafür finden wir sicher ein warmes Plätzchen im Wiki, oder?
Evtl. als Unterseite von Browser?
Oder bei Grundlagen ?
Finde beides schwierig. Grundlagen sind die, mit denen ich anfange, wenn ich etwas neues lerne. Ich finde, dazu muss man das hier geschriebene nicht von Anfang an wissen.
Vielleicht wäre es sinnvoll neben HTML, CSS und JS noch einen Einstieg in den technischen Hintergrund des WWW zu geben. Da wären dann Client-Server-Architektur, DNS, vielleicht auch unterschiedliche Übertragungstechniken wie WLAN, LTE, DSL usw erklärt, wie Suchmaschinen funktionieren, woher die Standards kommen und eben auch, wie die Browser prinzipiell funktionieren. Alles wichtig irgendwo, aber um eine Webseite zu erstellen (zumal so lange nur HTML und CSS im Spiel sind) nicht unbedingt von Anfang an nötig.
Meinst du diese Grundlagen?
Was ist das Internet? Internet of Things Entstehung des Internet Wie funktioniert das Internet? Datenübertragung Client-Server-Technologie Protokolle Domain Name System Wem gehört das Internet? Netzneutralität Web-TechnologienHerzliche Grüße
Matthias Scharwies
--
"I don’t make typos. I make new words."-
Hej Matthias,
Meinst du diese Grundlagen?
Ja 😉
Da würde ich das mit Aufnehmen: „Wie Browser eine Website darstellen“ oder so…
Marc
-
-
-
-
-
Super, VIELEN Dank! Jetzt ist schon vieles klarer.
Waere vielleicht auch eine Idee, so etwas mal hier bei selfhtml.org irgendwo aufzunehmen. Finde ich sehr nuetzlch. Ich interessiere mich unter anderen mit der Frage, welches Dinge man machen sollte, wenn man "gezwungen" wird, eine sehr lange Webseite bereitzustellen aber die Performance (inklusive schneller Darstellung) zu optimieren.
-
-
Hallo
kennst du Lazy Loading?
Selbst, wenn ihm der Begriff unbekannt sein sollte, die Technik selbst kennt er, wie er im Eröffnungsposting zeigt.
Aktuelle Webseiten nutzen ja dynamisches Nachladen mit Hilfe vvon Javascript.
Tschö, Auge
--
Eine Kerze stand [auf dem Abort] bereit, und der Almanach des vergangenen Jahres hing an einer Schnur. Die Herausgeber kannten ihre Leser und druckten den Almanach auf weiches, dünnes Papier.
Kleine freie Männer von Terry Pratchett -
hallo
kennst du Lazy Loading?
Andere Frage, mich wundert was für dich der entscheidende Trigger ist, ob Inhalt nicht oder doch geladen werden soll?
-
Hallo Beat,
kennst du Lazy Loading?
Andere Frage, mich wundert was für dich der entscheidende Trigger ist, ob Inhalt nicht oder doch geladen werden soll?
das wundert mich noch mehr, da ich Lazy Loading nicht einsetze 😀.
Aber, ich würde evtl. Lazy Loading einsetzen, wenn die Seite extrem umfangreich ist, also Ladezeiten im Bereich > 10 Sekunden bei schnellem Netz, und wenn die Seite sinnvoll in Blöcke zerlegt werden kann. Dann kann man die Blöcke (z.B. Bilder) erst dann laden, wenn Sie fast in den sichtbaren Bereich gescrollt wurden.
Gruß
Jürgen-
hallo
Hallo Beat,
kennst du Lazy Loading?
Andere Frage, mich wundert was für dich der entscheidende Trigger ist, ob Inhalt nicht oder doch geladen werden soll?
das wundert mich noch mehr, da ich Lazy Loading nicht einsetze 😀.
Aber, ich würde evtl. Lazy Loading einsetzen, wenn die Seite extrem umfangreich ist, also Ladezeiten im Bereich > 10 Sekunden bei schnellem Netz, und wenn die Seite sinnvoll in Blöcke zerlegt werden kann. Dann kann man die Blöcke (z.B. Bilder) erst dann laden, wenn Sie fast in den sichtbaren Bereich gescrollt wurden.
Was bedeutet Sichtbarkeit in einem Kontext, wo sichtbar keine Rolle spielt?
Ich schreibe gerade für mich an einem Dokument, um mir die Sache klar zu machen
<p>Eine Resource ist potentiel obsolet:</p> <ul> <li>Unter der Bedingung, dass es sich dabei um visuellen Inhalt handelt.</li> <li>Unter der Bedingung, dass es sich um eine alleinstehende Resource handelt und nicht etwas Ausschnitt einer Spritemap ist.</li> <li>Unter der Bedingung dass sie hochwahrscheinlich nicht im Cache vorliegt.</li> <li>Unter der Bedingung, dass sie nicht direktes Sprungziel des aktuell fokusierten Elements ist.</li> <li>Falls sie Teil eines hidden Elements ist (oder via css auf dislay:none).</li> </ul>Ich suche jetzt nach einem sicheren Hinweis für
<li>Falls das Element fern des Interesses/der unmittelbaren Interaktion des Users steht.</li>-
Ich suche jetzt nach einem sicheren Hinweis für
<li>Falls das Element fern des Interesses/der unmittelbaren Interaktion des Users steht.</li>-
hallo
Ich suche jetzt nach einem sicheren Hinweis für
<li>Falls das Element fern des Interesses/der unmittelbaren Interaktion des Users steht.</li>Da ist ein Werkzeug aber immer noch keine Beschreibung, was genau fern des Interesses/der unmittelbaren Interaktion des Users heisst.
Wir suchen nach Werkzeugen, die mehr Download einsparen, als sie erzeugen und in der Anwendung umfassender sind, als nur src Attribute umzuschreiben.
-
Hallo Beat,
… Beschreibung, was genau fern des Interesses/der unmittelbaren Interaktion des Users heisst.
ich denke, eine harte Regel gibt es da nicht. Es liegt schon in der Entescheidung des Seitenautors, ob und wann was nachgeladen wird.
Ich denke, bei Bildern ist das noch einfach, da Vorlesebrowser sowieso mit dem Alt- und/oder Title-Attribut zufrieden sind. Wie man man da an Textwüsten rangeht, weiß ich nicht. Aber ich denke, Megabytes an Text wird man selten am Stück in einer Seite vorfinden, aber Bilderserien schon.
Gruß
Jürgen-
hallo
… Beschreibung, was genau fern des Interesses/der unmittelbaren Interaktion des Users heisst.
ich denke, eine harte Regel gibt es da nicht. Es liegt schon in der Entescheidung des Seitenautors, ob und wann was nachgeladen wird.
Das ist leider nicht wahr, wenn jemand meine Themes benutzt oder das showtime.js
Mein KISS Prinzip besagt ja: mache html-Seiten schreiben so einfach / sparsam und wenn notwendig auch unabhängig wie möglich ohne Freiheiten zu entziehen.
Aber Abhängigkeiten kommen hinein.
Beispiel showtime.js.
Dort deklarierst du frames im HTML, die normal angezeigt werden. Der Frameinhalt ist, was immer du willst. Auf wunsch kannst du den frame hidden stellen. Er wird dann nur in der Showtime angezeigt.
Die Showtime selbst erzeugt clones der Frames. Technisch ist der Inhalt immer mit dem viewport grössenidentisch. Hier würde schon intersectionObserver versagen.
Wenn also ein Autor nun ein solches auf IntersectionObserver basierendes Lazy-Load verwenden wollte, macht die Showtime da doch einen Strich durch die Rechnung.
Anderseits hat die Showtime wiederum eine Möglichkeit, zu bestimmen, was ausserhalb der üblichen Reihenfolge liegt. Nur nützt es nichts dort erst ein Lazy-Load umzusetzen, da die Resourcen schon vorliegen, da diese ja ursprünglich in den Frames definiert wurden.
Jetzt kann natürlich der Autor irgend eine Lazy-Load Technik verwenden. Nur weiss mein Showtime.js davon nichts, und wenn es davon betroffen wäre, wäre das dann kontraproduktiv, weil eben IntersectionObserver erkennt, dass alle Ressourcen im fraglichen Bereich sind.
Ich denke, bei Bildern ist das noch einfach, da Vorlesebrowser sowieso mit dem Alt- und/oder Title-Attribut zufrieden sind. Wie man man da an Textwüsten rangeht, weiß ich nicht. Aber ich denke, Megabytes an Text wird man selten am Stück in einer Seite vorfinden, aber Bilderserien schon.
Nebenbei: Direkt an Menschen gerichtete Information in Attributen sollte der Vergangenheit angehören.
-
[...]
Ist mir komplett zu hoch, ich verstehe nur Bahnhof.
Jetzt kann natürlich der Autor irgend eine Lazy-Load Technik verwenden. Nur weiss mein Showtime.js davon nichts, und wenn es davon betroffen wäre, wäre das dann kontraproduktiv, weil eben IntersectionObserver erkennt, dass alle Ressourcen im fraglichen Bereich sind.
Welchen immensen Nutzen bietet mir Dein Showtime.js denn, wenn ich dafür auf IntersectionObserver verzichten soll?
-
hallo
[...]
Ist mir komplett zu hoch, ich verstehe nur Bahnhof.
Jetzt kann natürlich der Autor irgend eine Lazy-Load Technik verwenden. Nur weiss mein Showtime.js davon nichts, und wenn es davon betroffen wäre, wäre das dann kontraproduktiv, weil eben IntersectionObserver erkennt, dass alle Ressourcen im fraglichen Bereich sind.
Welchen immensen Nutzen bietet mir Dein Showtime.js denn, wenn ich dafür auf IntersectionObserver verzichten soll?
Das ist die falsche Frage. Die Korrekte Frage lautet: Wie muss ich showtime.js fixen, damit du trotzdem deine Lazy-Load-Methode (was immer die sei) anwenden kannst?
Wohl realistischer wäre die Frage, was muss ich ändern, so dass deine Frames selber kein spezielles Lazy-Load einbinden müssen.
-
Das ist die falsche Frage. Die Korrekte Frage lautet: Wie muss ich showtime.js fixen, damit du trotzdem deine Lazy-Load-Methode (was immer die sei) anwenden kannst?
Da kann ich Dir leider nicht helfen. Mir ist völlig unklar, was Dein showtime.js wie und warum tut.
Wohl realistischer wäre die Frage, was muss ich ändern, so dass deine Frames selber kein spezielles Lazy-Load einbinden müssen.
Meine Frames?! Die hast Du in den Raum geworfen, weil Dein showtime.js wohl irgendwelche krassen Sachen mit Frames macht.
-
hallo
Das ist die falsche Frage. Die Korrekte Frage lautet: Wie muss ich showtime.js fixen, damit du trotzdem deine Lazy-Load-Methode (was immer die sei) anwenden kannst?
Da kann ich Dir leider nicht helfen. Mir ist völlig unklar, was Dein showtime.js wie und warum tut.
Wohl realistischer wäre die Frage, was muss ich ändern, so dass deine Frames selber kein spezielles Lazy-Load einbinden müssen.
Meine Frames?! Die hast Du in den Raum geworfen, weil Dein showtime.js wohl irgendwelche krassen Sachen mit Frames macht.
Nö. hat nichts mit frame Elementen zu tun. Ein Frame ist ein das Äquivalen von einem Slide in einer Slideshow.
Hier eine kleine Vorstellung / Gebrauchsanweisung
-
Nö. hat nichts mit frame Elementen zu tun. Ein Frame ist ein das Äquivalen von einem Slide in einer Slideshow.
Geschickte Namenswahl dann ;-)
Hier eine kleine Vorstellung / Gebrauchsanweisung https://beat-stoecklin.ch/pub/showtime.html
OK. Dein showtime.js macht also sowas wie impress.js, ja?
Die Inhalte der Slides holst Du Dir aus dem vorhandenen Markup? Ja, dann ist ein Lazy-Loading eher doof, weil ist ja schon geloadet 😉
-
hallo
Nö. hat nichts mit frame Elementen zu tun. Ein Frame ist ein das Äquivalen von einem Slide in einer Slideshow.
Geschickte Namenswahl dann ;-)
Hier eine kleine Vorstellung / Gebrauchsanweisung https://beat-stoecklin.ch/pub/showtime.html
OK. Dein showtime.js macht also sowas wie impress.js, ja?
Die Inhalte der Slides holst Du Dir aus dem vorhandenen Markup? Ja, dann ist ein Lazy-Loading eher doof, weil ist ja schon geloadet 😉
Es ist nicht vom Tisch. ich habe kürzlich eine Site die 14MB Bildmaterial ungefragt darstellte auf maximal 500kB pro page verkürzt.
Allerdings habe ich dabei 3 statt eine solche Gallerie gemacht, was aber konzeptionell richtig war.
Ich stelle fest, dass User öfters daran denken, einfach alle Bilder in die gleiche Gallerie/page zu packen. Da hätt ich schon gerne eine Notbremse die man aktivieren kann.
-
Es ist nicht vom Tisch. ich habe kürzlich eine Site die 14MB Bildmaterial ungefragt darstellte auf maximal 500kB pro page verkürzt.
Allerdings habe ich dabei 3 statt eine solche Gallerie gemacht, was aber konzeptionell richtig war.
Ich stelle fest, dass User öfters daran denken, einfach alle Bilder in die gleiche Gallerie/page zu packen. Da hätt ich schon gerne eine Notbremse die man aktivieren kann.
Das würde ich eher als Anforderung an eine Galerie denn eine Notbremse sehen. Nenne oder löse es wie Du magst, aber Inhalte bei Bedarf nachzuladen, ist schon eine verdammt gute Idee ;-)
-
-
-
-
-
-
-
-
-
Da ist ein Werkzeug aber immer noch keine Beschreibung, was genau fern des Interesses/der unmittelbaren Interaktion des Users heisst.
Beim IntersectionObserver geht es um visuelle Überlappungen auf dem Screen des Users. Ziemlich interessante Info, wenn Du mich fragst.
Wir suchen nach Werkzeugen, die mehr Download einsparen, als sie erzeugen
Das PolyFill ist ca. 7 Kilobyte groß und kann mit zwei Zeilen JavaScript auch nur bei Bedarf nachgeladen werden.
und in der Anwendung umfassender sind, als nur src Attribute umzuschreiben.
Der IntersectionObserver schreibt nur src-Attribute um?!? WTF! Gucks Dir an. Je nach Konstellation kannst Du elegant viele MegaByte Download einsparen.
-
hallo
Da ist ein Werkzeug aber immer noch keine Beschreibung, was genau fern des Interesses/der unmittelbaren Interaktion des Users heisst.
Beim IntersectionObserver geht es um visuelle Überlappungen auf dem Screen des Users. Ziemlich interessante Info, wenn Du mich fragst.
Wir suchen nach Werkzeugen, die mehr Download einsparen, als sie erzeugen
Das PolyFill ist ca. 7 Kilobyte groß und kann mit zwei Zeilen JavaScript auch nur bei Bedarf nachgeladen werden.
und in der Anwendung umfassender sind, als nur src Attribute umzuschreiben.
Der IntersectionObserver schreibt nur src-Attribute um?!? WTF! Gucks Dir an. Je nach Konstellation kannst Du elegant viele MegaByte Download einsparen.
Die spare ich gerne anders ein, als dass der Download durch zufälliges Scrollen betätigt wird.
-
Die spare ich gerne anders ein, als dass der Download durch zufälliges Scrollen betätigt wird.
Ah, ja. Wie unterscheidest Du denn zufälliges von gewolltem Scrollen?
-
hallo
Die spare ich gerne anders ein, als dass der Download durch zufälliges Scrollen betätigt wird.
Ah, ja. Wie unterscheidest Du denn zufälliges von gewolltem Scrollen?
Gar nicht. Es gibt verschiedene Ursachen dafür, dass eine Scrollposition verändert wird oder etwas anderes eintritt, so dass eine Intersection festgestellt wird/werden könnte. Ich behaupte nicht mal, diese Ursachen alle zu kennen. Ich habe es einfach schon beobachtet oder berichtet bekommen.
-
Ah, ja. Wie unterscheidest Du denn zufälliges von gewolltem Scrollen? Gar nicht. Es gibt verschiedene Ursachen dafür, dass eine Scrollposition verändert wird oder etwas anderes eintritt, so dass eine Intersection festgestellt wird/werden könnte. Ich behaupte nicht mal, diese Ursachen alle zu kennen. Ich habe es einfach schon beobachtet oder berichtet bekommen.
Na da wäre es doch eine coole Sache, wenn der Browser dafür eine API bereitstellen würde!
-
-
-
-
-
-
-
Hej beatovich,
Was bedeutet Sichtbarkeit in einem Kontext, wo sichtbar keine Rolle spielt?
Ich schreibe gerade für mich an einem Dokument, um mir die Sache klar zu machen
Eine Resource ist potentiel obsolet:
Ich suche jetzt nach einem sicheren Hinweis für
<li>Falls das Element fern des Interesses/der unmittelbaren Interaktion des Users steht.</li><li>Unter der Bedingung, dass ausgeschlossen ist, dass ein wiederkehrender Besucher nach dieser Ressource mittels Strg-F suchen könnte…</li>Marc
-
hallo
Hej beatovich,
Was bedeutet Sichtbarkeit in einem Kontext, wo sichtbar keine Rolle spielt?
Ich schreibe gerade für mich an einem Dokument, um mir die Sache klar zu machen
Eine Resource ist potentiel obsolet:
Ich suche jetzt nach einem sicheren Hinweis für
<li>Falls das Element fern des Interesses/der unmittelbaren Interaktion des Users steht.</li><li>Unter der Bedingung, dass ausgeschlossen ist, dass ein wiederkehrender Besucher nach dieser Ressource mittels Strg-F suchen könnte…</li>Guter Punkt
-
-
-
Hej JürgenB,
Aber, ich würde evtl. Lazy Loading einsetzen, wenn die Seite extrem umfangreich ist, also Ladezeiten im Bereich > 10 Sekunden bei schnellem Netz, und wenn die Seite sinnvoll in Blöcke zerlegt werden kann.
Wenn sie sich sinnvoll zerlegen lässt, würden sich Unterseiten abieten…
Marc
-
Hallo Marc,
ich denke, bei Text ist Lazy Loading nicht das Mitrel der Wahl, eher bei Bildern,
Gruß
Jürgen
-
-
-
-
Hej JürgenB,
kennst du Lazy Loading?
Auch so eine meiner meistgehassten techniken. Statt sparsam mit Daten umzugehen werden Seiten gebaut, die man nciht durchsuchen kann, weil ein großteil "dem Nutzer zuliebe" nciht geladen wird. Von den Inhalten wohlbemerkt. Nutzloser Scheiß vom drölften Framework über Tracker bis hin zu Werbung wird natürlich geladen 👎
Marc
-
-
-