Ankündigung

Einklappen
Keine Ankündigung bisher.

best practice bei einbindung von JS / CSS files

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #16
    Yahoo löst es so das sie einen Request absenden und dabei angeben welche css Files geladen werden sollen.

    Man könnte es also so machen:

    /css.php?css/blub.css&jquery/jquery.min.css&jquery/jquery.ui.css&custome.css

    nachdem du die CSS Files zusammengebaut hast kannst du sie natürlich entsprechend Cachen dann sollte das denke ich keine Probleme geben.

    Gilt natürlich auch für JS.

    Kommentar


    • #17
      Zitat von cycap Beitrag anzeigen
      Darum nun meine Frage hier nach euren bewährten Vorgehensweisen.
      prinzipiell: ich fasse alle benötigten css-dateien serverseitig on the fly zusammen; die "virtuelle" ausgabe-datei ist komprimiert (whitespaces). die betreffenden einzelnen css-dateien werden im kopf der haupt-datei (verlinkung im html-quellcode) statisch notiert.

      speziell: einzelne bereiche der website (bspw. kunden- oder admin-bereich) binden zusätzliche haupt-dateien ein. darüber hinaus kann ich dem serverseitigen skript params zur steuerung der einbindung mitgeben.

      ich habe also nur einen requests pro haupt-dateien und dennoch (viele) einzelne / spezialiserte css-dateien. browser-seitig wird das ganze natürlich gecached.

      cx

      nachtrag: ich würde nicht zu stark nach benötigten modulen / views unterscheiden; man sollte schon die effizienz (einsparung einiger kb vs. komplizierte steuerung der css-einbindung) im auge behalten.

      keep it simple, stupid .-)

      cx

      Kommentar


      • #18
        Hast du wirklich so häufig wechselne Projekte, dass du dafür ein Softwarekonzept brauchst?

        Reicht es nicht, bei der Fertigstellung des Projektes deine vier, fünf CSS-Dateien zu kompressieren und zusammenzufassen?

        Bei JS bzw jQuery mach ich es so, dass ich jquery extern von Google laden lasse, Scripts lokal und meine eigenen jQuery-Zeilen ohne externe Datei direkt einbinde.

        Kommentar


        • #19
          Bei JS bzw jQuery mach ich es so, dass ich jquery extern von Google laden lasse, Scripts lokal und meine eigenen jQuery-Zeilen ohne externe Datei direkt einbinde.
          Ist für Testing- und Entwicklungszwecke ganz gut, aber für Produktivumgebungen finde ich das ganz schlecht. Dazu muss ein Extra-Request zu einem fremden Server getätigt werden, den man sich evtl. sparen könnte und vom Datenschutz will ich gar nicht erst anfangen. Ich hasse es, wenn zentrale Teile der Seite von Drittanbietern geladen werden. So einen schrecklichen Facebook-Button kann man ja noch blocken. Wenn du dann die Google-API aber auch noch blockst, dann funktioniert die Seite u.U. nicht mehr (richtig).
          Refining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”

          Kommentar


          • #20
            Wo bindest du denn deine JavaScript-Dateien ein, im Head-Bereich oder am Ende der Seite? Das könnte eine Erklärung für die lange Rendering-Zeit sein.
            Also ich hab jetzt nochmal einen Test gemacht mit der ext-all.js am Ende der HTML-Datei, das verzögert in meinem FF laut Firebug das onLoad-Event um rund 400ms. Ohne das irgendwas durch mich von dem JS-Code ausgeführt wird. Kann das jemand bestätigen oder hat vielleicht jemand eine Idee wie das zu umgehen ist?

            Kommentar


            • #21
              Bestätigen kann ich es, habe es gerade mal getestet.
              Wenn ich das richtig sehe, nutzt ExtJs eine anonyme Funktion zum Laden der Klassen/Funktionen, die muss der Browser natürlich erstmal ausführen, das kostet Zeit (wird ohne anonyme Funktion aber wohl genauso viel Zeit kosten).

              So oder so analysiert der Browser ja deine Dateien und führt sie aus. Er kann ja schließlich nicht wissen, dass es nicht nur um ein Framework handelt das so selbst noch gar nicht benötigt wird.
              Bei einer Datei dieser Größe (immerhin stolze 697 KB) wirst du um eine Verzögerung wohl nicht herumkommen.

              Je nachdem, wofür du die Datei brauchst, wäre es noch eine Überlegung die Datei nachträglich zu laden. Steve Souders schreibt in Kapitel 3 "Splitting the Initial Payload" seines Buches "Even Faster Web Sites" etwas darüber.

              Geht im Grunde darum, dass du nur das zum Rendern der Seite benötigte JavaScript direkt lädst und den Rest per "post-onload download" nachlädst.
              Programming PHP

              Kommentar


              • #22
                Ist für Testing- und Entwicklungszwecke ganz gut, aber für Produktivumgebungen finde ich das ganz schlecht. Dazu muss ein Extra-Request zu einem fremden Server getätigt werden, den man sich evtl. sparen könnte
                So doof ist das gar nicht. Stichwort Content Distribution Network. Gerade die JS-Frameworks werden diese Server vermutlich noch schneller ausliefern, weil deren Serverinfrastruktur besser ist. Geschwindigkeitsoptimierung für Websites empfiehlt desweiteren, mehrere Domains zu benutzen, um die Anzahl gleichzeitig ladender Komponenten zu erhöhen.

                Datenschutz - klar; wenn allerdings ohnehin Google-Tracking aka Analytics oder Webmastertools verwendet wird, ist das sowieso egal. jQuery findet man sicher auch noch auf anderen großen Seiten.

                http://www.drweb.de/magazin/jquery-g...ode-einbinden/
                [COLOR="#F5F5FF"]--[/COLOR]
                [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                [COLOR="#F5F5FF"]
                --[/COLOR]

                Kommentar


                • #23
                  @[-UFO-]Melkor hast du es mit oder ohne geöffnetem Firebug (o.ä.) getestet? Siehe http://www.php.de/off-topic-diskussi...alysieren.html

                  Kommentar


                  • #24
                    Das Problem ist folgendes. Wenn JS Dateien im Head eingebunden werden wird alles was danach geladen wird solange geblockt bis alle JS Dateien fertig sind. Hat man also sehr sehr große JS Dateien und viele Bilder auf der Seite kann es etwas dauern bis er anfängt die Bilder zu laden..

                    Werden die JS Dateien allerdings im am Ende des Bodys geladen werden erst die Bildern geladen und dann das JS,

                    Kommentar


                    • #25
                      Zitat von stayInside Beitrag anzeigen
                      Das Problem ist folgendes. Wenn JS Dateien im Head eingebunden werden wird alles was danach geladen wird solange geblockt bis alle JS Dateien fertig sind. Hat man also sehr sehr große JS Dateien und viele Bilder auf der Seite kann es etwas dauern bis er anfängt die Bilder zu laden..

                      Werden die JS Dateien allerdings im am Ende des Bodys geladen werden erst die Bildern geladen und dann das JS,
                      Trotz alle dem wird die Seite aber vom Browser erst freigegeben (onLoad-Event) wenn alles geladen UND (der springende Punkt) verarbeitet wurde. Und bei Einbindung des ExtJs-Frameworks verzöger sich dieses (zumindest mit geöffnetem Firebug sehr deutlich).

                      Kommentar


                      • #26
                        Wobei du noch zwischen onload und Document-Ready unterscheiden musst. Letzteres wird schon geworfen, wenn das DOM fertig aufgebaut ist. Der Ladebalken des Browser verschwindet aber natürlich erst bei onload.
                        Refining Linux: “[url=http://www.refining-linux.org/archives/65/Performing-push-backups-Part-1-rdiff-backup/]Performing Push Backups – Part 1: rdiff-backup[/url]”

                        Kommentar


                        • #27
                          Dateien auf von fremden Servern laden hat sogar noch mehr Vorteile, wird Beispielsweise jQuery von Google geladen, dann ist die Wahrscheinlichkeit das der Benutzer davor auf einer Webseite war und ebenfalls dort von Google jQuery eingebunden war sehr hoch. Heißt, jQuery muss überhaupt nicht mehr geladen werden weil die Google Version schon im Cache des Benutzer ist, obwohl er noch nie auf deiner Webseite war.

                          Wenn man selbst ein paar Server nutzt bzw. verschiedene Subdomains dann muss man allerdings aufpassen. Die geladene Datei muss nämlich immer vom selben Server/Sudomain geladen werden sonst hat man am Ende das ganze eher verschlimmert weil der User eine Version von jeder Domain in den Cache laden muss.

                          Kommentar


                          • #28
                            Die Idee JS und CSS dynamisch je nach angeforderter Funktion zu verarbeiten hatte ich auch mal. Davon bin ich aber wieder abgekommen. Das Caching wird dann viel zu fummelig. Besser ist es IMHO für jedes Projekt zu validieren was benötigt wird und was nicht und dann eben selektiv die JS Dateien erstellen.

                            Je größer die JS Files werden desto langsamer wird Firefox. Ich hatte auch tatsächlich schon einen Fall, da war der IE schneller im JS verarbeiten als der FF. Wobei ich nicht ausschließen möchte, dass das an der Kombination FF3 und Mootools 1.2 lag.

                            Mootool Core hole ich aktuell auch von Google. Selber hosten sollte man bei Intranet-Seiten oder wenn man dem Kunden auch mal offline was vorführen möchte

                            Kommentar

                            Lädt...
                            X