Enrico: Vorladen: "window.location.replace" oder "window.location.href"?

Hallo,

ich habe mal eine grundsätzliche Frage zu den Auswirkungen, ob man "window.location.replace" oder "window.location.href" verwendet.

Genauer:

Ich lade mittels php Grafiken vor, indem ich das Verzeichnis "Grafiken" rekursiv durchlaufe und aus den gefundenen Grafiken html-konforme Anweisungen in einen versteckten div-Bereich schreiben lasse.

Wenn die Seite, die meine Grafiken vorlädt, fertig ist, dann soll eine Weiterleitung auf die eigentliche Homepage erfolgen.

Und hierauf zielt meine Frage ab:

Dass der Browser-Cache mit "window.location.replace" überschrieben wird bzw. genauer genommen das history-Objekt, weiß ich, sind davon dann aber auch die vorgeladenen Grafiken betroffen oder wäre es sinnvoller, hier "window.location.href" zu verwenden oder spielt es womöglich gar keine Rolle, welche Methode ich hernehme?

Danke und Gruß
Enrico

  1. Hi,

    Ich lade mittels php Grafiken vor, ...

    wohl kaum. Wenn überhaupt, dann entweder mit HTML oder mit Javascript.

    indem ich das Verzeichnis "Grafiken" rekursiv durchlaufe und aus den gefundenen Grafiken html-konforme Anweisungen in einen versteckten div-Bereich schreiben lasse.
    Wenn die Seite, die meine Grafiken vorlädt, fertig ist, dann soll eine Weiterleitung auf die eigentliche Homepage erfolgen.

    Das heißt, der Besucher starrt erstmal ein paar Sekunden grundlos auf eine leere Seite, bis die Grafiken einmal geladen sind? Keine gute Idee.

    Dass der Browser-Cache mit "window.location.replace" überschrieben wird bzw. genauer genommen das history-Objekt, weiß ich, sind davon dann aber auch die vorgeladenen Grafiken betroffen

    Wieso sollten sie? Für die wurde doch gar kein history-Eintrag erzeugt, also sind sie von solchen Kapriolen überhaupt nicht betroffen.

    oder wäre es sinnvoller, hier "window.location.href" zu verwenden oder spielt es womöglich gar keine Rolle, welche Methode ich hernehme?

    Der einzige Unterschied ist der, dass bei Verwendung von location.href deine sinnlose Preload-Seite in der Browser-History bleibt und mit "Zurück" erneut aufgerufen werden kann.

    Und was das Vorladen von Bildern angeht: Tu deinen Besuchern einen Gefallen und lass es bleiben. Es ist viel angenehmer, wenn man quasi sofort wenigstens den Textinhalt der Seite sieht. Damit die Blöcke des Layouts dabei nicht springen, während die Bilder eintrudeln, sollte man deren Abmessungen im Markup vermerken. So reserviert der Browser gleich beim ersten Anzeigen den nötigen Platz und klatscht das Bild dann einfach nur an die reservierte Stelle, sobald es verfügbar ist.

    So long,
     Martin

    --
    "Hier steht, deutsche Wissenschaftler hätten es im Experiment geschafft, die Lichtgeschwindigkeit auf wenige Zentimeter pro Sekunde zu verringern." - "Toll. Steht da auch, wie sie es gemacht haben?" - "Sie haben den Lichtstrahl durch eine Behörde geleitet."
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    1. Hallo Martin,

      danke für Deine Antwort und konstruktive Kritik, die mich meine Lade-Reihenfolge überdenken lässt (*ernst-gemeint*).

      Gruß
      Enrico

      1. Moin!

        danke für Deine Antwort und konstruktive Kritik, die mich meine Lade-Reihenfolge überdenken lässt (*ernst-gemeint*).

        Was die Lade-Reihenfolge angeht, so gibt es mittlerweile relativ klare Ideen, wie man eine Seite optimal aufzubauen hat, damit alle Browser die bestmögliche und insbesondere schnellstmögliche Darstellung hinkriegen können:

        1. Nur ein CSS-Stylesheet laden, und zwar so früh wie es geht, also möglichst weit oben im <head>. Je schneller das CSS bekannt ist, desto schneller kann die korrekte Formatierung vorgenommen werden.
        2. Bilder, wenn möglich, von mehr als einem Hostnamen, also nicht von "www.example.org", sondern von "pic1.example.org", "pic2.example.org" und "pic3.example.org". Browser laden nicht beliebig viele Bilder parallel von einem Hostnamen, mehrere Hostnamen erhöhen die Parallelität.
        3. Javascript möglichst am Ende der Seite, direkt vor </body>; document.write() vermeiden. Javascript sollte immer so hinzugefügt werden, dass sein Fehlen die Seite nicht kaputt macht. Das bedeutet automatisch, dass alles, was auch per Javascript ausgelöst werden kann, erst "onload" zum HTML hinzugefügt wird, und das geschieht sowieso erst, wenn alle Ressourcen geladen wurden. Wenn Javascript direkt zum Anfang geladen wird, können stattdessen Bilder oder CSS nicht geladen werden - das stört den optischen Aufbau der Seite.

        - Sven Rautenberg

        1. Hallo Sven,

          besten Dank für Deine Tips :-)

          Habe mir Deine Antwort rauskopiert und abgespeichert, um Deine Tips dann Schritt für Schritt umzusetzen :-)

          Gruß
          Enrico

          1. Moin!

            Hallo Sven,

            besten Dank für Deine Tips :-)

            Habe mir Deine Antwort rauskopiert und abgespeichert, um Deine Tips dann Schritt für Schritt umzusetzen :-)

            Das ist alles keine Hexenkunst. Und am besten: Für Firefox gibts das YSlow-Plugin, damit kann man solche Analysen für seine eigene Seite machen und auch gleich direkt die Verbesserungsvorschläge sehen.

            Wobei dabei zu beachten ist, dass man manche Tipps auch einstellbar gestalten kann, sprich die Analyse geht von einstellbaren Voraussetzungen aus, und die Tipps am Ende verändern sich dann entsprechend. YSlow bietet, wenn ich es richtig erinnere, Analysen für kleine, mittlere und große Websites, bzw. unterschiedliche Aspekte, die von diesen technisch geleistet werden können. Beispielsweise haben große Sites in der Regel ein Content-Delivery-Network (CDN), bzw. sollten es haben. Bei kleinen Sites macht das weniger Sinn.

            Die resultierenden Tipps sollte man also nochmal einer eigenständigen Sinnprüfung unterziehen und ggf. die Analyse anpassen.

            - Sven Rautenberg