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

Random Javascript Themen, Tutorials und co

12.10.2019 02:43:56

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.

javascript

24.09.2019 21:42:38

Optimierungen von CSS und JavaScript on-the-fly

In meinem letzten Beitrag habe ich einige Möglichkeiten aufgezeigt, wie man HTML-, CSS und JavaScript-Code verkleinern kann ohne die Darstellung und Funktionalität zu beeinträchtigen. Wenn man jedoch keine Lust hat, immer nach einem Bearbeiten die Optimierungen wieder vorzunehmen, hab ich hier eine praktikablere Lösung. Außerdem wollen wir zusätzlich die Komprimierung der Daten einsetzen sowie das Client-side Caching einsetzen.
Das Ziel soll also eine Lösung sein, bei der wir mit unseren wohlstrukturierten Dateien weiterarbeiten können, aber trotzdem sollen möglichst wenig Daten vom Client geladen werden müssen.

Warum wollen wir eigentlich um jeden Preis die zu ladenden Daten so klein wie möglich halten? Es gibt 2 Gründe:

  • schnellerer Seitenaufbau: jedes Byte, was nicht geladen werden muss, beschleunigt den Seitenaufbau beim anfordernden besucher
  • geringere Kosten: oft ist das Trafficvolumen beim Webhosting oder Server begrenzt bzw. wird immer teurer je mehr Daten an den Client geschickt werden

Wenn wir es also schaffen, mit wenig Aufwand die Datenmenge zu verringern, können wir sowohl etas für unsere User als auch für unseren Geldbeutel tun.

Zuerst schauen wir uns CSS-Dateien an. Ich habe bereits bei Projekten mitgemacht, bei denen die CSS-Datei 40 kB groß war. Schönen Gruß an die 56k-Modem-User! Wir gehen hier natürlich davon aus, dass in der CSS-Datei nur wirklich genutzte Klassen und Definitionen enthalten sind – ansonsten wirkt dieser Tuningversuch lächerlich für das Projekt. Gut, wir nehmen und als Beispiel eine CSS-Datei mit einer Definition für das DIV-HTML-Element. Natürlich haben wir Multiformateigenschaften genutzt, um dadurch schon mal einige Bytes zu sparen, denn dabei geht die Übersicht auf keinen Fall verloren.

div {   font:bold 0.9em/12px Arial; /* fett groesse/zeilenabstand schriftart */   border:solid 1px red; /* typ breite farbe */   background:url(images/bild.jpg) top repeat-x; /* url position wiederholung */ }

Diese CSS-Datei kann nun nur noch durch 2 Dinge optimiert werden: Entfernung von Zeilenumbrüchen und Entfernen der Kommentare. Allerdings kann man mit der entstehenden 1-Zeilen-Datei später kaum noch arbeiten, deshalb wäre es doch toll, wenn diese Optimierungen zwar gemacht würden, wir uns aber nicht darum kümmern müssten.
Wir brauchen demzufolge ein Lösung, die on-the-fly die optimierte CSS-Datei erstellt und an den Client schickt. Um überhaupt an der Datei etwas ändern zu können, bevor sie geladen wird, brauchen wir erstmal PHP bzw. dessen Output Buffering. Dazu lassen wir unsere CSS-Datei(en) durch den PHP-Parser laufen. Das legt man über einen zusätzlichen Eintrag in der .htaccess fest (wenn diese Datei im root ihres Webprojekts noch nicht existiert, legen sie sie einfach an).
AddType application/x-httpd-php .css
Eine andere PHP über das Stylesheet schicken zu können, wäre die .css-Datei in .php umzubenennen, aber dann müssten alle Referenzierungen in der Anwendung umgeschrieben werden.

Was tun wir nun damit? Wir packen den PHP Output Buffer mit einer eigenen Callback-Funktion in die CSS-Datei. Die Callbackfunktion wird aufgerufen, nachdem die gesamte Dateiausgabe feststeht (der eigentliche CSS-Code geladen wurde), und erhält als Parameter genau diesen CSS-Code als String.

<?php header("Content-type: text/css"); ob_start("compress"); header ("content-type: text/javascript"); header ("cache-control: must-revalidate; max-age: 3600"); header ("expires: " . gmdate ("D, d M Y H:i:s", time() + 3600) . " GMT");   function compress($buffer) {   // remove comments   $buffer = preg_replace('!/\*[^*]*\*+([^/][^*]*\*+)*/!', '', $buffer);   // remove tabs, newlines, etc.   $buffer = str_replace(array("\r\n", "\r", "\n", "\t"), '', $buffer);   //remove multiple spaces   $buffer = preg_replace('/\s\s+/', ' ', $buffer);   return $buffer; } ?> div {   font:bold 0.9em/12px Arial; /* fett groesse/zeilenabstand schriftart */   border:solid 1px res; /* typ breite farbe */   background:url(images/bild.jpg) top repeat-x; /* url position wiederholung */ } <?php ob_end_flush(); ?>

Die Funktion compress ist unsere Callback-Funktion. Wir bearbeiten den Buffer (den CSS-Code) durch das Entfernen von Kommentaren, Zeilenumbrüchen und Tabulatoren sowie mehrfachen Leerzeichen. Dadurch wird folgende CSS-Datei im Endeffekt wirklich an den Client geschickt:

div { font:bold 0.9em/12px Arial; border:solid 1px red; background:url(images/bild.jpg) top repeat-x; }

Durch diese recht trivialen Änderungen konnte die ursprüngliche Größe von 212 Bytes auf jetzt nur noch 103 Bytes verkleinert werden. Das sind über 50% weniger Daten! Und wenn man es mit der CSS-Datei vergleicht, bevor man Multiformateigenschaften genutzt hat (wenn man diese auflöst und alle Einzeleigenschaften aufschreibt kommt man auf 358 Bytes), beträgt die Speicherplatzeinsparung sogar über 70%!

Mit JavaScript-Dateien können wir ähnlich verfahren. Wir fügen die Endung .js zur .htaccess hinzu, damit sie vom PHP Parser verarbeitet wird. Bei JavaScript sind die gleichen Formatierungen möglich, nur müssen wir zusätzlich die einzeiligen Kommentare entfernen, da es sonst zu Problemen beim Entfernen von Zeilenumbrüchen kommen kann. Unsere Callback-Funktion sieht bei js-Dateien also so aus:

function function compress($buffer) {   // remove comments   $buffer = preg_replace('!/\*[^*]*\*+([^/][^*]*\*+)*/!', '', $buffer);   $buffer = preg_replace('!//[^\n\r]*!', '', $buffer);   /*   Konstrukte wie    var variable = {     var1:"test",     var2:function() {       doSomething();     }   }   müssen nach der letzten schließenden Klammer ein Semikolon bekommen --> funktioniert nicht   */   //$buffer = preg_replace('/var ([^=]*) = \{(([^\}]*\})*)[\n\r]+/', "var ".'$1'." = {".'$2'.";", $buffer);   // remove tabs, spaces, newlines, etc. - funktioniert nicht, weil das vorhergehende nicht funktioniert   //$buffer = str_replace(array("\r", "\n", "\t"), "", $buffer);   $buffer = str_replace("\t", "", $buffer);   // multiple whitespaces   $buffer = preg_replace('/(\n)\n+/', '$1', $buffer);   $buffer = preg_replace('/(\n)\ +/', '$1', $buffer);   $buffer = preg_replace('/(\r)\r+/', '$1', $buffer);   $buffer = preg_replace('/(\r\n)(\r\n)+/', '$1', $buffer);   $buffer = preg_replace('/(\ )\ +/', '$1', $buffer);   return $buffer; }

In JavaScript gibt es komplexe Konstrukt (welche genau, steht im Kommentar im Quellcode), die ich versuche, durch ein Semikolon zu ergänzen. Leider funktioniert das nicht richtig. Aus diesem Grund habe ich auch nicht alle Zeilenumbrüche entfernt, denn sonst kommt es da zu Fehlern. Trotzdem bringt diese Funktion einiges an eingespartem Traffic.
Bei einem von mir geschriebenen Script zur Darstellung der Tooltips auf SucheBiete.com brachte diese Veränderung eine Einsparung von ca 20 % (Original: 3,24 kB, optimiert: 2,65 kB). Bei viel kommentierten Scripten wie beispielsweise Lightbox konnte ich sogar etwa 40 % einsparen (Original: 22,9 kB, optimiert: 13,8 kB).
Trotzdem muss ich sagen, dass es mit einigen JavaScripts Probleme gibt, beispielsweise mit der Bibliothek Prototype, da darin in Strings ‚/*‘ und ‚//‘ vorkommen. Man sollte also überprüfen, ob es nach dem Einbau JavaScript-Fehlermeldungen gibt.

Wenn diese On-the-fly-Optimierungen durchgeführt wurden, kann man die entstandenen Code dann noch als GZip senden, was die Größe des optimierten Codes auf ca ein Drittel zusammenpackt. Außerdem habe ich noch eine Cache-Control eingebaut, damit die Datei nicht jedes mal vom selben User erneut geladen wird.
Für CSS:

header("Content-type: text/css"); header ("cache-control: must-revalidate; max-age: 2592000"); header ("expires: " . gmdate ("D, d M Y H:i:s", time() + 2592000) . " GMT"); ob_start("compress"); function compress($buffer) {   // remove comments   $buffer = preg_replace('!/\*[^*]*\*+([^/][^*]*\*+)*/!', '', $buffer);   // remove tabs, spaces, newlines, etc.   $buffer = str_replace(array("\r\n", "\r", "\n", "\t"), '', $buffer);   $buffer = preg_replace('/\s\s+/', ' ', $buffer);   if (stripos($_SERVER["HTTP_ACCEPT_ENCODING"],'x-gzip') !== false) {     header("Content-encoding:x-gzip");     $buffer = gzencode($buffer);   }   elseif (stripos($_SERVER["HTTP_ACCEPT_ENCODING"],'gzip') !== false) {     header("Content-encoding:gzip");     $buffer = gzencode($buffer);   }   elseif (stripos($_SERVER["HTTP_ACCEPT_ENCODING"],'deflate') !== false) {     header("Content-encoding:deflate");     $buffer = gzdeflate($buffer);   }   header('Content-Length: ' . strlen($buffer));   return $buffer; }

Entsprechend funktioniert es auch für JavaScript (außer eben mit den oben genannten Replaces). Wer eine js-Datei hat, die durch die angegebene Funktion nicht optimiert werden kann, weil dadurch Fehler entstehen, sollte zumindest gzippen. Wenn man aber nix mehr mit dem Buffer vorhat, reicht auch ob_start("ob_gzhandler");.

Durch diese kleinen Eingriffe lassen sich also durchaus ohne viel Aufwand (Vorsicht, Untertreibung) einige Bytes an Trafficvolumen einsparen.
An die On-the-fly-Optimierung von HTML-Code traue ich mich im Moment nicht so recht ran, weil das mittlerweile nicht mehr sauber ist. Erstens haben viele Seiten nicht valides HTML und zweitens erschweren Geschichten wie Conditional Comments und vorformatierte Bereiche (z.B. in Textareas und <pre>-Abschnitten) das Optimieren.

javascript

10.11.2019 04:39:48

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.

javascript

12.10.2019 02:43:54

JavaScript-Event onLoad und die bessere Alternative

Die meisten Webentwickler kennen das JavaScript-Event onload. Dieses wird aufgerufen, sobald die komplette Seite geladen ist. Sie dient dann beispielsweise dazu, direkt nach dem Laden der Seite Änderungen durchzuführen. Nun gibt es allerdings ein großes Problem mit diesem Event – und dieses soll dieser Beitrag lösen.

Eigentlich ist das onload-Event eine feine Sache. Man kann sich sicher sein, dass der gesamte HTML-Code geladen ist und somit Änderungen ausführen. Würde es dieses Event nicht geben, müsste man die JavaScript-Funtion direkt aufrufen – und das ginge dann natürlich erst ganz am Ende des body-Tags bzw. nach dem zu bearbeitenden HTML-Element. Das hätte sehr hässlichen Code zur Folge. Viel schöner ist es doch den JS-Block in den Head der HTML-Datei zu schreiben oder sogar ganz auszulagern und dann darauf zu referenzieren.

Und doch ist das Event onload problematisch. Es wartet nämlich bis der gesamte Inhalt der Seite geladen wurde – das bedeutet: auch ALLE externen Ressourcen müssen erst vollständig geladen werden. Dazu gehören Bilder, Videos und sonstige externe Dateien. Zu diesem Zeitpunkt interagiert der User aber vielleicht schon mit der Seite, weil es ihm egal ist, ob da noch ein Bild oder Video lädt. Und das wiederum kann einerseits zu JavaScript-Fehlern führen, da der Entwickler per onload oft irgendwelche Funktionalitäten initialisiert und dann davon ausgeht, dass die Funktion sofort nach dem Aufruf für die User-Interaktion zur Verfügung steht. Es ist ja nicht unbedingt vertrauensbildend, wenn bei einem unbedarften User dann so ein tolles „Diese Seite enthält Fehler“ entgegenpoppt, wie der IE es bei JS-Fehlern anzeigt (bei entsprechender Einstellung, sonst zeigt er nur ein Ausrufezeichen unten links – aber auch das ist nicht schön).
Das zweite Problem ist, dass einfach eine Verzögerung eintritt. Der User möchte die Seite so schnell wie möglich benutzen – und es stört ihn garantiert, dass er eine bestimmte Funktion noch nicht nutzen kann, nur weil da noch ein Bild lädt (was mit der Funktion, die er nutzen möchte, vielleicht gar nichts zu tun hat).

Und wie lösen wir das Problemchen? Mit einem eigenen Eventchen.
Und zwar wollen wir ja eigentlich gar nicht warten bis das komplette Dokument mit allen externen Ressourcen geladen ist, sondern es würde vollkommen reichen, wenn alle DOM-Inhalte zur Verfügung stehen (das HTML-Dokument ist also vollständig geladen, sodass der DOM-Baum aufgebaut ist). Schon da können wir ja mit dem DOM arbeiten. Nativ bieten die Browser dafür leider keine Unterstützung, die für alle Browser gleichermaßen funktioniert, aber mit ein wenig Zusatzcode kann man den Seitenaufbau dadurch trotzdem beschleunigen.

//create onDomReady Event       window.onDomReady = initReady;         // Initialize event depending on browser       function initReady(fn)       {       	//W3C-compliant browser       	if(document.addEventListener) {           document.addEventListener("DOMContentLoaded", fn, false);         }       	//IE       	else {           document.onreadystatechange = function(){readyState(fn)}         }       }         //IE execute function       function readyState(func)       {       	// DOM is ready       	if(document.readyState == "interactive" || document.readyState == "complete")       	{       		func();       	}       }

In Zeile 1 wird unser neues Event namens onDomReady initialisiert. Dies geschieht durch den Aufruf der Funktion initReady(). Diese prüft nun, ob der Browser das W3C-Event-Model unterstützt. Für den IE gibt es eine kleine Sonderbehandlung (wie üblich).

Aufgerufen wird das Event nun so:

//execute as soon as DOM is loaded window.onDomReady(onReady);   //do when DOM is ready function onReady() { 	alert("The DOM is ready!"); }

Im Prinzip also genauso wie onload, nur eben jetzt mit dem neuen Event onDomReady.

Zur Anschauung habe ich noch eine kleine Demo erstellt, die das neue Event mit dem onload-Event vergleicht bzw. anzeigt, welches Event schneller da ist. Das funktioniert am besten mit leerem Cache, denn da werden die Unterschiede aufgrund des großen Bildes sichtbar.
Ich habe die Datei mit IE7 und FF3 unter Vista getestet. Ob die anderen Browser das auch verstehen, weiß ich nicht.
Große JS-Libraries wie jQuery oder Prototype haben ähnliche Funktionen, aber ich mag solche Monster nicht so gern, da die dem User erstmal 100 kB entgegenwerfen, obwohl man nur ganz wenige Funktionalitäten daraus nutzt.

Wem diese Mini-Funktion noch nicht reicht, der sollte auch mal den Beitrag bei The Future of the web ansehen. Dort ist eine etwas größere Funktion, die eventuell auch etwas mehr kann (hab ich nicht ausprobiert).

javascript

10.11.2019 04:39:44

UX Design mit Angular, HTML & CSS

User Experience (UX) und UI-Design sind fundamentale Bestandteile vieler Softwareprojekte und ermöglichen es, eine auf den Benutzer abgestimmte Lösung zu entwicklen, die sich von den Konkurrenzprodukten abhebt. Im neuen Entwickler-Tutorial „UX Design mit Angular, HTML & CSS“ zeigt Timo Korinth, wie gutes Design und User Experience auch ohne künstlerische Fachausbildung möglich ist.

Die Begriffe User Experience (UX), CSS und UI-Design sind für viele Softwareentwickler allgegenwärtig. Manch einer hadert aber noch mit sich selbst und kann sich nicht so recht dazu durchringen, eingehender in die Materie einzusteigen. Gerade jene Entwickler allerdings, die im Frontend-Bereich unterwegs sind (oder sein wollen), sollten die Vorteile einer guten Nutzerführung und eines ansehnlichen Designs nicht verkennen: Oft lässt sich hier ein Vorteil gegenüber etwaigen Konkurrenzprodukten erreichen.

Timo Korinth gibt in seinem Tutorial UX Design mit Angular, HTML & CSS einen Überblick über verschiedene Gebiete im Bereich UX, Design, Konzeption und Entwicklung. Dabei bleiben die Machbarkeit und der praktische Einsatzzweck immer im Blick. In Verbindung mit konkreten Beispielen und Erfahrungen aus vielen Projekten führt er Entwickler an die Materie heran und nimmt die Angst vor Themen wie UX, Design & CSS.

Der praktische Guide gibt eine Sammlung an Tipps und Tricks an die Hand, mit denen die eigenen Projekte in neuem Glanz erstrahlen: Man muss nämlich keinesfalls Künstler oder Designer sein, um eine gute UX oder ein ansprechendes Design in eigenen Projekten zu etablieren.

TIPP: Sichern Sie sich jetzt 15 Minuten GRATIS: https://tutorials.entwickler.de/tutorials/ux-design-gratis

Inhalt:
✓ Einführung in die Bestandteile von UX
✓ Entwicklung vs. Design
✓ Design Tools
✓ UX Best Practices
✓ CSS & HTML
✓ Layouting – Flexbox und CSS Grid
✓ UI-Strukturierung mit Angular Components (Atomare Controls vs. View Components)
✓ Automatisierte GUI Tests mit Protractor
✓ UI-Frameworks – Übersicht, Integration, Customizing und Stolperfallen bei 3rd Party UI-Libraries
… und vieles mehr!

Einen ersten Vorgeschmack gibts bei Youtube.

javascript