Herzlich willkommen im SEO Forum der ABAKUS Internet Marketing GmbH
registrieren registriertes Mitglied
Darum habe ich ja auch gesagt: eine niedrig aufgelöste Version des echten Bildes. (quasi ein Thumbnail)staticweb hat geschrieben:> 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.
Die Datenmenge wäre zu groß um die Bilder mit Base64 zu kodieren.
Ich weiß grad nicht, was das bringen soll? Mit einem zusätzlichen Bild in niedriger Auflösung anstelle des Fake Bildes wird die zu ladende Datenmenge ja deutlich erhöht und erfüllt nicht den Zweck des hinten anstellen von zu ladenden Inhalten. Darum und nur darum geht es.Hanzo2012 hat geschrieben:Darum habe ich ja auch gesagt: eine niedrig aufgelöste Version des echten Bildes. (quasi ein Thumbnail)staticweb hat geschrieben:> 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.
Die Datenmenge wäre zu groß um die Bilder mit Base64 zu kodieren.
Damit der Benutzer schonmal ein kleines Vorschaubild sieht, bevor das echte Bild geladen wird. Du musst bedenken, dass es relativ lange dauern könnte, bis das onload-Event aufgerufen wird. Wenn z. B. irgendeine externe Ressource (JS, Facebook-Button etc.) zu lange braucht, sieht der Benutzer möglicherweise für ziemlich lange Zeit nur schwarze Rechtecke statt Bilder. Da das Vorschaubild direkt im HTML integriert ist, werden keine neuen Verbindungen zum Server geöffnet. Alternativ könnte man auch eine kleine Lade-Animation als Platzhalter nutzen, damit der Benutzer weiß, dass da noch was kommt. Wenn du gzip-Komprimierung aktivierst, werden die wiederholten Base64-URLs sehr gut komprimiert.supervisior hat geschrieben:Ich weiß grad nicht, was das bringen soll? Mit einem zusätzlichen Bild in niedriger Auflösung anstelle des Fake Bildes wird die zu ladende Datenmenge ja deutlich erhöht und erfüllt nicht den Zweck des hinten anstellen von zu ladenden Inhalten. Darum und nur darum geht es.
Ich habe nicht gesagt, dass der Tipp "obsolet" ist. Sondern dass man window.onload = ... nicht nutzen sollte, weil das eben nur einer tun kann. Wie es besser geht, habe ich ja auch direkt gesagt, nämlich mit window.addEventListener. Damit kannst du so viele Event-Handler anhängen wie du lustig bist, ohne dass sie sich gegenseitig stören. Das war nur ein Verbesserungsvorschlag im Detail.supervisior hat geschrieben:Und natürlich wird der mögliche Aspekt, dass womöglich mehrere Eventhandler im Einsatz sein können, nicht berücksichtig. Wie auch und ist auch nicht die absolute Regel, dass es generell so ist. Im Falle dessen packt man eben alles in 1 Funktion und gut ist. Deswegen wird der hier beschriebene Tipp nicht obsolet.
Wir reden hier doch nicht über Minuten oder Stunden für das Laden von Seiten. Die onload Anweisung feuert unmittelbar nachdem der ganze HTML Kram nebst sonstigen Sourcen geladen ist, wobei das Rendern davon ausgenommen ist. Wenn dann auch noch das Laden von js Files nach der gleichen defered Methode geladen wird und zudem die Bilder vom Laden zunächst ausgeschlossen ist, reduziert sich die Ladezeit des verbleibenden enorm. Das Abarbeiten der onload Funktion fällt dann fast nicht mehr ins Gewicht.Hanzo2012 hat geschrieben: Damit der Benutzer schonmal ein kleines Vorschaubild sieht. Du musst bedenken, dass es relativ lange dauern könnte, bis das onload-Event aufgerufen wird. Da das Vorschaubild direkt im HTML integriert ist, werden keine neuen Verbindungen zum Server geöffnet.
Doch, es gibt eine prioritaet: es wird in der reihenfolge geladen wie es im quelltext auftaucht. Deswegen wird ja auch empfolen die CSS dateien oben im header einzutragen, damit die styles moeglichst angewendet werden koennen sobald das dokument fertig geladen ist - ansonsten gibt es den effekt das sich elemente nochmal verschieben oder sich die groesse aendert wenn man styles laedt nachdem der dom schon fertig gerendert ist.supervisior hat geschrieben: 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. [...] Beim Laden einer Seite blockiert im Grunde genommen das Eine das Andere
Ist aber bei meinen seiten unpraktisch, da ich pro sitzung relativ viele impressions bekomme. Daher alles in einer einzigen css, die dann nur einmal geladen und im browser gecacht wird.supervisior hat geschrieben:Anstelle css Anweisungen in eine css Datei zu packen, definiert man zumindest den Bereich above the fold im Datei Header und lässt den Rest defered laden. Machbar und praktiziere ich auch und Du glaubst nicht wie sich der Pagespeed freut.
Nur zu Deiner Info HTTP/2 ist seit Jahren State of the art und wird seit mind. 5 Jahren von allen Browsern unterstützt, bzw. von Webservern zur Verfügung gestellt. Der einzige Browser, der kein HTTP/2 kann, ist der IE11 abwärts und auch nur in Kombination mit Windows 7 abwärts. Hinzukommem noch die Bots (Googlebot eingeschlossen) und die Crawler, die sich als User ausgeben. Die von Dir genannten Beschränkungen bzw. der max. Speichermenge im Header kann man inzwischen vernachlässigen.staticweb hat geschrieben:> Ist aber bei meinen seiten unpraktisch, da ich pro sitzung relativ viele impressions bekomme.
Ja, die above the fold Optimierung ist etwas aufwendig. Da muss man abwägen ob sich der Augwand lohnt.
> Daher alles in einer einzigen css, die dann nur einmal geladen und im browser gecacht wird.
Auch hier sollte die 14KB Schwelle eingehalten werden oder du nutzt HTTP/2. Auf alle Fälle sollte
das CSS fast ganz oben im <head> eingebunden werden.
Wenn ich grad mal nix zu tun habe, suche ich nach Deinen Beiträgen und welchen Schmarrn Du wieder verzapfst....staticweb hat geschrieben:Ich weiß jetzt nicht warum du den alten Beitrag herausgesucht hast...
Falsch! Wie heißt der Titel dieses Threads?staticweb hat geschrieben:...aber es ging hier nicht um Browser, sondern um die eingesetzten Webserver.