HowTo: Gelöscht

[supervisior]

Gelöscht

[Hanzo2012]

Welche Auswirkungen hat das auf die Google Bildersuche? Ich könnte mir vorstellen, dass Bilder dann nicht mehr richtig indexiert werden.

[elmex]

Kleiner Tipp, anstat alle Bilder zu parsen, nur die, welche auch data-src gesetzt haben parsen:

Code: Alles auswählen

var b = document.querySelectorAll("img[data-src]");

[supervisior]

Welche Auswirkungen hat das auf die Google Bildersuche? Ich könnte mir vorstellen, dass Bilder dann nicht mehr richtig indexiert werden.

Google kann Javascript. Von daher gäbe es keine Einschränkungen und kann auch garantieren, dass das in Bezug auf Google keine negativen Auswirkungen hat. Aktiviertes js wäre aber unabängig davon notwendig.

[supervisior]

Kleiner Tipp, anstat alle Bilder zu parsen, nur die, welche auch data-src gesetzt haben parsen:

Code: Alles auswählen

var b = document.querySelectorAll("img[data-src]");

Wenn ein Bild kein data-src hat, passiert ohnehin nix, sprich Bild wird wie gewohnt geladen und angezeigt.

[staticweb]

> Welche Auswirkungen hat das auf die Google Bildersuche? Ich könnte mir vorstellen, dass Bilder dann nicht mehr richtig indexiert werden.

Der Google Bot benutzt den web rendering service aus Chrome 41. Der ist ES5 kompatibel und sollte mit diesem Code keine Probleme haben.

Solange sich die Bildanzahl noch im 3-stelligen Bereich hält sollte es auch keine zeitlichen Probleme geben.

> Kleiner Tipp, anstat alle Bilder zu parsen, nur die, welche auch data-src gesetzt haben parsen: var b = document.querySelectorAll("img[data-src]");

Bei dieser Methode kann es zu Performance-Problemen kommen, da die Attribut-Suche zeitaufwendiger ist. Jedenfalls bei größeren Dokumenten.

Dann wäre es besser wenn eine eindeutige Klasse vergeben und nach der gesucht wird.

[supervisior]

Bei dieser Methode kann es zu Performance-Problemen kommen, da die Attribut-Suche zeitaufwendiger ist. Jedenfalls bei größeren Dokumenten.

Dann wäre es besser wenn eine eindeutige Klasse vergeben und nach der gesucht wird.

Einspruch! Ich habe mehr als 2 Millionen Bilder auf 250.000 Seiten verteilt. Von Performance Problemen kann absolut nicht die Rede sein, wobei ich noch nicht mal einen Managed oder Root Server betreibe. Wenn Du was kommentieren oder gar zu kritisieren hast, dann baue Deine Kritik bitte nicht auf theoretischen Phantasien auf. Ansonsten landet das hier wieder bei der Diskussion bei Du einmal mehr den Schwanz einziehst.

[staticweb]

> Von Performance Problemen kann absolut nicht die Rede sein, wobei ich noch nicht mal einen Managed oder Root Server betreibe.

Dein Problem ist, dass du erst schreibst und dann liest und über den Inhalt nachdenkst.

> Wenn Du was kommentieren oder gar zu kritisieren hast, dann baue Deine Kritik bitte nicht auf theoretischen Phantasien auf.

Dann lese mal nach wo in der Praxis (!) die Unterschiede zwischen getElementsByTagName() und querySelectorAll() liegen.

> Ansonsten landet das hier wieder bei der Diskussion bei Du einmal mehr den Schwanz einziehst.

Zu einer Diskussion gehören mindestens 2 Personen und ich muss dir leider mitteilen, dass ich dafür nicht zur Verfügung stehe.

Das kann sich wieder ändern wenn du dich an reale Fakten hältst und nicht nur deine Meinung durchzusetzen versuchst.

[supervisior]

Wusst' ichs doch, dass Du es vorziehst den Schwanz einzuziehen!

[Hanzo2012]

@supervisior: Was hat JavaScript-Performance mit einem Managed- oder Root-Server zu tun?

[supervisior]

@supervisior: Was hat JavaScript-Performance mit einem Managed- oder Root-Server zu tun?

Nichts! War nur eine Randbemerkung.

[nerd]

Sorry, aber ich verstehe nicht ganz was dieser code bezwecken soll..?

So wie ich das lese geht der code alle bilder durch, laedt die bilder per javascript und setzt sie inline als base64 bild ein. Der code wird mit window.onload so zeitig wie moeglich ausgefuehrt, also auch bevor die seite komplett geladen ist - soweit richtig?

Allerdings heisst das ja nichts anderes, als dass du die parallelen downloads die zu dem zeitpunkt auftreten neu aufteils, indem du die bilder eben (erneut, weil noch vom <img src> schon im download queue?) per javascript anforders. Damit reduzierst du aber keine bandbreite da die bilder ja so oder so irgendwie vom server in den browser kommen muessen. Ob das durch parsen des html codes oder ajax request via javascript passiert ist dabei voellig egal.
Die anzahl an files, die der browser gleichzeitig vom server laedt ist begrenzt, und wenn der download-queue voll ist kommen weitere requests in die warteschlange bis ein download fertig ist.
Wenn du die bilder mit diesem code im queue nach vorne mogelst, dann heisst das ja nur das irgendwas anderes (css? fonts? externe scripte?) im gegenzug spaeter geladen wird.

Mir ist nicht ganz klar wo hierbei der gewinn sein soll, oder welches problem du damit loest?

Edit:
was vielleicht sinn macht ist, die bilder die beim pageload ausserhalb des viewports liegen erstmal zu verzoegern und nur das zu laden was tatsaechlich innerhalb des viewports liegt. Bei jQuery ist das relativ einfach mit dem :visible selector, mit vanilla js ist es etwas komplizierter.

[Hanzo2012]

@nerd:
Da hast du was übersehen. Die Bilder werden anfangs nicht geladen. Da steht nicht src=..., sondern data-src=...

Cool wäre es, wenn das Base64-kodierte Bild eine niedrig aufgelöste Version des echten Bildes wäre. Kann sein, dass ModPagespeed sowas kann.

Noch ein Tipp, um nicht das window-Objekt mit globalen Variablen zu „verschmutzen“:
window.onload = function() { ... }
statt
function init() { ... } window.onload = init;

Und noch besser, um mehrere Event-Handler zu ermöglichen (falls schon jemand anderes auf onload wartet):
window.addEventListener('load', function() { ... });

[supervisior]

@nerd

Im Grunde genommen hast Du es verstanden, aber dann doch wieder nicht. Die Antwort auf das, was Du nicht verstehst, steht eigentlich in meiner Einleitung, will das aber nochmal auf einfache Weise erläutern.

Beim Aufruf einer Internet Seite gibt es keine Priorität, was an den Inhalten wann geladen wird. Der Browser versucht einfach so viel wie möglich gleichzeitig zu laden, wobei es nicht nur um das Laden von Inhalten geht, sodern auch um das Rendern von css und js. Gewissermaßen und im übertragenen Sinne stopft sich der Browser so viel wie möglich ins Maul, verschluckt sich aber dabei alles, was er im Maul hat, zu kauen und zu schlucken. Der "Essvorgang" = Ladeverhalten einer Seite wird dadurch verlangsamt. Beim Laden einer Seite blockiert im Grunde genommen das Eine das Andere

Bringt man jetzt den Viewport, bzw. das "Above the fold" und das Nutzerverhalten ins Spiel, führt dieses verlangsamte Ladeverhalten zu vorzeitigen Absprüngen noch bevor die Seite eigentlich geladen ist. Man weiß inzwischen, dass dieses typische Ladeverhalten dazu beiträgt, dass die Absprungraten noch vor dem vollständigen Laden einer Seite eine nicht unwichtige Rolle spielt. Deswegen pocht Google schon seit längerem auf das Einhalten des "Above the fold".

Um nun das Essverhalten = Ladeverhalten zu ändern, müssen wir dem Browser andere Essgewohnheiten aufzwängen und verändern das Timing, was wann geladen wird. Im Allgemeinen spricht man dabei vom "defer"-en, also dem hinten anstellen von dem, was weniger Priorität hat und begünstigen damit das"Above the fold" Ziel. Der Code Schnipsel übernimmt nun den Part was die Bilder anbetrifft, was im Grunde genommen wie folgt abläuft:

Beim Parsen der Seite geben wir dem Browser mit dem base 64 image ein Fake Bild. Das blockiert nicht beim Laden und der Browser bekommt, was er beim img Tag erwartet. Das data-src ignoriert er, weil er damit gemäß html Spezifikation nix anfangen kann. Anders als Du es annimmst, feuert die onload Anweisung erst, wenn alles HTML und andere Ressourcen geladen sind. Erst wenn alles geladen ist, wird auch die Funktion aus dem Schnipsel ausgeführt und diese Funktion macht im Grunde genommen nichts anders als das Fake Bild mit dem data-src zu ersetzen. Im generierten HTML Code, also nach Ausführen der Funktion steht dann auch das korrekte Bild im Source für das Bild.

Das für sich alleingestellt führt zu einem Besänftigung des Pagespeed Gottes, aber der will ja auch, dass das "Above the fold" Ziel eingehalten wird und dann soll auch noch der Nutzer bedient werden. Deswegen sollte man den Code Schnipsel nicht pauschal auf alle Bilder richten, sondern nur auf die Bilder nach dem Fold. Hat beispielsweise eine Seite im Above the fold ein Hauptbild und nach dem Fold noch weitere, bekommen nur die nach dem Fold stehenden Bilder das Fake Bild, bzw. den data-src Zusatz.

Ohne jetzt noch mehr zu zerreden, probiert es einfach aus und lasst mal den Pagespeed Test drüberlaufen. Erfolg ist garantiert.

[supervisior]

Vielleicht noch eine nicht unwichtige Anmerkung speziell zu diesem Thema und zum Optimieren im Allgemeinen. Man darf den hier beschriebenen Optimierungstipp nicht standalone betrachten. Durch das "Defer"-en von Inhalten, die weniger wichtig sind, reduziert sich unweigerlich die Zahl der gleichzeitigen Requests an den Server. Je nach Art des Servers und dessen verfügbare Performance kommt es zu einer Entlastung des Servers, eben weil er nicht mehr so viel gleichzeitig abarbeiten muss und das führt in Folge dessen zu der ebenso wichtigen Reduzierung der "Server Response Time, die der Pagespeed Gott ebenso gern gering hätte.

Man muss also nicht sofort auf einen leistungsstärkeren Server wechseln, sondern einfach nur mal die bekannten Methoden anwenden, wenngleich nicht alle so einfach umzusetzen sind, wie die hier beschriebene Methode.