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: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:00

Performance bei unterschiedlichem HTML-Code

Mit HTML kann man ja das gleiche Aussehen einer Seite auf unterschiedlichste Art und Weise erreichen. Früher gab es Tables zur Positionierung, heute Divs. Man kann Dinge semantisch korrekt lösen (z.B. für Überschriften <h1> verwenden) oder man regelt einfach alles über CSS. Es gibt viele Wege, die nach Rom führen – doch welche Auswirkungen haben die verschiedenen Varianten auf die Geschwindigkeit der Darstellung?

Da ich gar nicht wüsste, wie ich das objektiv testen soll, überlasse ich das einfach einem anderen Blog ????
Nee, Spaß beiseite, ich möchte euch einfach den Artikel The Browsers Performance in Dependence of HTML Coding im Blog AJAXLine empfehlen.

Hier nur kurz die Ergebnisse:

  • Es ist schneller position:absolute zu verwenden als position:relative. Ist auch logisch, denn bei absoluter Positionierung sagt man dem Browser genau, wohin das Element soll, während es bei allen anderen Positionierungsarten erst berechnet werden muss.
  • Sehr viele HTML-Elemente auf einer Seite können das Rendering bremsen., aber man sollte erst nachdenken, bevor man irgendwelche Elemente streicht (auch in Richtung Validität). Test erfolgte mit 942 HTML-Elementen (zum Vergleich: die Suchergebnisse bei Google haben 384)
  • Sehr tiefe HTML-Verschachtelungen bremsen ebenfalls. Test erfolgte mit 30 ineinander verschachtelten Elementen.
  • Bilder sollten nicht mit HTML skaliert werden. Die width- und height-Attribute des img-Tags helfen zwar beim Skalieren, aber leider kommen oft auch unschöne Effekte dabei heraus und bremsen tut das ganze auch noch. Besser: Mit PHP skalieren.
  • Das img-Element wird schneller gerendert als die CSS-Eigenschaft background-image.

Wie gesagt, die Erkenntnisse stammen nicht von mir. Wer genaueres zu den Tests lesen möchte, klickt hier.

html

24.09.2019 21:39:03

Mobiles Internet

In Zeiten, in denen Handys immer leistungsfähiger werden und mittlerweile auch HTML-, CSS- und JS-fähige Browser spendiert bekommen, ist klar, dass es immer mehr Nutzer gibt, die ihren ständigen Begleiter dazu nutzen, im Netz Informationen abzurufen. Und doch wird das Thema bisher stiefmütterlich behandelt.

Das Problem am mobilen Internet war jahrelang, dass die Entwicklung für Handys (mindestens) drei Nachteile hatte:

  1. neue (im Vergleich zu HTML abgespeckte) Markup-Sprache nötig (WAP, cHTML usw.)
  2. unterschiedliche Interpretationen der Browser auf den verschiedenen Geräten -> zumal das Testen auf Handys viel schwieriger ist als am Desktop, denn wer hat schon Zugang zu vielen Handys?)
  3. und drittens war die Bandbreite meist so gering, dass interaktive Inhalte meist sinnfrei waren

Mittlerweile hat sich das etwas geändert. Die Datenraten sind gestiegen, manche Leute nutzen sogar zu Hause am Rechner die Handy-UMTS-Flatrate.
Außerdem gibt es mittlerweile bessere Browser und die interpretieren valides HTML zumindest annähernd kompatibel (leichte Unterschiede ist man ja vom Desktop her gewöhnt).

Nicht zuletzt ist das Mobile Internet aber so interesant, weil es eben (Achtung Fremdwort) ubiquitär ist. Das bedeutet, es ist überall verfügbar. In Deutschland gibt es mehr Handys als Einwohner und das will schon was heißen. Es birgt also ein riesiges Potential.

Insbesondere Geo-basierte Dienste sind natürlich mit dem Handy toll umzusetzen.
Man ist gerade beim Spielzeugeinkauf für die Kids zu Weihnachten und hat sich entschieden. Dann kann man nochmal kurz überprüfen, ob ein Laden in der Umgebung das Objekt der Begierde etwas günstiger anbietet. Sehr schlecht für die Ladenbesitzer, die teuer anbieten, aber das ist im Web ja nicht anders.

Der Galileo-Verlag hat nun ein neues Buch namens Mobiles Webdesign herausgebracht. Beim Webstandard-Blog gibts dazu sogar ein Gewinnspiel. Also wer an diesem Thema interessiert ist und noch kein passendes Weihnachtsgeschenk für sich selbst hat (oder seinen Wunschzettel noch nicht abgeschickt hat), dem sei das empfohlen.

Nun wollte ich euch mal fragen, wie ihr zum Mobile Web steht. Gibt es schon Erfahrungen? Wie am besten einsteigen? Sollte man Subdomains nutzen oder anhand der Browserkennung die mobile bzw. normale Version ausliefern? Welche mobilen Seiten findet ihr gut bzw. schlecht? Wie sollte ein Design verändert werden, um auf den kleinen Displays ordentlich angezeigt zu werden?
Ich freue mich auf eure Meinungen! Wer über ein bestimmtes Thema separat diskutieren möchte, darf auch gern das Forum nutzen.

html

24.09.2019 21:39:05

Performancegewinn durch virtuelles JavaScript-File

Dies ist ein Gastbeitrag von Tobias Undeutsch. Es wird beschrieben, wie durch den Einsatz von PHP die Konkurrenzsituation paralleler Downloads bei mehreren eingebundenen JavaScript-Dateien vermieden und somit beschleunigt werden kann.

Da ich zur Zeit an einem größeren, stark JavaScript- und AJAX-basierten Webprojekt arbeite, an welchem vor allem in der Entwicklungs- und Testphase viel geändert werden soll / muss, musste ich mir etwas einfallen lassen, wie ich den Seitenaufbau auf dem Client performanter gestallten kann.

Da alleine die Startseite über 20 verschiedene JS-Files lädt (davon bekanntlich immer nur zwei gleichzeitig), begann ich dort zu schauen was sich machen lässt. Eine Verringerung der Anzahl JS-Files kommt deshalb nicht in Frage, weil mehrere Entwickler mit den Files arbeiten und um das Projekt übersichtlicher zu halten. Die Komplexität für die Programmierer sollte sich demzufolge nicht ändern.

Nach einer kurzen Suche im Internet kam ich auf ein Vorgehen, mit welchem sich die JS-Files auf dem Server zusammenfügen lassen und als eine Datei an den Server gesendet werden: ein virtuelles JavaScript-File!

Dazu hier ein Beispiel:
Im HTML sind zwei JS-Files eingebunden:

<script language="javascript" type="text/javascript" src="script/script1.js"></script> <script language="javascript" type="text/javascript" src="script/script2.js"></script>

Diese werden nun durch diese Zeile ersetzt:

<script language="javascript" type="text/javascript" src="vscript.php"></script>

Die Datei vscript.php auf dem Server:

<?php // Set application type header('Content-type: application/javascript');   // Get content of real javascript files require_once('script/script1.js'); require_once('script/script2.js'); ?>

Das wars dann auch schon, die JS Files werden auf dem Server zusammengefasst und als ein File gesendet!

Ich bin noch einen kleinen Schritt weiter gegangen und lasse mit zwei einfachen preg_replace „single line comments“, Zeilenumbrüche und Einzüge aus den Scripts entfernen, um wirklich nur den benötigen Source an den Client zu senden.
Anmerkung von Jan: Dies hatte ich bereits in diesem Beitrag vor einiger Zeit beschrieben. Dort wird noch ein wenig mehr gefiltert.

So haben die Programmierer alle Vorzüge, welche gut gegliederte Sourcecodes auf mehrere Files verteilt haben und die Client Performance wird verbessert. Als kleines extra wird der JS-Source beim Client schwerer lesbar ????

Mein fertiges Script:

<?php // Set application type header('Content-type: application/javascript');   // Set variables $str_ouptput;   // Get content of real javascript files $str_output = file_get_contents('script/script1.js'); $str_output .= file_get_contents('script/script2.js');   // Remove single line comments $str_output = preg_replace('#//.*#', '', $str_output);   // Remove line breaks and indents $str_output = preg_replace('#\n|\n\r|\r|\t#', '', $str_output);   // Send fake js echo $str_output; ?>

Beim Schreiben der JS-Files muss nun nur noch penibel darauf geachtet werden, dass alle Semikolon richtig gesetzt werden!

Noch einige Anmerkungen von Jan:
In dem Zustand, wie Tobias es hier geschrieben hat, werden die virtuellen JS-Dateien allerdings nicht im Browser-Cache des Besuchers zwischengespeichert. Die Datei müsste demzufolge bei jedem Seitenaufruf erneut heruntergeladen werden, was einerseits für den Client Zeit kostet und andererseits Last auf dem Server verursacht. Deshalb schlage ich als sinnvolle Ergänzung einige Header-Anweisungen vor. Außerdem kann man das fertige Dokument noch gzippen und verringert dadurch die zu übertragende Datenmenge.

header('Content-type: text/javascript'); header ("cache-control: must-revalidate; max-age: 2592000"); header ("expires: " . gmdate ("D, d M Y H:i:s", time() + 2592000) . " GMT"); ob_start("ob_gzhandler");

Des Weiteren bin ich mir nicht ganz sicher, ob der MIME-Type für JavaScript nicht doch text/javascript ist. Der Firefox ist da manchmal recht penibel. Vielleicht ist es aber auch egal. Kann ja vielleicht durch die Kommentare zu diesem Beitrag noch verifiziert werden.

Und nicht verschweigen möchte ich noch, dass die Generierung der virtuellen Datei natürlich den Server mehr belastet als es die bloße Auslieferung der JS-Dateien täte. In meinen Augen ist dies aber zu vernachlässigen.

Ich danke Tobias vielmals für diesen Beitrag. Falls auch andere Leser mal Lust haben hier etwas zu veröffentlichen, freue ich mich (und bestimmt auch die Leser) über jeden Beitrag.

html