Hier im Forum bekommt ihr bei euren fragen schnelle hilfe.Hier geht es rund um das Web SeitenProgrammieren.Alles rund ums Javascript,Html,Php,Css und Sql.Auf fast allen Fragen haben wir eine Antwort.
Der Soforthilfe-chat verspricht das ,was sein Name sagt. Hier sind Leute Online die sofort ihre hilfe anbieten.Seht in der OnlineListe nach und wenn einer Online ist werdet ihr auch antwort bekommen. Admine ,Moderatoren und Helfer sind unsere Spezialisten in Sachen Web Programierung

Sie sind hier : sebastian1012.bplaced.net/ homepage-neu / kreuz-und-quer / tutorials-info-neuigkeiten-html / index.php

Random Html Themen, Tutorials und co

24.09.2019 21:39:04

Wie erstelle ich eine HTML-Liste aus einem Nested-Set?

Einer der meistgelesenen Beiträge in diesem Blog ist der über Nested Sets. Es bringt natürlich nichts, wenn man damit performante Abfragen realisieren kann aber anschließend das Ergebnis nicht in entsprechenden HTML-Code umwandeln kann, um daraus eine Navigationsliste oder ähnliches zu erstellen. Da laut einiger Kommentare genau dort das Problem liegt, möchte ich in diesem Beitrag beschreiben, wie man ein Nested Set in eine Unordered List umwandeln kann.

Zuerst nochmal unser Ausgangspunkt: Wir haben eine Tabelle kategorien mit 4 Spalten: ID, name, lft, rgt
Dort sind einige Kategorien untergebracht, genau wie im Nested Set-Beitrag erklärt: Der lft-Wert einer übergeordneten Kategorie ist kleiner als alle lft-Werte Ihrer Kind-Kategorien und der rgt-Wert der übergeordneten Kategorie ist größer als alle rgt- (und auch lft-) Werte. Dadurch entstehen Umarmungen und Abfragen aller Kindelemente einer bestimmten Kategorie sind problemlos möglich.
Aber ich möchte hier nicht nochmal das gesamte Modell erklären, das steht ja ausführlich im Nested-Set-Beitrag.

Nun möchten wir sämtliche Kategorien samt Ihrer Untermenüs hierarchisch anzeigen – in einer Unordered List, die für jede hierarchisch untergeordnete Ebene weitere ULs einbaut. Das geht nur rekursiv.
Falls sich jemand fragt, was nun eigentlich gewonnen ist, wenn wir die rekursiven Abfragen, wie Sie „normalerweise“ bei Baumstrukturen in MySQL gemacht werden, wiederum durch etwas Rekursives ersetzen. Nun, die Variante mit parentID erfordert sehr viele MySQL-Abfragen. Ständig muss in einer Schleife bzw. rekursiv durch PHP die DB abgefragt werden, ob diese oder jene Kategorie Kindelemente hat. Das schlaucht den DB-Server unnötig (jede Anfrage hat noch Overhead). Deshalb ist es immer ratsam SQL-Abfragen aus Schleifen rauszuholen und möglichst durch eine einzige Abfrage zu ersetzen (falls dies möglich ist).

Wenn wir nun die rekursive Funktion allein nutzen, um aus dem fertigen Ergebnis eine Liste zusammen zu bauen, bleibt alles im Rahmen von PHP – es muss kein anderes System mehr nach Informationen befragt werden und das bringt den Geschwindigkeitsschub.

Jedenfalls möchten wir nun die Liste darstellen, dazu sind mehrere Funktionen nötig – zuerst unsere Hauptfunktion, die das Result Set holt und das Array erstellt, mit dem wir fortan arbeiten:

  function getMenu() {       $query = "SELECT lft,rgt FROM kategorien";       $einlesen = mysql_query($query);       $lft = array();       $rgt = array();       while($einzeln = mysql_fetch_assoc($einlesen)) {         $lft[] = $einzeln['lft'];         $rgt[] = $einzeln['rgt'];       }       $query = "SELECT n.ID,n.name, COUNT( * ) -1 AS level FROM kategorien AS n, kategorien AS p WHERE n.lft BETWEEN p.lft AND p.rgt AND (";       for($i=0;$i<count($lft);$i++) {         $query .= "(n.lft<=".$lft[$i]." AND n.rgt>=".$rgt[$i].")";         if($i<count($lft)-1) $query .= " OR ";       }       $query .= ") GROUP BY n.lft";       $einlesen = mysql_query($query);             $menu = array();       while($einzeln = mysql_fetch_assoc($einlesen)) {         $menu[] = array($einzeln['ID'],$einzeln['name'],$einzeln['level']);       }       return buildMenu($menu);   }

Diese Funktion selektiert alle Kategorien und speichert die Datensätze im Array $menu ab. Die erste Abfrage nach allen lft- und rgt-Werten wird erst sinnvoll, wenn nur bestimmte Zweige eingelesen werden sollen. Der Einfachheit halber habe ich das hier weggelassen. Würde bedeuten einfach einen Parameter der Funktion getMenu() zu übergeben und diesen dann in diese Query einfließen zu lassen.

Der Rückgabewert der Funktion erfordert den Aufruf der Funktion, die das Result Set in HTML konvertieren soll:

  function buildMenu($subMenu) {     $menu = "";     $cnt_subMenu = count($subMenu);     for($i=0;$i<$cnt_subMenu;$i++) {       if($i<$cnt_subMenu-1 && $subMenu[$i][2]<$subMenu[$i+1][2]) {         $menu .= "<li>".$subMenu[$i][0]." ".$subMenu[$i][1]."<ul>";         $untilIndexUnderThisKat = getKatsUnder($subMenu,$i+1,$subMenu[$i][2]);         $menu .= buildMenu(array_cut($subMenu,$i+1,$untilIndexUnderThisKat));         $i = $untilIndexUnderThisKat;         $menu .= "</ul></li>";       } else {         $menu .= "<li>".$subMenu[$i][0]." ".$subMenu[$i][1]."</li>";       }     }     return $menu;   }

Diese Funktion durchläuft alle Kategorien-Datensätze und schaut, ob im nachfolgenden Eintrag die Ebene (Array-Index [2]) größer ist als beim aktuellen. Wenn dem so ist, wird eine weitere Liste unter dem aktuellen LI angelegt, indem die Funktion buildMenu() rekursiv aufgerufen wird, vorher aber das Array so gesplittet wird, das nur noch die Untermenüs des aktuellen Eintrags darin enthalten sind. Dazu werden zuerst alle darunter liegenden Kategorien geholt (getKatsUnder()) und anschließend das neue Array erstellt – das übernimmt die Funktion array_cut():

  function getKatsUnder($array,$start,$ebene) {     $cnt_array = count($array);     for($i=$start;$i<$cnt_array;$i++) {       if($array[$i][2]==$ebene) return $i-1;     }     return ($cnt_array-1);   }     function array_cut($srcArr,$start,$end) {     $newArr = array();     for($i=$start;$i<=$end;$i++) {       $newArr[] = $srcArr[$i];     }     return $newArr;   }

Ob die Sache noch performanter zu machen ist, kann ich im Augenblick nicht sagen, weil ich diesen Weg alle Einträge auf einmal zu laden selbst nicht mehr anwende und deshalb auch nicht weiter über die Performance nachgedacht habe. Es ist einfach der Weg, wie ich es mir damals ausgedacht habe. Ghostgambler hatte noch was mit current() und next() vorgeschlagen, eventuell gehts in die gleiche Richtung wie meine Lösung – wenn nicht, wäre es schön, wenn Du noch etwas mehr dazu sagen könntest.

Ich hoffe das hilft denjenigen, die immer wieder nach einem Weg gefragt haben… und wie gesagt: Die Lösung erhebt keinen Anspruch die schönste oder beste zu sein – auf jeden Fall funktioniert sie.
Und damit ihr nicht mühsam die Sachen rauskopieren müsst, hänge ich sogar das Script an: Nested Set zu HTML umwandeln

html

24.09.2019 21:39:07

HTML-Code auf Produktivsites so klein wie möglich

Es ist nicht sonderlich überraschend, wenn ich sage, je weniger Daten vom Server geschickt und vom Client empfangen werden müssen, desto schneller funktioniert der Seitenaufbau. Ich habe bereits im Beitrag zur Komprimierung des Ausgabestroms gezeigt, wie man den an den Client gesendeten Code verkleinern kann. In diesem Beitrag möchte ich aber einmal näher darauf eingehen, wie der an den Browser gesendete HTML-Code selbst verkleinert werden kann.

Zu allerest möchte ich eine wichtige Grundlage festlegen, damit man mit dem Code auch später noch arbeiten kann: Man sollte sich im CVS, SVN oder einfach nur auf der Festplatte 2 Ordner anlegen. Einen Source-Ordner, der die Quellcodes in ihrer ursprünglichen Form enthält, und einen Veröffentlichungsordner, in dem wir alle Dateien ablegen, die wir nach den folgenden Anweisungen verkleinern.
Alle hier aufgelisteten Tipps beziehen sich auf den HTML-Code, der entweder als fertige HTML-Datei vorliegt oder von einer PHP-Datei generiert wird, CSS-Dateien und JavaScript – kurz: alles, was vomClient geladen werden muss.

Zuerst entfernen wir alle unnötigen Leerzeichen und Zeilenumbrüche. Das sind vor allem solche zwischen Tags. Da HTML auf XML basiert, haben Zeilenumbrüche, Leerzeichen und Tabulatoren zwischen Tags sowieso keinen Einfluss. Es ist allerdings darauf zu achten, dass nicht innerhalb von Textareas oder vorformatierten Abschnitten (<pre>) für die Ausgabe bedeutsame Whitespaces entfernt werden.
Auch in CSS-Dateien sowie innerhalb von <style>-Tags können Leerzeichen und Zeilenumbrüche entfernt werden. Für Javascript gilt ähnliches, allerdings ist hier darauf zu achten, dass man keine syntaktisch notwendigen Leerzeichen löscht, aber ganz allgemein gesagt kann jeder Zeilenumbruch in JavaScript gelöscht werden und nach einem Semikolon braucht kein Leerzeichen zu stehen – vorausgesetzt, man hat nach jedem Befehl ordentlicherweise ein Semikolon gemacht.

Anschließend entfernen wir die HTML-Kommentare (<!– … –>), außer dem Kommentar um JavaScript-Angaben. Wichtig und auf jeden Fall beizubehalten sind auch die Doctype-Definition sowie Conditional Comments für den IE.
Das gleiche gilt für JavaScript (// und /* … */) und CSS (/* … */) – auch hier sind Kommentare auf dem Produktivsystem überflüssig.

Bestimmte Farben können in CSS in Kurzschreibweise angegeben werden: Immer dann, wenn sich die Hex-Ziffern der einzelnen Rot-Grün- und Blau-Werte wiederholen, geht das. So wird aus #ff0000 einfach #f00 oder aus #ddeeff #def.

Sinnlose Tags wie leere Absätze <p></p> oder bestimmte Meta-Angaben, welcher Editor benutzt wurde, können gefahrlos entfernt werden.
Wem es nicht auf Suchmaschinenoptimierung ankommt, sondern nur darauf, wie die Seite dargestellt wird, kann auch <i> statt <em> sowie <b> statt <strong> benutzen.

Benutze CSS !!! Mit dem gekonnten Einsatz von CSS-Eigenschaften für bestimmte Tags oder Klassen kann sehr viel Code eingespart werden. Wenn man dazu noch Vererbung von CSS-Klassen gekonnt einsetzt, kann richtig viel Code gespart werden.
Hinzu kommt, dass externe CSS-Dateien nach dem ersten Laden einer Seite (je nach Einstellung) beim Client im Browser-Cache gespeichert werden und somit beim nächsten Aufruf nicht geladen werden müssen. Ähnlich verhält es sich mit externen js-Dateien.

In CSS kann man viele Eigenschaften zusammenfassen. border-color, border-width und border-style beispielsweise können zusammengefasst werden:

/* alte Definition */ div {   border-color:red;   border-style:solid;   border-width:1px; }   /* neue Definition */ div {   border:solid 1px red; }

Das gleiche geht mit font-size, font-family, line-height und font-weight.

/* alt */ blockquote {   font-size:0.9em;   font-family:Arial,sans-serif;   line-height:12px;   font-weight:bold; }   /* neu */ blockquote {   font:bold 0.9em/12px Arial,sans-serif; }

Und es gibt weitere Beispiele, die nach diesem Muster funktionieren. Ich empfehle dazu die Beschreibungen auf CSS 4 You

In JavaScript können auch Codeoptimierungen vorgenommen werden: Aus x = x + 1; kann nach dem Umschreiben auf eine Inkrementierung x++; werden. Ebenso müssen auf Produktivsystemen Variablennamen nicht nachvollzogen werden können – aus var gesamtsumme kann per search-and-replace einfach var g1 gemacht werden. Ein automatisches Tool würde darauf achten, dass es nicht zu Variablenüberschneidungen kommt, deshalb die eins. Wenn man diese Optimierung per Hand durchführt, ist peinlichst genau darauf zu achten, dass man wirklich suchen-und-ersetzen benutzt, da man sonst eventuell ein Vorkommen einer Variable nicht umbenennt und das zu Fehlermeldungen und Funktionalitätseinbußen führen kann.

In JavaScript kann man auf die eingebauten Objekte (und Funktionen) wie window eine Referenzvariable legen. Statt

alert(window.navigator.appName);  alert(window.navigator.appVersion);  alert(window.navigator.userAgent);

könnte man

w=window;n=w.navigator;a=alert;  a(n.appName);  a(n.appVersion);  a(n.userAgent);

schreiben. Nebenbei erhöht diese Art der Programmierung auch die Ausführungsgeschwindigkeit des JavaScripts, da die Variablen einfacher auf die Objekte zugreifen können.
Ein Nebeneffekt dieses Tipps und dem im vorherigen Absatz ist, dass es Codediebe nicht mehr so leicht haben, den Code nachzuvollziehen und für eigene Aktionen zu verwenden.

JavaScript-Imports können optimiert werden. Man sieht oft Code-Blöcke wie diesen im Head einer Seite:

<script src="scripts/rollovers.js"></script>  <script src="scripts/validation.js"></script>  <script src="scripts/tracking.js"></script>

Wenn man die Inhalte der 3 Funktionen in eine große js-Datei kopiert, kann diese sehr viel einfacher geladen werden (nur noch eine HTTP-Anfrage nötig statt drei) und der Markup-Aufwand verringert sich ebenfalls.

Und zum Schluss noch einer der besten Tipps: Divs statt Layout-Tabellen nutzen. Das spart oft sehr viel Code und ist dazu noch wesentlich flexibler.

Ich sage es nochmal deutlich: Der Code, der am Ende nach all diesen Optimierungen herauskommt, ist für die Entwicklung nicht mehr zu gebrauchen, da er kaum noch Struktur enthält. Dem Browser ist das aber völlig egal, denn der verarbeitet die Scripte auch so ohne Probleme, nur müssen somit viel weniger Daten gesendet werden. Und ihre Benutzer interessiert der Quellcode auch nicht – die Hauptsache ist, dass es im Browser keinen Unterschied gibt. Weiterentwicklung wird eh mit dem Originalcode durchgeführt. Wer also sehr häufig Änderungen am Code durchführt, sollte sich den Einsatz eines (kostenpflichtigen) Tools wie dem W3 Compiler überlegen, statt die Optimierungen ständig von Hand durchzuführen.
Einzelne Tipps allein mögen nicht viel bringen. Wenn aber alle konsequent durchgeführt werden, können Ersparnisse von bis zu 30% herausspringen.

html

24.09.2019 21:38:58

JavaScript- und CSS-Dateien parallel downloaden

Um den HTML-Code schlank zu halten, doppelten Code zu vermeiden und Browser-Caching optimal einsetzen zu können, lagern viele Entwickler JavaScript- und CSS-Code in eigene Dateien aus und referenzieren diese Dateien anschließend im HTML-Code mit dem <script>- bzw. <link>-Tag. Doch sollte einiges beachtet werden.

Zuerst ist zu sagen, dass auf CSS-Dateien stets im <head> der Seite referenziert werden sollte und auf JavaScript am Ende des Bodys. Das ist deshalb gut, weil der Browser dann sofort alle CSS-Regeln hat und sofort mit der Formatierung der HTML-Elemente beginnen kann. Ansonsten wartet der Browser mit dem Rendering der Seite bis alle CSS-Dateien geladen sind.
JavaScript-Dateien sollten aus dem Grund direkt vor </body> eingefügt werden, da mit JavaScript HTML-Elemente erzeugt werden können, z.B. durch document.write() oder document.createElement(). Dadurch wird der HTML-Baum verändert. Deshalb muss der Browser mit dem Rendern des folgenden HTML-Codes warten bis die JavaScript-Datei geladen ist (denn der Browser weiß ja vorher nicht, was in der JS-Datei gemacht wird).
Mehr dazu, warum CSS im Head eingebunden werden sollte, gibt es bei Google Page Speed und im Yahoo Developer Network.

Nun kommt es aber manchmal vor, dass man noch einzelne kleine Code-Anweisungen nicht auslagern kann, beispielsweise wenn per PHP noch eine Variable eingefügt werden muss. Man hat dabei zwei Möglichkeiten:

  1. Dynamische CSS- bzw. JS-Datei per PHP-Script erstellen und Variable als GET-Parameter übergeben
  2. CSS- bzw. JS-Code mit dem Parameter direkt in den HTML-Code unterbringen

zu 1.: Diese Variante ist sehr schlecht, da mit der Änderung des Parameters sich der Dateiname der Ressource ändert. Dadurch muss die gesamte Datei erneut geladen werden, denn der Browser kann nicht auf die Datei aus dem Browser-Cache zugreifen.
zu 2.: erstmal noch kurz, was genau mit parametrisierten CSS- und JS-Anweisungen gemeint ist:

<style type="text/css"> .klasse { width: <?php echo $breite; ?> } </style> <link rel="stylesheet" href="restliches_CSS.css" type="text/css" />   <script type="text/javascript"> var elemente = "<?php implode(",",$elementeArray); ?>"; </script> <script src="restliches-Javascript.js" type="text/javascript"></script>

Diese Variante ist besser, da der größte Teil der Ressource aus dem Browser-Cache geladen werden kann. Aber es gilt folgendes zu beachten:
Wie oben gesagt, beginnt der Browser erst mit dem Rendering, sobald er alle CSS-Dateien und -regeln geladen hat. Deshalb sollten die parametrisierten CSS-Regeln, die im HTML-Code stehen möglichst auch im <head> stehen. Es ist aber zu beachten, dass JavaScript-Code zwischen 2 externen Ressourcen die Parallelisierung verhindert. Deshalb sollten stets alle externen JS-Dateien direkt hintereinander eingebunden werden. Erfolgt zwischen den einzelnen Referenzierungen zu CSS-Dateien oder JS-Dateien ein JS-Befehl, kann der Download nicht parallel erfolgen.

Beispiel (ganz schlecht):

<head> <link rel="stylesheet" type="text/css" href="stylesheet1.css" /> <script type="text/javascript" src="scriptfile1.js" /> <script type="text/javascript" src="scriptfile2.js" /> <link rel="stylesheet" type="text/css" href="stylesheet2.css" /> <link rel="stylesheet" type="text/css" href="stylesheet3.css" /> </head>

Hier wird der Download der Dateien stylesheet2.css und stylesheet3.css blockiert, weil die JS-Dateien dazwischen den HTML-Baum verändern könnten.

Beispiel (auch schlecht):

<head> <link rel="stylesheet" type="text/css" href="stylesheet1.css" /> <script type="text/javascript">  document.write("Hello world!"); </script> <link rel="stylesheet" type="text/css" href="stylesheet2.css" /> <link rel="stylesheet" type="text/css" href="stylesheet3.css" /> </head>

Zuerst wird die Ausführung des Inline-Style-Befehls durch stylesheet1.css verzögert. Anschließend verhindert die Inline-Anweisung wiederum, dass die Stylesheets parallel heruntergeladen werden können.

Beispiel (gut):

<head> <link rel="stylesheet" type="text/css" href="stylesheet1.css" /> <link rel="stylesheet" type="text/css" href="stylesheet2.css" /> <link rel="stylesheet" type="text/css" href="stylesheet3.css" /> <script type="text/javascript">    document.write("Hello world!"); </script> </head>

Zuerst alle externen Ressourcen einbinden. Alle werden parallel heruntergeladen. Anschließend das Inline-Script. Natürlich sollte das JavaScript möglichst weit unten in den Body geschrieben werden, da es genauso das Laden von Bildern verzögert.
Alle Beispiele stammen von hier.

Folgende Tipps kann ich demzufolge geben:

  • alle CSS-Datei-Referenzierungen per <link>-tag in den <head> direkt hintereinander schreiben
  • alle <script>-Tags direkt vor </body> (wenn möglich)
  • möglichst keine JS-Anweisungen (inline oder extern) zwischen CSS-Referenzierungen
  • keine JS-Inline-Anweisungen zwischen mehreren Referenzierungen auf JS-Dateien

Interessant in diesem Zusammenhang ist auch der Beitrag von Rakesh Pai namens Download JavaScript Files in Parallel. Er geht dabei auf das HTML-Attribut defer ein, das schon lange im Internet Explorer und seit Version 3.1 auch im Firefox implementiert ist. Damit umgeht man die Blockierung anderer Ressourcen durch JavaScript, da das defer einfach dem Browser mitteilt, dass das Script nicht sofort geladen werden muss, sondern erst, wenn der gesamte Body geladen ist. Dadurch brauchen dann andere Ressourcen nämlich auch nicht blockiert zu werden. Dadurch bräuchten die JS-Referenzierungen dann auch nicht mehr zwingend ganz am Ende des Bodys stehen.

html

24.09.2019 21:39:01

Einige Links

Heute bin ich auf eine interessante Webseite des O’Reilly-Verlags gestoßen, die sich mit Website Performance befasst. Der Verlag hat ja auch schon einige Bücher zum Thema herausgebracht. In diesem Beitrag möchte ich euch kurz einige Quellen nennen, die lesenswert sind.

Die Webseite, die ich gefunden habe, nennt sich treffend Website Optimization.
Zuerst ein Beitrag zu CSS Sprites, mit denen ich mich ja auch schon beschäftigt habe.
Außerdem ein weiterer Weg mehrere CSS-Dateien automatisch zusammen zu fassen, obwohl ich da eigentlich die Variante von Matthias besser finde (wenn man sie auf CSS überträgt).
Eine Zusamenfassung der Methoden bietet auch yensdesign.
Für die absoluten Optimierer gibt es einen Beitrag zur Verringerung des HTML-Codes, doch ich mahne zur Vorsicht. Wer das liest, sollte auch andere Quellen zu Rate ziehen, bevor er / sie die Änderungen durchführt, denn Tipps wie „Get rid of unnecessary closing tags </LI>, even </BODY>“ widersprechen natürlich jeglicher Validität. Manchmal wünsche ich mir schon, dass XHTML von den Browsern mit einem strengen XML-Parser verarbeitet würden, der einfach einen Fehler wirft, wenn die struktur kein XML ist … naja, nichtsdestotrotz sind in dem beitrag einige nützliche Ideen.

Oder hier noch was schönes zum Thema Parallelisierung / Verringerung von HTTP-Requests. Das hatte ich zwar auch schon beschrieben, aber ich freue mich immer wieder etwas über Performance-Themen zu lesen. Davon gibts leider viel zu wenig im Web, finde ich. Also wenn ihr da noch interessante Quellen kennt, würde ich mich über Kommentare freuen.

PS: Will keinen neuen Beitrag für aufmachen, aber habe hier noch 2 schöne Dinge zum Lesen:
1. Wie man einen Serverumzug mit möglichst wenig Problemen übersteht.
2. Und hier noch nen Screencast von Brenelz Web Solutions zum Thema transparente PNG-8-Bilder. PNG-8 ist wesentlich kleiner als PNG-24 und untersützt auch Transparenz und damit sind auch keine CSS- oder JS-Hacks nötig, um die Transparenz im IE6 anzuzeigen.

html

24.09.2019 21:39:00

Firefox-Plugins zum Verbessern der Client-Performance

Der Browser Firefox ist nicht zuletzt aufgrund seiner Pluginfähigkeit immer erfolgreicher geworden. So kann jeder Benutzer seinen Browser mit zahlreichen Zusatzfunktionen ausstatten, die (Hobby-)Programmierer erstellt haben. Diese Plugins helfen auch Webentwicklern bei der täglichen Arbeit sowie der Analyse und Verbesserung der eigenen Webseiten.

Eines der bekanntesten Plugins, das jeder Webentwickler nutzen sollte, ist Firebug. Damit kann jedes HTML-Element der aktuellen Seite analysiert und verändert werden. Außerdem sieht man, welche Regeln die aktuelle Darstellung des Elements durch CSS verursachen. Auch JavaScript lässt sich damit on-the-fly ausführen.
Firebug wurde aber wiederum als Plattform für einige weitere Plugins genutzt, auf die ich etwas näher eingehen möchte, da mit ihnen die clientseitige Performance von Webseiten ermittelt und verbessert werden kann.

Der Klassiker in Richtung Client-Performance-Analyse ist YSlow. Dieses Plugin stammt von Yahoo (das Y hätte es fast vermuten lassen). Es ist mittlerweile in Version 2 erschienen. Mit diesem Tool könnt ihr die Performance einer Webseite messen lassen und es gibt konkrete Tipps, um diese zu verbessern. Dabei besteht es aus 3 Tabs (+1 Tab für einige Tools):

  • Grade: Hier führt YSlow verschiedene Tests durch und vergibt eine Note (Grade, von A bis F), wie gut oder schlecht die jeweilige Webseite aus Performancesicht ist und gibt zusätzlich Hinweise, wie die Performance verbessert werden kann.
  • Components: Hier kann man sich anzeigen lassen, welche Bestandteile der Webseite wie groß sind (HTML, CSS, JS, Bilder usw.). So kann man auch leicht die Gesamtgröße einer Seite ermitteln.
  • Statistics: Hier kann man in einem Kreisdiagramm sehr schön vergleichen, in welchem Verhältnis sich die einzelnen Bestandteiltypen auf die Gesamtgröße auswirken. Viel wichtiger an dieser Funktion ist aber, dass man die Unterschiede bei leerem und gefülltem Browser-Cache sieht. Je weiter beide Werte auseinander liegen, desto besser funktioniert das clientseitige Caching (das natürlich serverseitig gesteuert werden kann).

Insbesondere die Best-Practice-Ansätze im Tab Grade helfen die Performance zu verbessern, obgleich sie auch manchmal eher für seeehr große Seiten gedacht sind (Größe von Yahoo eben).
Die gesamte Liste der von YSlow vorgeschlagenen Best Practices ist schon sehr informativ und lehrreich.

Ein zweites Tool, das erst vor Kurzem als Open Source veröffentlicht wurde, heißt Page Speed und ist von Google. Es wurde früher intern von Google dazu verwendet, die Performance der eigenen Webseiten und Applikationen zu verbessern. Prinzipiell geht das Tool recht ähnlich vor wie der Grade-Tab von YSlow. Es gibt also konkrete Empfehlungen zur Verbesserung der Performance. Teilweise überschneiden sich die Hinweise von YSlow und Page Speed, aber teilweise hat Page Speed auch noch zusätzliche Tipps wie zum Beispiel, wenn Grafiken per HTML skaliert werden, dann bietet es gleich eine skalierte Version an, denn per HTML Bilder zu skalieren ist natürlich unschön, weil der Client erstmal das große Bild laden muss.
Außerdem erkennt es schlauerweise JavaScript- und CSS-Code, der von der Seite gar nicht verwendet wird. Insbesondere bei größeren Projekten mit mehreren Entwicklern, Designern und Co blickt ja irgendwann niemand mehr durch die Stylesheets durch. Da ist so eine Funktion doch ganz praktisch.

Zusätzlich bietet Page Speed noch eine Timeline, auf der man visualisiert bekommt, wann auf eine Verbindung gewartet wird, wie lange die DNS-Auflösung dauert, wie lang das Senden dauert, wann JavaScript ausgeführt wird usw. – alle Aufgaben, die ein Browser eben zu erledigen hat. Das ist recht informativ, hat aber wohl eher statistische Zwecke und dient nur der Visualisierung.

Wer diese Plugins noch nicht nutzt, sollte sie sich mal genauer ansehen.
Kennt ihr noch weitere Plugins für den Firefox, die man unbedingt haben sollte, als Webentwickler? Oder wie ist eure Meinung zu oben beschriebenen Plugins? Ich freue mich auf zahlreiche Kommentare.

html