Seite "kleiner machen"!?

[SeriousBadMan]

Hi,

ich hab mal wieder 'ne Frage. Hab ne wunderschöne Website kreeiert und habe nun große Probleme mit der Ladezeit. Die ist viel zu lang, da springt die Hälfte der teuren Adwords Besucher wieder ab. Das liegt zum einen an den vielen Designelementen die sich nur mit Bildern realisieren ließen, zum anderen an der eingebauten Slideshow mit Bildern (alles .png bisher). Ansonsten ist der Code eig. schlank, wie gesagt nur die Bilder sind halt's Problem...

1. Empfiehlt sich eine Komprimierung der gesamten Website mit gzip? (hat da jmd. nen Link wo erklärt wird, wie's geht?)
2. Oder wäre es am effektivsten und einfachsten die Bilder erstma' in JPEG zu verwandeln und zu schaun, ob's jetzt passt mit der Ladezeit?
3. Gibt's noch andere Alternativen außer den beiden?

[Hobby_SEO79]

nenn mal ruhig deine website. Dann kann man das mal nach elementen auseinader nehmen.

Quellcodegröße ist heut meist das geringste Übel. Würde Bilder grundsätzlich fürs Web als jpg empfehlen. mit png hat so mancher IE n Problem und gifs sind für heutige Standards einfach überholt. Das nur grundsätzlich.

nochmal kurz n Gedanke:
Ich weiss, dass ich mit meiner Website keine modem user ranbekomm, weil die Ladezeiten zu hoch. Standardanwendungen (connections) schaffens aber meine Site relativ in kurzer Zeit zu laden ..... ich leg also mehr Wert aufs Laden von Grafiken und den damit verbundenen Zeiten, als auf jederzeitigen Zugriff. Klär die Frage auch mal für dich!

Ich arbeite derzeit auf ein Erstladen von 200 KB hin .....drüber muss man größere Abstriche an Besuchergeduld machen, drunter an Website-Quali.

Das so mal als tendenzielel Aussage. Muss man immer individuell abwägen ....

[grossy]

1. Zippen bringt bei Bilderlast!! rein gar nichts
2. png->jpg kann ne menge bringen, wenn es sich um Photos handelt
2.1. png/gif verwendet man, wenn es sich um Grafiken handelt, die mit einem Rechner erstellt wurden (einfach ausgedrückt)

Hier mal ein paar "Größen": (mit eingeschaltetem adblocker)

gmx.de Total:223 KB (577 KB uncompressed)
web.de Total:249 KB (589 KB uncompressed)
yahoo.com Total:249 KB (479 KB uncompressed)
amazon.com Total:350 KB (599 KB uncompressed)

[mgutt]

wunderschöne Website

Vielleicht liegts daran. Hast Du das Grunddesign schon viel Bildern realisiert? Kannst Du da nicht noch abspecken?

Ansonsten wie schon gesagt wurde die Bilder besser komprimieren z.B. JPEG mit 70-80% Qualität.

[Mork vom Ork]

1. Empfiehlt sich eine Komprimierung der gesamten Website mit gzip? (hat da jmd. nen Link wo erklärt wird, wie's geht?)

Bei allem, was in Textform daherkommt, eigentlich immer, schließlich wird das Volumen kleiner, gerne auch auf ein Zehntel, ohne, dass etwas verloren geht. Komprimierung von Bildern mit gzip ist natürlich Unsinn, PNG und JPG komprimieren bereits und wären schlechte Algorithmen, wenn sich das Ergebnis noch weiter komprimieren ließe.

Wie du die HTTP-Kompression aktivierst, hängt von deinem Webserver ab. Prüfe erstmal, ob sie nicht schon aktiv ist: Besorge dir für Firefox die Erweiterung LiveHTTPHeaders. Nach dem Aufruf deiner Seite findest du bei den Seiteninformationen einen zusätzlichen Reiter namens Header; ist dort unter Antwort Content-Encoding: gzip (oder deflate) aufgeführt, brauchst du dich um nichts weiter zu kümmern.

Falls nicht: Bei Apache 2 ist häufig das Modul mod_deflate vorhanden. Wenn es nicht eh schon aktiviert ist, reicht die Zeile AddOutputFilterByType deflate text/plain text/html text/css text/javascript in der obersten .htaccess.

Falls mod_deflate nicht nutzbar ist, kannst du bei von PHP ausgegebenen Daten die Option zlib.output-compression benutzen, sie führt zum gleichen Ergebnis. (Das gleichzeitige Aktivieren von mod_deflate und zlib macht keinen Sinn, belasse es bei mod_deflate.)

Hast du statische Dateien, könntest du sie auch bzw. zusätzlich zu mod_deflate manuell mit gzip komprimieren. Du legst dann statt einer Datei zwei auf dem Server ab, zB grosses_skript.js.js und grosses_skript.js.gz (beachte bei beiden die zweifache Dateiendung!). Aktivierst du die Option Multiviews, sucht sich der Server beim Aufruf von grosses_skript.js (beachte die einfache Dateiendung!) die passende von den beiden vorhanden aus.
Kleiner Stolperstein: Auf manchen Servern ist die Endung .gz mit einem Datentyp und nicht mit einer Kodierung verknüpft. In dem Fall hilft RemoveType .gz, gefolgt von AddEncoding gzip .gz in der .htaccess.
Diese Methode funktioniert mit allen Dateien; jeweils eine unkomprimierte mit verdoppelter Dateiendung (.html.html, .css.css, etc) und eine komprimierte mit normaler Endung plus .gz (.html.gz, .css.gz, etc).
Der Sinn der doppelten Endungen liegt darin, dass das Modul mod_negotiation, das für die Auswahl verantwortlich ist, nur in Aktion tritt, wenn unter der angefragten URL nichts gefunden wird.

[ole1210]

Am Server liegts nicht? Das beispirlsweise die DB zu langsam ist? Ist die reine Größe?

Wieviele kB sinds dennn?

[Anonymous]

slideshow im quelltext nach "unten" schieben.
designelemente versuchen durch wiederholungen aufzubauen (repeat-x y)
möglichst viel in die css auslagern.

[Malte Landwehr]

Bilder auf Amazon S3 auslagern?

[mgutt]

Sich abhängig von Dritten machen? Welchen Vorteil soll das bringen?

[SeriousBadMan]

das ist ja interessant, die amazon infrastr. services kannte ich gar nicht.

danke euch allen.

habe die .PNGs soweit möglich in .JPGs verwandelt, und jetzt ist die ladezeit, wenn auch immernoch hoch, immerhin akzeptabel.

gibt halt zwei PNGs als Designelemente, die sich nicht verwandeln lassen, da sie mit teilweiser Transparenz arbeiten und .GIF das ja nicht kann. aber trotzdem danke euch allen, hat schon sehr geholfen.

[wehwehweh]

vielleicht kannst du was mit geringerer aualität vorladen und dann höhere qualität nachladen.

Würde Bilder grundsätzlich fürs Web als jpg empfehlen. mit png hat so mancher IE n Problem und gifs sind für heutige Standards einfach überholt.

hab ich was versäumt?

[mgutt]

Halbtransparente PNGs sind für den IE ein Problem. Sehen schick aus, verursachen in den IE-Versionen aber grausige Ergebnisse. Dafür gibts JS-Klassen, aber die funktionierten bei meinen Tests genauso wenig

Ich würde für solche Effekte vielleicht auf Flash zurückgreifen. Da gibts dann nur geht und geht nicht und nicht irgendwas dazwischen wie bei PNG.

[Malte Landwehr]

Sich abhängig von Dritten machen?

Von dritten bist du immer Abhängig oder bist du dein eigener Webhoster mit eigenem Server im eigenen RZ und eigenen Peerings zu wirklich allen relevanten Stellen?

Welchen Vorteil soll das bringen?

Eine schnellere Ladezeit seiner Website. Weniger Probleme mit Trafficspitzen, usw.

[Mork vom Ork]

Halbtransparente PNGs sind für den IE ein Problem. Sehen schick aus, verursachen in den IE-Versionen aber grausige Ergebnisse.

Das gilt seit IE 7 nicht mehr und beim IE 6 nur, wenn man im PNG keine Hintergrundfarbe setzt (mit Farbe wird aus dem „grausig“ ein „akzeptabel“ bis „kaum zu erkennen“). Und wer mit noch älteren Browsern unterwegs ist, hat ganz andere Probleme.

[mgutt]

Sich abhängig von Dritten machen?

Von dritten bist du immer Abhängig oder bist du dein eigener Webhoster mit eigenem Server im eigenen RZ und eigenen Peerings zu wirklich allen relevanten Stellen?

Wenn ich von einer Abhängigkeit spreche, dann meine ich damit vor allen Dingen eine rechtliche. Ansonsten fallen alle bekannten Maßnahmen weg, wie Zusicherung der Verfügbarkeit, Schadensersatz, direkte Ansprechpartner, Kontrolle über den Speicherort, usw.

Weiterhin ist es rechtlich bedenklich und einfach nur gewissenlos, einem Dritten die eigenen Besucherdaten zu übermitteln.

Ich behaupte mal frech, dass Amazon den Dienst nur deswegen so günstig anbietet.

Welchen Vorteil soll das bringen?

Eine schnellere Ladezeit seiner Website. Weniger Probleme mit Trafficspitzen, usw.[/quote]
Das hängt vom Geldbeutel ab. Und jeder Dienst wird irgendwann in die Knie gezwungen. S3 schon öfter, was man an zahlreichen Berichten nachvollziehen kann. Mal davon abgesehen kostet S3 Geld. Und zwar pro Gigabyte. Nichts ist dümmer als ein kleines Projekt so zu betreiben. Ein TV-Bericht oder eine Twitter-Welle und Du bist arm dran.