XHTMLforum

XHTMLforum (http://xhtmlforum.de/index.php)
-   Knowledge Base (http://xhtmlforum.de/forumdisplay.php?f=79)
-   -   Ladezeit optimieren - Was sind die wichtigsten Faktoren? (http://xhtmlforum.de/showthread.php?t=65735)

Test5000 13.09.2011 23:12

Ladezeit optimieren - Was sind die wichtigsten Faktoren?
 
Hallo zusammen,
mich würde interessieren, wovon die Ladezeit meiner Seite (HTML+CSS) am meisten abhängt, bzw. welche Faktoren man am meisten beachten muss.
Ich habe schon paar Sachen gelesen, dass die Bilder klein sein sollen usw. aber mir ist das nicht detailliert genug. Kennt ihr einen guten Artikel oder könnt ihr aus eigener Erfahrung sagen, was die mit Abstand wichtigsten Faktoren sind?
Ich frage mich auch z.B. ob es sich lohnt, z.B. 100 Wörter mit einem <p> - Paragraphen in eine Zeile zu schreiben statt in 5 Zeilen.
Hat so etwas überhaupt Einfluss auf die Ladezeit?
Könnt ihr mir weiterhelfen bzw. habt ihr sonst irgendwelche Tipps?

Viele Grüße, Test5000

Praktikant 14.09.2011 09:33

Bilder und eine hohe Anzahl an Anfragen verlängern die Ladezeit am meisten. Das heißt im Klartext: ausgelagerte Dateien so gut es geht zusammenfassen und bildet auf die entsprechenden Größen skalieren.

Ob du nun einen Absatz in eine Zeile oder in 10 packst ist relevant sobald du ca. 15.000 oder mehr Zeilen in der Datei hast. Text wird nicht sonderlich groß als Datei. Das hat kaum Einfluss. Selbst bei ISDN sind Textdateien in der Regel sofort da.

haggy 14.09.2011 10:36

Das ist ein interessanter Punkt, den man vielleicht auch mal als FAQ aufarbeiten könnte :)

Hier mal die - aus meiner Sicht - wichtigsten Faktoren (Praktikan hat ja bereits einige genannt):
  • Korrekte Dimensionen im img-Tag angeben - nicht per HTML skalieren
  • Bildgröße mimieren (smush.it)
  • Verwendung von CSS Sprites reduzieren Requests
  • wenn möglich: Content Delivery Network benutzen
  • JS- und CSS-Dateien zusammenfassen
  • CSS in den Kopf (Verzicht auf inline CSS!)
  • JavaScript ans Ende des Dokuments
  • CSS und JS minify'en
  • einen korrekten Document Type verwenden
  • Seiten validieren
  • keine CSS Expressions verwenden
Auf die Eigenschaften / Möglichkeiten beim Webserver gehe ich jetzt mal nicht ein. Aber so sollte das erstmal als Anhalt dienen.

Grundsätzlich ist wohl auch daran zu denken, dass man möglichst wenig DOM-Elemente verwenden sollte (keine extreme Verschachtelung von div-Containern z.B). Bei JavaScript gibts auch einige Sache zu berücksichtigen (jQuery z.B.: effektive Selektoren -> $('div.classX') statt $('.classX'); optimierung von Schleifen; Cachen von Variablen etc.).

Aber das würde wohl hier wohl den Rahmen sprengen ;)

gabischatz 14.09.2011 23:52

Hi, ich höre immer wieder
Zitat:

Verzicht auf inline CSS!
Welchen Vorteil bringt mir die Auslagerung der CSS-Daten?
Im Gegenteil stelle ich meine CSS-Daten mittels PHP korrekt zusammen so brauch der Browser weniger Daten abarbeiten und ich spare einen oder mehrere Requests.
MfG gabischatz

Praktikant 15.09.2011 00:05

Auch CSS-Dateien werden gecacht. Zudem ist es übersichtlicher. Wenn du mit IDs und Klassen arbeitest kannst du auch davon ausgehen, wiederkommende Elemente immer gleich bleiben.

Man kann im Übrigen auch CSS-Dateien von php generieren lassen.
Es hat aber nicht unbedingt etwas mit schnellerer Ladezeit zu tun, eher mit der Übersicht. Ob jetzt eine Textdatei mehr oder weniger geladen wird ist nur bedingt relevant.

haggy 15.09.2011 15:43

Ausführlichere Fassung
 
So, ich habe mich nochmal rangesetzt und die wichtigsten Faktoren für die Ladezeiten etwas näher erläutert. Worauf ich an dieser Stelle nicht eingehen möchte (aber auch gern nachreichen kann) ist die Performance von CSS und JavaScript. Ich bitte das zu entschuldigen, aber es würde sicherlich den Rahmen des Posts sprengen ;)

Bilder – Dimensionen
Skalierungen durch HTML sind nicht gut. Sie verlangsamen den Seitenaufbau erheblich. Bilder sollten entsprechend ihrer Dimensionen bereits im Vorfeld durch ein Programm (z.B. GIMP, PS) skaliert werden.

Ein schönes selbst geschossenes Bild mit der HighEnd-Kamera von der Freundin welches ihr der Welt zeigen wollt, hat z.B. die Abmaße 4960 x 3508 px (entspricht A3 bei 300 dpi). Nun soll es aber nur auf 600 x 415 px ausgegeben werden, dann wäre ein:
<img src=“freundin.jpg“ width=“600“ height=“415“ alt=“Meine hübsche Freundin“ />
ziemlich ungünstig. Also: vorher mit einem Programm herunterskalieren, das Bild wird von der Dateigröße kleiner und es lädt somit schneller. Generell sollten die Dimensionen eines Bildes natürlich im img-Tag angegeben werden, um den Bereich im Voraus zu "reservieren". Dadurch wird ein "Zucken" der Seite verhindert. (Danke an Praktikant für die Anmerkung)

Vorteile: die Bilder sehen besser aus und werden natürlich auch schneller geladen.


Bilder – Dateigröße
Bilddateien, welche mit Programmen wie GIMP oder PS erstellt werden, haben grundsätzlich erstmal einen so genannten Overhead. Es sind also Informationen in der Datei enthalten, die für das Bild unwichtig sind.

Diese Informationen können relativ über Online Services wie Smush.It entfernt werden. Die Einsparung sind erheblich. Beispiel mit einem einfachen 640 x 400 px Bild von dummyimage.com: http://dummyimage.com/600x400/000/fff.jpgsmush.it reduziert es von 12,4 KB auf 9,6 KB, Ersparnis: 22%!

Vorteile: kleinere Bilder werden schneller geladen


(CSS) Sprites
Man stelle sich vor, es soll eine Seite erstellt werden, die einen Menüaufbau ähnlich den Yahoo!-Seiten auf Yahoo! Deutschland hat (Yahoo! Deutschland). Lauter kleine lustige Symbole untereinandern (15 und mehr). Würde jedes Bild einzeln geladen, hätte man an der Stelle schon allein 15 Requests nur für das Menü - nicht gut!

Also umdenken: Sprites erstellen, Grafiken zusammenfassen. Der Technik dahinter ist relativ einfach: eine Gesamtgrafik mit allen Teilgrafiken erstellen; CSS-Klasse für die Sprite-Datei anlegen:
.mainSprite {background: #fff url(pictures/main-sprite.png) no-repeat 0 0}

Von dieser Klasse aus anderen Klasse “ableiten”. Beispielsweise eine 50 x 50 px Grafik
.articleIcon {width: 50px; height: 50px; background-position: 0 -50px}

Und in der HTML verwenden:
<span class=”mainSprite articleIcon”></span>

Interessante Artikel dazu findet man auf The Mystery Of CSS Sprites: Techniques, Tools And Tutorials - Smashing Magazine

Vorteile: weniger Requests = schnellerer Seitenaufbau; Flackern bei hover-Effekten fällt weg


CSS- und JS-Dateien vereinen und minify’en
Wie schon oben beschrieben, hängen die Requests stark mit der Ladezeit einer Seite zusammen. Das gilt selbstverstänlich auch für CSS- und JavaScript-Dateien.

Aus screen.css, layout.css, design.css, format.css etc. kann man doch auch eine Datei erstellen und auf den Server laden. Gleichermaßen sollte bei JavaScript-Dateien verfahren werden.

Ist eine CSS- oder / und JavaScript-Datei fertig, sollten diese noch minimiert werden. Es gibt hier für verschiedene Online Tools, die diese Aufgabe erledigen. Dabei werden z.B. überflüssige Leerzeichen entfernt,
aus: (CSS) margin: 0px

wird: margin: 0 etc.

Resultat ist eine Datei, die weniger Speicherplatz belegt aber noch genau so arbeitet wie vorher.

Empfehlenswert sind hier: Minify Javascript Online / Online JavaScript Packer oder Minify CSS - Compress CSS Code

Vorteile: weniger und kleinere Dateien ergeben wieder einen schnelleren Seitenaufbau


CSS an den Anfang, JS ans Ende
Wird das CSS am Anfang eines Dokuments geladen, bleiben dem Besucher unerwünschte Redraw oder Reflow-Effekte erspart.
JS am Ende eines Dokuments hat den Vorteil, dass die durch JS beinflussten DOM-Elemente nicht während des Ladens der Seite gerendert werden, was sehr unangenehm für den Benutzer werden kann (könnte das parallel Ausliefern von Files stören).

Vorteile: die Seite selbst wird schneller (samt Styles) ausgeliefert


Inline CSS vermeiden
Inline CSS ist weniger optimal, da es nicht sonderlich dem Verständis dient, erschwert die Fehlersuche und erhöht die Dateigröße der HTML-Dateien drastisch. Weiterhin kann nicht von den Vorteilen des Cachings (wie bei CSS- und JS-Dateien) profitiert werden.

Wird also eine andere (interne) Seite aufgerufen, so kann bei externen CSS- und JS-Dateien die gecachte Version genutzt werden und erhöht damit die Ladezeiten.

Vorteile: schnelleres Laden durch Caching (Minimierung der Requests)


Document Type wählen
Ok … hier ist ein Punkt der nicht direkt mit den Ladezeiten einer Seite zu tun hat. Aber empfehlens ist es trotzdem!

Vorteile: ein korrekter Doctype erhöht die Crossbrowser-Kompatibilität


Validierung der Seiten
Auch noch ein Punkt, der nicht mit den Ladezeiten zusammenhängt.

Trotzdem ist es empfehlenswert sich an die Richtlinien des W3C zu halten. Nicht umsonst wurden diese irgendwann mal aufgestellt.

Es kommt vor, dass ein Benutzer eine Internetseite auf Qualität prüft - um eventuell Rückschluss auf die Qualität des Herausgebers zu ziehen. Eine valide Website ist also stets auch ein Indikator für die Qualität des Webdesigners - und gute Reputation kann wohl jeder gebrauchen ;)


Verzicht auf CSS-Expressions
Erster Fakt der gegen die Verwendung spricht: sie gehören nicht zum Standard! Und es gehört einfach nicht zum guten Ton CSS mit Programmlogik zu verknüpfen (wir erinnern uns: CSS soll Inhalt (und Logik) von Gestaltung trennen).

Darüberhinaus sind CSS Expressions um einiges langsam beim rendern von Inhalten als reines CSS.

Vorteile: schnellerer Seitenaufbau bei Verzicht auf Expressions


Fragen, Kritik und Anmerkungen sind selbstverständlich willkommen und bei Fehler bitte ich um harte aber gerechte Strafe :)

Verwendete Literatur: The Smashing Book, 1. Auflage (2009)

Praktikant 15.09.2011 16:16

Zitat:

Zitat von haggy (Beitrag 502416)
CSS an den Anfang, JS ans Ende
Wird das CSS am Anfang eines Dokuments geladen, bleiben dem Besucher unerwünschte Redraw oder Reflow-Effekte erspart.

Daher du hier Reflow oder Redraw Effekte ansprichst, die nicht viel mehr als "ein Zucken der Seite" meinen sollte man Folgenden Punkt zwar beachten, aber die Größenangaben der Bilder trotzdem machen. Denn auch diese ersparen dem Benutzer "ein Zucken der Seite", vor allem wenn der schon den Text ließt während die Bilder noch laden.
Zitat:

Zitat von haggy (Beitrag 502416)
Ein schönes selbst geschossenes Bild mit der HighEnd-Kamera von der Freundin welches ihr der Welt zeigen wollt, hat z.B. die Abmaße 4960 x 3508 px (entspricht A3 bei 300 dpi). Nun soll es aber nur auf 600 x 415 px ausgegeben werden, dann wäre ein:
<img src=“freundin.jpg“ width=“600“ height=“415“ alt=“Meine hübsche Freundin“ />
ziemlich ungünstig. Also: vorher mit einem Programm herunterskalieren, das Bild wird von der Dateigröße kleiner und es lädt somit schneller.

Der Rest ist aber soweit nicht sonderlich zu bemängeln.

haggy 15.09.2011 16:48

Zitat:

Zitat von Praktikant (Beitrag 502420)
[...] aber die Größenangaben der Bilder trotzdem machen. Denn auch diese ersparen dem Benutzer "ein Zucken der Seite", vor allem wenn der schon den Text ließt während die Bilder noch laden.

Oh ja, gute Anmerkung. Das hatte ich vergessen zu erwähnen. Danke für den Hinweis :)

Test5000 15.09.2011 18:49

Okay vielen Dank für eure Antworten, da habe ich ja schon mal einige Anhaltspunkte... :)
Da muss ich mich wohl etwas mehr mit CSS beschäftigen :P

EvT 15.09.2011 20:19

Mit den in modernen Browsern vorhandenen Entwicklertools kann die Übertragungsgeschwindigkeit der einzelnen Komponenten einer Seite gemessen werden. Mit diesen Tools kann man sehr genau feststellen, wie sich was auswirkt und sieht wo die Engpässe sitzen.

Edit: Gut ist es, solche Tests gerade auch mit langsamen Netz-Verbindungen durchzuführen.

haggy 16.09.2011 08:59

EvT, das stimmt. Allerdings machen solche Tests auch wirklich nur dann Sinn, wenn die Seite(n) auf dem letztendlichen Server liegen. Bei lokalen Entwicklungen - ich vermute mal, dass das hier im Forum nicht wenige sein werden - sollte man lieber schon im Entwicklungsprozess auf die Ladezeiten durch die oben genannten Punkte achten :)

Aber per se sollte man solche Tests natürlich regelmäßig machen. Ein nettes Plugin ist hier YSlow für den FireFox der sich an die Performanceregeln von Yahoo! hält.

fricca 16.09.2011 09:23

Ich kann die Bücher von Steve Souders empfehlen. High Performance Websites und Even Faster Websites.

David 11.10.2011 15:24

Hab ich's überlesen, oder fehlt es einfach? Daten vom Typ text/* kann man vor dem Versenden komprimieren. Das schlägt vor allem bei JS Frameworks und großen Stylesheets zu Buche.

Data-URIs können das CSS-Sprite unter Umständen komplett ersetzen.

haggy 11.10.2011 18:22

Es kommt jetzt wohl drauf an ... komprimieren kannst du vorher (das erwähnte "minify'en", oder es dem Server erledigen lassen. Letzteres hatte ich nicht mit angeführt, da das wohl vielleicht etwas sehr technisch ist.

Data URIs sind auch eine tolle Sache, das stimmt. Wobei ich mir gerade bei einer Sprite nicht so sicher bin, ob der Einsatz von Data URIs da Sinn macht. Google beispielsweise lädt die Sprites auch auf konventionellem Weg ;)

hereandnow 14.10.2011 21:44

Firebug plugin yslow installieren. Der sagt dir was schlecht ist, mit links auf Artikel wie es besser geht

inta 14.10.2011 22:32

Aber unbedingt selbst überlegen welche Hinweise sinnvoll sind und welche nicht, bloß nicht stumpf alles "verbessern" was Yslow, Pagespeed & Co vorschlagen. Die beiden Tools sind für große Projekte mit mehreren Servern ausgelegt, nicht jede "Optimierung" gilt auch für kleinere Umgebungen.

sambuca89 22.11.2011 16:41

Hallo,

es wurde geschrieben, dass die Validierung von Webseiten nicht mit der Ladezeit zusammenhängt.

Hier muss ich widersprechen:

Validierungsfehler müssen von Browsern erst korrigiert werden, was auch Zeit kosten kann. Oder irre ich mich?

Danke im Voraus.

sambuca89

mermshaus 23.11.2011 11:16

Der Aussage, dass Validierungsfehler die Ladezeit beeinträchtigen können, ist wohl schwer zu widersprechen. Das mag von der konkreten Implementierung abhängen. Ich glaube aber nicht, dass die möglichen Einbußen im Regelfall spürbar sind.

Es ist abgesehen davon aber völlig sinnlos, über sowas nachzudenken. Niemand sollte ernsthaft erwägen, bewusst falsches Markup zu erstellen. Solche Überlegungen sind der erste Schritt zu absurden Mikrooptimierungen im Stile von: „Ich nutze Arial, denn die Schriftart hat im Schnitt weniger Vektoren und kann deshalb schneller gerendert werden.“

protonenbeschleuniger 23.11.2011 11:18

Zitat:

Zitat von sambuca89 (Beitrag 506090)
Validierungsfehler müssen von Browsern erst korrigiert werden, was auch Zeit kosten kann. Oder irre ich mich?

Ja du irrst. Ein valides Dokument, kann syntaktisch völlig falsch sein. Daher sind eher Fehler die in der Fehlerkonsole angezeigt werden ein Problem. Validität interessiert den Browser eher weniger.

upasem 17.12.2011 01:00

Ich empfehle zum testen der Ladezeiten die Google Webmaster Tools zu verwenden. Das Tools PageSpeed. Gute Webseiten schneiden hier mit 80 oder mehr Punkten von 100 ab.

Hast du gzip auf deinem Server verfügbar?

Webstandard 03.05.2012 22:09

In Bezug auf die Verbesserung der Performance stellen oftmals die verwendeten Bilder das größte Einsparpotential dar. Mit der hier bereits angesprochen Browser-Extension YSlow kann man die Ladezeit von Webseiten spürbar verbessern, da damit die Bilder mit einer Dateikomprimierung teilweise sehr stark optimiert werden können.

Die Anleitung des verlinkten Artikels sollte schnell zu ersten Erfolgen führen können.

Viel Erfolg dabei!

irmen 28.09.2012 08:59

Hallo,
ich hätte zum unschönen Übergang zwischen den Seiten die Frage,
was ich davon halten soll, daß die seite zwar in ff, chrome und safari gut aussieht, das heißt die Hintergrundbilder bleiben stehen und nur was sich ändert wird geladen - passt soweit - ABER im IE sieht es unmöglich aus.

Bei jedem Seitenwechsel verschwinden alle Hintergrundbilder der dunkle bodybackground wird sichtbar und dann klatscht sich der helle contenthintergrund wieder drüber. Gibt es eine Möglichkeit, das auszubügeln?
Die Hintergründe sind alle in der css definiert und die wird ganz am Anfang geladen.

vielen Dank für einen tipp!
Irmen

protonenbeschleuniger 28.09.2012 09:52

So ist das Internet.
Jemand der einen IE benutzt wird das vermutlich auf jeder Seite so sehen, es wird ihn also nicht stören. Es stört ja nur dich, weil du es nicht gewohnt bist.

mermshaus 29.09.2012 22:38

Ja, würde ich auch sagen. Aber bitte in Zukunft für neue Fragen einen neuen Thread erstellen.

Luisa777 31.10.2012 09:44

Zitat:

Zitat von Webstandard (Beitrag 515758)
Mit der hier bereits angesprochen Browser-Extension YSlow kann man die Ladezeit von Webseiten spürbar verbessern, da damit die Bilder mit einer Dateikomprimierung teilweise sehr stark optimiert werden können.

Die Anleitung des verlinkten Artikels sollte schnell zu ersten Erfolgen führen können.

Viel Erfolg dabei!

Ein toller Tipp, den ich momentan gut gebrauchen kann :D

Danke,
Luisa

verlagi 13.12.2012 08:53

Hmm..
 
Hallo, könnte jemand genauer erklären wie das funktioniert? Wird die Datei zeitweise stark verkleinert?

gabischatz 13.12.2012 15:25

Zitat:

Zitat von verlagi (Beitrag 523752)
Hallo, könnte jemand genauer erklären wie das funktioniert? Wird die Datei zeitweise stark verkleinert?

Nein. Es gibt verschiedene Tools mit denen man die Ladezeit von Dateien messen kann.
Ob du nun Photoshop, Gimp oder IrfanView zum verkleinern von Bildern nimmst hängt von deinem Geldbeutel bzw. Verständnis für das jeweilige Programm ab.

Bilder werden für die Anzeige neu erstellt, so das beim laden des Bildes der Browser nicht die Bilder neu berechnen muss.
JS -Dateien werden erst zum Schluss geladen usw. Siehe die ersten Posts zu diesen Thema.
MfG gabischatz

DanTan 12.03.2013 14:26

Grundsätzlich würde ich echt immer Bilder verkleinern. Gerade bei vielen Wordpress Blogs fällt auf, dass die Grafiken in groß geladen werden, der Code sie aber verkleinert. Das ist natürlich ein Hinderniss (vor allem wenn man die Seite mit dem Smartphone etc besucht).

Q Webdesigner Darmstadt 11.06.2013 13:25

Zur Ergänzung noch folgende Tipps:

- Ladereihenfolge beachten:
Werden Bilder über CSS aufgerufen (z.B. Hintergrundbilder), werden diese üblicherweise nach dem Laden der aus dem HTML aufgerufenen Bilder geladen.
Also große Bilder entsprechend ins CSS auslagern.
Das hilft natürlich nichts für die tatsächliche Ladezeit, jedoch sieht der menschliche Seitenbesucher schneller die restlichen Inhalte, bevor das entsprechende Bild nachgeladen wird (gefühlt schneller).

- Ein Bild, das z.B. ein Foto und einen Schriftzug enthält, und das wegen des Textes nicht so stark komprimiert werden kann (weil der Text beim Komprimieren unscharf wird), kann man gut aufteilen in zwei Bilder (nebeneinander oder auch übereinander).

mermshaus 11.06.2013 14:24

Die Tipps finde ich beide semantisch fragwürdig.

Wenn ein Bild Content ist, ist es Content. Dann sollte es auch in einem img-Element stehen. Ansonsten eben per CSS. Die Entscheidung von der Bildgröße abhängig zu machen, halte ich für falsch.

Die zweite Sache kann man mit Abstrichen sicherlich so machen. Wirklich glücklich bin ich damit prinzipiell aber nicht, denn grundsätzlich sind Bild+Schriftzug entweder eine Einheit oder sie sind keine. In beiden Fällen stellt sich die Frage einer etwaigen Aufteilung dann gar nicht. Auch hier würde ich primär von semantischen Aspekten ausgehen.

Q Webdesigner Darmstadt 11.06.2013 15:15

Vielen Dank für Deine ergänzenden Einschätzungen. Das Thema Semantik hat sicherlich einen eigenen Beitrag verdient.
Die von mir aufgezeigten Möglichkeiten sind Möglichkeiten. Und zwar Möglichkeiten, die man tatsächlich nicht von Haus aus so umsetzen sollte.

mymaksimus 25.08.2013 11:32

Zitat:

Zitat von haggy (Beitrag 502416)
Verzicht auf CSS-Expressions
Erster Fakt der gegen die Verwendung spricht: sie gehören nicht zum Standard! Und es gehört einfach nicht zum guten Ton CSS mit Programmlogik zu verknüpfen (wir erinnern uns: CSS soll Inhalt (und Logik) von Gestaltung trennen).

Darüberhinaus sind CSS Expressions um einiges langsam beim rendern von Inhalten als reines CSS.
Vorteile: schnellerer Seitenaufbau bei Verzicht auf Expressions

Das würde ich nicht so sehen. Hier wird das ganz gut erklärt, denn das eigentlich problem sind nicht die expressions selber, sondern das diese ziemlich oft neugeladen werden müssen. Das lesst sich aber mit runtimeStyle ziemlich gut umgehen.

lottikarotti 27.08.2013 10:36

Morgen,

Zitat:

Zitat von mymaksimus (Beitrag 532512)
Das würde ich nicht so sehen. Hier wird das ganz gut erklärt, denn das eigentlich problem sind nicht die expressions selber, sondern das diese ziemlich oft neugeladen werden müssen.

Was die CSS-Expressions wiederum zum Problem macht. Ganz nebenbei bemerkt, fällt mir auch kein konkreter Anwendungsfall ein, den man nicht ohne CSS-Expressions lösen könnte.

Viele Grüße,
lotti

mermshaus 27.08.2013 11:48

Im ersten Satz des verlinkten Artikels steht:

Zitat:

Mit CSS-Expressions kann man in alten Internet Explorern bis Version 7 JScript (Microsofts JavaScript-Variante) in CSS notieren und damit Werte von CSS-Eigenschaften berechnen. Auf diese Weise lassen sich CSS-Darstellungsangaben, die alte IEs nicht interpretieren, auch in alten IEs umsetzen.
[Hervorhebung hinzugefügt.]

Ich glaube nicht, dass das Thema 2013 noch so wahnsinnig relevant ist. ;)

mymaksimus 30.08.2013 00:07

Zitat:

Zitat von mermshaus (Beitrag 532565)
Im ersten Satz des verlinkten Artikels steht:



[Hervorhebung hinzugefügt.]

Ich glaube nicht, dass das Thema 2013 noch so wahnsinnig relevant ist. ;)

Stimmt auch wieder :mrgreen:

freako 28.05.2014 15:21

Gibt ja viele Onpage Optimierung Tool die dir sagen was du noch optimieren

Leo80 30.09.2014 10:55

Erst einmal vielen Dank für die vielen Anregungen und neuen Einblicke, die ich vorher noch nicht kannte.

Zitat:

Zitat von freako (Beitrag 539436)
Gibt ja viele Onpage Optimierung Tool die dir sagen was du noch optimieren

Kannst du welche empfehlen?

mermshaus 04.10.2014 02:18

Dann aber bitte mit mehr Grammatik. ;)

Mir fallen spontan diese ein:

- https://developers.google.com/speed/pagespeed/
- YSlow - Official Open Source Project Website
- Nibbler - Test any website

charles 30.10.2014 16:15

Zitat:

Zitat von mermshaus (Beitrag 541424)

cool danke

Sabine1 08.02.2022 14:24

Wie stellt man eigentlich fest, welche Dateien durch gzip komprimiert wurden und welche nicht?

Beim Test mit https://tools.pingdom.com/ wird mir angezeigt, dass nicht alles komprimiert ist


Alle Zeitangaben in WEZ +2. Es ist jetzt 08:12 Uhr.

Powered by vBulletin® Version 3.8.11 (Deutsch)
Copyright ©2000 - 2024, vBulletin Solutions, Inc.

© Dirk H. 2003 - 2023