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-css / index.php

Random Css Themen, Tutorials und co

24.09.2019 21:40:57

CSS Sprites – Einsparung an HTTP-Requests durch Kombination von Hintergrund-Bildern

Wie sich ja gewünscht wurde, möchte ich von nun an auch etwas mehr über die Performance von Client-Systemen in Bezug auf Webanwendungen schreiben. Genauer: Wie müssen Webseiten ausgeliefert werden, damit Sie möglichst schnell im Browser des Besuchers dargestellt werden können?
In diesem Beitrag soll es dabei um die CSS Sprites bzw. Image Sprites gehen. Die Yahoo-Präsentation hat ja bereits darauf hingewiesen und hier soll nun erklärt werden, wie es funktioniert.

Problemstellung
Ein Problem, weshalb Seiten oft lange Ladezeiten haben, ist, dass recht viele HTTP-Requests gemacht werden müssen. Da HTTP ein zustandsloses Protokoll ist, muss für jedes Bild, jede JS-Datei und allgemain jede externe Ressource eine neue HTTP-Verbindung zwischen Browser und Server eröffnet werden. Das wäre ja noch nicht problematisch (lediglich umständlich). Das Problem ist aber, dass je nach Browser nur eine bestimmte Anzahl an parallelen HTTP-Requests ausgeführt werden können (oft 2-4). Im Firefox kann diese Einstellung über network.http.max-persistent-connections-per-server auf der about:config-Seite verändert werden.
Dadurch entsteht ein Treppen-Diagramm, das die Gesamtladezeit verdeutlicht: Treppeneffekt beim Laden mehrerer externer Ressourcen
Es wird deutlich, dass einige Beschleunigung des Ladens erreicht werden kann, wenn entweder die Anzahl paralleler Requests erhöht wird oder die Anzahl an Requests verringert wird. Ersteres kann beispielsweise durch unterschiedliche Subdomains gemacht werden (eine für Bilder, eine für JS usw.). Genaueres dazu findet sich beim Beitrag, wenn man auf den Link des Diagramms klickt.
Wir wollen uns jetzt aber mal mit dem anderen Punkt beschäftigen: der Verringerung der HTTP-Requests.

HTTP-Requests verringern könnte man auf 2 Arten: Mehrere Komponenten innerhalb einer Datei konsolidieren (ich hasse dieses Wort, seitdem es in jeder IT-Zeitung steht) oder die Komponenten inline in das HTML-Dokument einbinden. Letzteres geht beispielsweise gut bei CSS (wird z.B. auf Yahoo gemacht) aber auch bei Bildern (aber dann wird der Quellcode richtig hässlich).
Hier soll es um die Konsolidierung mehrerer Komponenten gehen, genauer um das Verringern von Anfragen für Hintergrundbilder.

Jedes mit CSS über url() referenzierte Hintergrundbild benötigt natürlich auch einen HTTP-Request. Aber habt ihr euch mal alte Spiele angesehen (bei aktuellen weiß ichs nicht, dafür hab ich leider kaum noch Zeit)? Dort sind meistens verschiedene GUI-Elemente in einer einzigen Bilddatei zusammengefügt. Hinterher schneidet sich dann das Programm den gewünschten Teil raus. Das spart Speicherplatz und Ladezeit.

Übertragen auf die Webentwicklung ist es ganz ähnlich: Mehrere Hintergrund-Bilder können in eine Grafik-Datei gepackt werden und später trotzdem an der richtigen Position angezeigt werden.
Der erste Schritt dafür ist das Zusammenpacken in eine Datei. Das geht ganz gut mit einem CSS-Sprite-Generator. Dabei sollte allerdings dringend darauf geachtet werden, dass man entweder nur Bilder nimmt, die später horizontal wiederholt werden (repeat-x) oder nur Bilder, die vertikal wiederholt werden (repeat-y) (bei mir traf ersteres dazu, deshalb kann ich die Tauglichkeit des verlinkten Generators für Letzteres nicht einschätzen). Zu den Gründen unten mehr.
Jedenfalls spuckt der Generator letztlich eine Bilddatei aus, in der alle eure Hintergründe enthalten sind. Dazu gibts noch einen CSS-Code.

Allein mit den Anweisungen dort beim Generator habe ich es allerdings nicht hinbekommen, die Sprites zum Laufen zu bekommen, sondern mir war noch dieser Beitrag behilflich. Zuerst muss die Sprite-Grafikdatei nämlich einmal eingebunden werden. Und zwar am besten für alle CSS Regeln, bei denen eines der im Sprite enthaltenen Bilder als Hintergrundbild genutzt wird. (Beispiel siehe unten)

Anschließend kann man sich um das Ersetzen der alten Hintergrundregeln kümmern, denn die werden nun nicht mehr benötigt. Je nachdem, welche CSS-Regeln obiger Generator ausspuckt, ersetzt ihr background-image nun nur noch durch background-position (also inklusive den vom Generator ausgepuckten Werten). Dadurch wird das Sprite an die für das bestimmte Element korrekte Position verschoben.

Nun aber zum repeat. Wenn ihr bisher die Multiformat-Eigenschaft background benutzt habt, müsst ihr das jetzt aufdröseln, denn es wird ja nur noch background-position und background-repeat benötigt. Jedenfalls werdet ihr eventuell schnell merken, dass wenn ihr repeat-x verwendet, es kein hübsches Hintergrundbild wie früher gibt. Der Grund dafür sind unterschiedlich breite Hintergrundbilder. Dadurch entstehen mitunter neben dem Bild weiße (oder transparente; je nachdem, was man einstellt) Ränder. Für ein repeat-x werden aber durchgängige Bilder benötigt.
Deshalb gibt es 2 Wege dieses Problem zu beheben: Entweder alle Bilder nachträglich auf gleiche Breite ziehen. Oder (von mir präferiert) einfach nur den ersten Pixel in der Breite des Sprite-Bildes verwenden (bzw. gleich nur 1px breite Bilder dem Sprite-Generator geben). Kann man ganz einfach per Irfan View oder auch irgendeinem anderen Grafikprogramm auswählen, freistellen / kopieren und entsprechend abspeichern. Es ist sowieso nur ein 1px breites Bild erforderlich, da der Rest ja per repeat-x generiert wird.

Und jetzt kommt noch das zweite Problem, auf das ich gestoßen bin: Ich habe einen Seiten-Hintergrund, der 500px hoch ist (Verlauf). Wenn die Seite länger ist, wird einfach die angegebene Hintergrundfarbe angezeigt. Wenn nun aber unterhalb dieses Bildes im Sprite noch ein völlig anderer Hintergrund kommt, weiß CSS natürlich nicht, wo es das Bild beenden soll (insbesondere da man per CSS zwar das Hintergrundbild verschieben nicht aber einen bestimmten Bereich ausschneiden kann). Entsprechend wird dann einfach der darunterliegende Hintergrund noch mit angezeigt. Entweder man wählt zur Behebung dieses Problems sehr große vertikale Abstände zwischen den einzelnen Hintergründen (diese Lösung ist allerdings nicht sehr flexibel, denn eventuell wird in der Zukunft eine noch längere Seite erstellt, wo der Abstand dann nicht mehr ausreicht) oder man wählt für das Sprite nur Hintergrundbilder von Elementen, deren Höhe feststeht (per CSS-Attribut height; teilweise auch bei Inline-Elementen, jedoch muss da eventuell auf die Schriftgröße geachtet werden – ist diese nämlich relativ angegeben, ist auch die Höhe des Elements variabel).

Nun noch ein kleines Beispiel zur Verdeutlichung:
Alte Regeln:

#header {background: url(bild1.jpg) top left repeat-x; height:80px;} ul.menu li {background: url(bild2.jpg) top left repeat-x; height:15px;}

bild1.jpg und bild2.jpg sind jeweils 1px breit. Durch den Sprite-Generator jagen, Sprite-Datei runterladen bzw. auf Webserver hochladen.

Sprite-Bild einmalig einbinden für alle Elemente, die einen im Sprite enthaltenen Hintergrund haben:

#header, ul.menu li {background-image:url(bg_sprite.png);}

Mit Hilfe der im Generator angegebenen Regeln die alten Regeln ersetzen:
Generator spuckt zum Beispiel aus:

.sprite-bild1 { background-position: 0 -30px; }  .sprite-bild2 { background-position: 0 -110px; }

Einbau in vorhandenes CSS:

#header {background-position: 0 -30px; background-repeat: repeat-x;} ul.menu li {background-position: 0 -110px; background-repeat: repeat-x;}

Und das wars. Mit 2 Bildern macht das noch nicht so viel Sinn, aber ich denke das reicht zum Verdeutlichen.

Falls ihr noch Fragen habt zu diesem Thema, freue ich mich über Kommentare. Euren Erfolg durch diese Maßnahme prüfen könnt ihr übrigens mit Firebug (Tab Net) sowie YSlow (Tab Performance).

css

24.09.2019 21:40:56

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.

css

24.09.2019 21:40:56

CSS-Tuning mittels DATA-URI (base64)

Dieser Artikel soll als Ergänzung zum Artikel CSS-Sprites dienen, den Jan vor einem Jahr veröffentlicht hat. Ergebnis soll so sein: Internetwerbung (Quellcode der CSS-Datei)
Wie Jan bemerkt hat, ist die Verwendung von CSS-Sprites teilweise sehr tricky und liefert z.b. schlechte Ergebnisse wenn:

  • die kombinierten Bilder verschiedene Farbtiefen haben, weil das Ergebnisbild entweder die größte Farbtiefe aller Bilder hat und dadurch sehr groß wird, oder die kleinste Farbtiefe aller Bilder hat und dadurch eher unansehnlich wird. Zwischenwerte sind denkbar aber auch immer nur ein Kompromiss zwischen Qualität und Dateigröße
  • Angenommen man möchte 2 Bilder kombinieren: 1.) 1x1000px und 2.) 1000x1px, dann wird das Ergebnisbild entweder 1001x1000px oder 1000x1001px groß, d.h. was man durch Verringerung an HTTP-requests einspart, zahlt man durch zusätzliche Übertragungsdaten wieder drauf
  • das Problem mit Repeat bei sehr langen Seiten
  • beim Einfügen neuer Teilbilder muss ggf. das ganze „Sammelbild“ neu zusammengesetzt werden (inkl. Änderungen in der CSS-Datei).

Die Lösung heißt DATA-URI (base64)

Die Grundlagen dazu sind sehr gut in der englischen Wikipedia nachzulesen. Allerdings möchte ich euch einige (selbstentwickelte) Tuningmaßnahmen vorstellen. Zuerst muss gesagt werden, dass man mit dieser Methode sämtliche HTTP-Requests aus seiner CSS-Datei entfernen kann. Dadurch wird die CSS-Datei allerdings um die Summe aller verwendeten Bilder größer. Deshalb unbedingt Cache-Header verwenden!!! Da meine „Tuningmaßnahmen“ sehr serverlastig sind (Bildbearbeitung mittels PHP), empfehle ich dringend die Ergebnis-CSS-Datei zu cachen: Ich habe einen einfachen (aber wirkungsvollen) Cache implementiert.

So solls am Ende aussehen

Auf einer meiner Internetwerbung Seiten (die Seite ist egal, und dient nur Demonstationszwecken) kann man sich die CSS-Datei ansehen. Wenn man den Quelltext nach der Zeichenkette: „url(„ durchsucht, sieht man alle verwendeten Bilder als Teil der CSS-Datei und nicht mittels Link-Tag referenziert. Der Kommentar am Anfang ist nur informativ für mich und sagt mir die Zeichenzahl meiner CSS-Datei (=Größe).

Anleitung zum Umbau der CSS-Datei

Wer erstmal „nur“ testen möchte, kann gerne die Code-Schnipsel von Wikipedia verwenden. Ich habe diese weiterentwickelt und stelle sie euch hier exklusiv zur Verfügung.

  • CSS-Datei irgendwo sichern … man weiß ja nie ????
  • Falls noch nicht in der .htaccess vorhanden: Addtype application/x-httpd-php .css einfügen, damit die CSS-Datei durch den PHP-Interpreter läuft (alternativ kann auch die style.css in style.css.php umbenannt werden, aber dann müssen auch alle Referenzen im HTML-Code geändert werden)
  • Dem Root-Verzeichnis Schreibrechte 777 geben (aus Sicherheitsgründen nach Erzeugung der CSS-Datei die Schreibrechte wieder entfernen)
  • In der Index-Datei den Pfad zur CSS-Datei ändern in: style_neu.css
  • Folgenden PHP-Code an den Anfang der CSS-Datei einfügen: CSS-Code für base64-Codierung
  • Die alte CSS-Datei aufrufen, damit die neue CSS-Datei erstellt wird.
    Was Passiert? :
    Die bisherige CSS-Datei wird umgebaut und liefert die neue komprimierte CSS-Datei mit eingefügten Base64-Bildern. Die neue CSS-Datei wird unter dem Namen style_neu.css im Root-Verzeichnis gespeichert (ggf. kann man das anpassen (bedenkt: Schreibrechte 777 für den betroffenen Ordner setzen)). Die ganze Umwandlung besteht aus 3 Schritten:
    ob_start(‚compress‘);
    Der Ausgabepuffer wird aktiviert und komprimiert die bisherige CSS-Datei indem überflüssige Zeichen entfernt werden. Bemerkung: Falls jemand eine Methode (Code-Schnipsel) kennt, wie man die CSS-Datei noch weiter verkürzen kann (CSS-Shorthand-Erkennung, Zusammenfassung gleicher Parameter (wie in meinem CSS-Beispiel), u.ä.), bitte kurze Nachricht an mich (die Geschwindigkeit der Umwandlung ist egal, weil das Ergebnis gecached wird).
    function data_url
    Diese Funktion ist das eigentliche Herzstück. Sie wird für jedes Bild der CSS-Datei aufgefufen. Pflichtparameter sind: die Bild-Url ($file) und der MIME-Datentyp ($mime). Optionale Parameter sind die Seitenlängen des Bildes (damit das Bild, falls es nur verkleinert gebraucht wird, vor der Umwandlung in Base64 gestaucht werden kann) und die Qualität (0 <= X <= 100). Die ersten Zeilen legen fest, ob sich eine Bildbearbeitung lohnt. Ich lege fest, dass kleine Bilder (kleiner als 70 x 70px) prinzipiell Base64-Codiert werden sollen, weil bei diesen Bildern die HTTP-Requestzeit im Verhältnis zur eigentlichen Übertragungszeit sehr hoch ist. Dateien werden durch die Base64-Codierung ca. 1/3 größer. Dadurch kann es passieren, dass bei großen Bildern die Übertragungszeit stärker wächst, als die Zeiteinsparung durch Verringerung der HTTP-Requests. Und deshalb lasse ich diese Bilder lieber normal referenziert. Außerdem möchte ich Bilder codieren, die in der fertigen CSS-Datei (um mindestens 30%) kleiner sind als das Originalbild, weil die Einsparung durch die physische Verkleinerung des Bildes den zusätzlichen Traffic durch die Base64-Codierung wett macht.
    Ähnlich verhält es sich bei Bildern, die lediglich in geringer Qualität gebraucht werden (z.B. bei sehr kontrastarmen Bildern merkt man Qualitätsunterschiede kaum). Alle Bilder, die nicht ausgewählt wurden, werden wie bisher normal referenziert. Alle anderen (also die meisten der CSS-Datei) werden je nach Mime-Typ gestaucht. Die Verwendung des Ausgabepuffers in der Funktion ist ein Trick, damit man das Bild als String bekommt, den man dann in Base64 umwandeln kann. Die restlichen Funktionen sind reine Arbeitsfunktionen ohne (geistige) Leistung meinerseits.
    Schreiben-Funktion
    Wie man sich schon denken kann, übernimmt diese Datei den Schreibvorgang der fertig erzeugten CSS-Datei. Es wird noch der Header: Content-Type: text/css eingefügt und festgelegt, dass die Style_neu.css komprimiert an den Browser versendet wird. Das lohnt sich sehr, weil Base64-Code sehr stark komprimiert werden kann.
  • alle Stellen der CSS-Datei, an denen ein Bild mittels url(‚xxxxx.yyy‘) referenziert wird, werden ersetzt durch url([Base64-Code]), wobei Breite und Höhe unbedingt angegeben werden sollten, und den optionalen Parameter Qualität zwischen 1 und 100 (einfach mal ausprobieren, wie weit man die Qualität runterschrauben kann, bis man den Unterschied sieht).
  • kontrollieren, dass jedes externe Bild in genau einer CSS-Regel verwendet wird (notfalls Regeln neu sortieren), damit das selbe Bild nicht mehrfach in die CSS-Datei eingefügt wird. Beispiel: Bisher:
    .a{    height:18px;    margin:0 0 0 5px;    padding:0px;    background-image:url('a.jpg');    } .b{    height:20px;    margin:0 0 0 5px;    padding:0px;    background-image:url('a.jpg');    } .c{    height:22px;    margin:0 0 0 5px;    padding:0px;    background-image:url('a.jpg');    }

    Also 3 CSS-Regeln, die sich nur in verschiedenen Height-Werten unterscheiden.
    Müssen umgewandelt werden in:

    .a,.b,.c    {    margin:0 0 0 5px;    padding:0px;    background-image:url(<?=data_url('a.jpg','image/jpg',10,10)?>); /*angenommen breite und höhe sind 10px*/    } .a{    height:18px;    } .b{    height:20px;    } .c{    height:22px;    }

    Ergebnis: das Hintergrundbild ist jetzt nur noch in einer Regel und wird deshalb auch nur einmal in die CSS-Datei eingefügt. Kleiner Nebeneffekt: die redundanten margin- und padding-Werte wurden entfernt.

Benchmark

Ich habe auf meiner Seite beide Varianten mit YSlow getestet:
Vorher: 0,56s
Nachher: 0,79s (css nicht gecached (umwandlung on the fly))
Nachher: 0,25s (css gecached)

Fazit

Im ungecachetem Zustand wird die Zeiteinsparung durch die Verringerung der HTTP-Requests vollständig durch die Erstellungszeit der neuen CSS-Datei aufgebraucht. Ein Cache ist also unbedingt notwendig!

Nur nebenbei

Jan hatte ja schon erwähnt, dass die meisten Browser eine interne Beschränkung haben, was die Anzahl der gleichzeitigen HTTP-Requests angeht. Erwähnenswert ist, dass die meisten Betriebssysteme ebenfalls eine interne Beschränkung haben. D.h. es ist doppelt wichtig die Anzahl der Requests der eigenen Seite gering zu halten, weil es eben 2 Flaschenhälse gibt.

Nur Nebenbei II

Wer noch die letzten Prozente rausholen möchte, kann die gecachede Datei gleich gezipt speichern, damit beim Ausliefern die Zeit zum Zippen entfällt. Bei mir bringt das etwa 0,05s … (klingt wenig, entlastet den Server aber)

Ein kleines Quiz am Ende

Was wird hier gemacht?

echo '<link rel="icon" href="data:image/ico;base64,'.base64_encode(file_get_contents('images/favicon.ico')).'" />';
css

24.09.2019 21:40:59

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.

css

24.09.2019 21:40:55

Performance-Probleme beim Rendering von Hintergrundbildern im IE

Die schnellste Übertragung von HTML, Bildern & Co. nützt nichts, wenn der Browser beim Rendern dieser Elemente ins Schwitzen kommt. Im Internet Explorer scheint es diesbezüglich ein besonders großes Problem im Zusammenhang mit großen Hintergrundbildern zu geben, wodurch der Browser unter gewissen Umständen mehrere Sekunden lang blockiert und die Seite dadurch unbenutzbar bzw. unscrollbar wird.

Dies ist ein Gastartikel von Lars-Simon Wollny.

Auf unserer Seite www.tui-wolters.de gab es das Phänomen, dass sich der Internet Explorer beim Rendering – vor allem beim Scrollen – etwas träge anfühlte. Das war noch kein großes Problem, den Rahmen gesprengt hat es allerdings, wenn der Zoomfaktor auf 95% reduziert wurde (lässt sich nicht direkt auswählen, aber mit gedrückter STRG-Taste und Scrollrad kann man die Zoomstufe in 5%-Schritten ändern). Der IE war nun nahezu unbenutzbar, die Seite brauchte etwa 1 Minute bis sämtliche Ladevorgänge abgeschlossen waren. Menüs waren sehr träge, beim Scrollen konnte man zusehen wie der IE die Seite Stück für Stück wieder aufbaute.

Merkwürdig war nur, dass es im Firefox und anderen Browsern überhaupt keine Performanceprobleme gab.

Wie wir letztlich nach vielem Ausprobieren festgestellt haben, war das Problem die Hintergrundgrafik: Diese war unten ausgerichtet und in der Höhe so groß bemessen, dass sie auch bei sehr langen Seiten einsetzbar war. Sie war 1px breit, 30.000px hoch und wurde dann entsprechend nach rechts „repeated“. Die Höhe klingt sehr groß, aber die Dateigröße lag bei nur 206 Byte (PNG). Wir konnten die Struktur der Seite nun so ändern, dass die Hintergrundgrafik nur noch etwa 500 Pixel hoch ist; der restliche Hintergrund wird durch Background-Color gefüllt.

Jetzt läufts im IE richtig flüssig, auch bei 95% Zoomstufe. Trügerisch war nur, dass man im Firefox überhaupt keinen Unterschied bemerkt – und auch im IE nur bei 95% Zoomstufe wirklich eine Änderung festzustellen ist.

Getestet und erfolgreich nachgestellt haben wir dieses Phänomen im IE7 und IE8, im IE9 konnten wir leider nicht testen.

Fazit
Man sollte möglichst kleine Hintergrundgrafiken verwenden – nicht nur von der Dateigröße her sondern auch von den Abmessungen. Und wenn man seine Seitenperformance im IE testen möchte, reduziert man am besten die Zoomstufe, dann muss der IE viel mehr arbeiten und man kriegt ein deutlich besseres Bild von potentiellen Flaschenhälsen.

css