|
Wer eine eigene Website oder Blog betreibt, möchte in der Regel, dass viele Besucher auf die Website kommen, die Artikel lesen und im Falle eines Shop vielleicht etwas kaufen. Getreu dem Mittel “Viel hilft viel” wird dann die Website mit allen möglichen Bildern, Widgets und Multimedia voll gepackt. Doch die Folge ist, dass das nicht nur die User abschreckt, sondern auch die Ladezeit der Website massiv erhöht. Auch wenn die Internetzugänge größtenteils recht schnell sind, dauert es doch recht lange bis eine voll gestopfte Website geladen wird. Die Folge ist, dass die Besucher gar nicht abwarten bis die Seite vollständig geladen ist und wieder weiter surfen.
1.Website auf Geschwindigkeit optimieren
Eine schnelle Website zieht Besucher an und wird auch von Google als wertiger angesehen. Die wichtigsten Einstellungen des Servers sind das Browsercaching, das Sie über mod_expires oder die .htaccess einstellen können, und die Komprimierung der Daten während der Übertragung (Gzip-Komprimierung). Optimieren Sie alle Bilder der Website (auch die im Layout) hinsichtlich der Speichergröße um die Website zu optimieren. Das Ziel ist nicht den Speicherplatz des Servers zu schonen sondern das Datenvolumen für die Übertragung dieser Dateien zu reduzieren.
2.Ballast abwerfen
Schauen Sie sich kritisch Ihre Website an und stellen sich die Frage “Ist das wichtig?”. Streichen Sie überflüssige grafische Elemente. Reduzieren Sie weiterführende Links auf ein gesundes Minimum. Der User muss schnell erkennen wo er etwas Interessantes finden kann und wird nicht lange suchen! Gerade Facebook-Widgets und JavaScript-Spielereien verzögern den Seitenaufbau einer Website enorm. Beschränken Sie sich auch hier auf das Wichtigste. Wenn Sie Ihre User auf etwas hinweisen möchten schreiben Sie einen Artikel.
3.Website analysieren
Um den Status der eigenen Website zu beurteilen bieten sich Webmaster-Tools wie Page Speed an, die einem ziemlich genau die Schwächen aufzeigen. Wenn die Website trotzdem zu langsam ist kann ein schnellerer Webserver helfen;-)
GD Star Rating
loading...
Website schneller machen, 4.5 out of 5 based on 2 ratings
Google+
|
Januar 9th, 2012 at 06:30
Das ist wohl ein kleines bisschen unglücklich…
Die Tipps sind schon OK. Vor allem das Ballast abwerfen. Nur – hier wirkt der Artikel ein bisschen “fehl am Platz”. Jedenfalls für mich. Ladezeit (GTmetrix) Mittelwert etwa 18 Sekunden.
Das ist ganz einfach langsam. Zu langsam
loading...
Januar 9th, 2012 at 19:27
Hallo Waelti,
bei dem Artikel handelt es sich um einen Gastartikel, aber ich als Admin werde mir Deinen Hinweis zu Herzen nehmen!
Die lange Ladezeit hängt sicher auch mit den vielen Bildern zusammen? Diese sind aber nunmal für die Anleitungen wichtig… Für Hinweise bin ich aber immer dankbar!
Habe einen großen “Sünder” rausgenommen. Ladezeit liegt nun bei 7.24s .
admin
loading...
Januar 9th, 2012 at 20:01
Erstmal – vielen Dank für’s freischalten. Habe ich auch schon anders erlebt.
Dass es ein Gastartikel ist hatte ich gesehen. (Deshalb das “hier” wirkt der Artikel ein bisschen…)
Ja, die Ladezeit ist heute um Klassen besser.
Es sind viele kleine Teile die verbessert werden könnten. Ob das nötig ist, das weiß ich nicht – wie gesagt: heute ist die PageSpeed sehr viel besser.
Die Bilder ein bisschen besser komprimieren. Und vor allem ein “expire” Datum angeben. Webpagetest brauchte für die “erneute” Verbindung (das, was normal aus einem Browsercache kommen könnte) *länger* als für die erste Verbindung.
Mod_expire – sofern das auf dem Server funzt – wäre wohl eine schnelle und einfache Verbesserung. Vor allem für wiederkehrende Leser.
Nochmals Danke. Und die schnelle Verbesserung ist auch kein Standard. Dickes Lob
loading...
Januar 9th, 2012 at 20:24
Das Freischalten von “sinnvollen Kommentaren” ist elementarer Bestandteil dieser Seite
Wenn ich die Funktionen “expire” Datum und Mod_expire verstanden habe, bzw. ich mich da durchgelesen habe, werde ich das mal in Angriff nehmen.
Thx, Hendrik
loading...
Januar 12th, 2012 at 14:48
mod_expired bzw Browsercaching hilft Dir schon auf der zweiten besuchten Seite des Users, wenn das Theme / Layout / Seitenelemente schon mal geladen sind, und im Browsercache warten;-)
loading...
Januar 26th, 2012 at 02:45
Generell kann ich beim Einsatz eines CMS nur dazu raten auf Caching zu setzen. Für die meisten Content Management Systeme gibt es spezielle Caching-Plugins die aus den dynamischen Seiten mehr oder minder statische Webseiten machen. Das bringt sehr viel Geschwindigkeit wenn man korrekte Einstellungen nutzt.
loading...
Januar 27th, 2012 at 04:30
Schön und gut mit dem Caching-Plugin. Das entlastet den Server, HTML wird schneller ausgeliefert, klar.
Ändert nix an der Größe der Seite (Grafiken etc.), ändert nix an der Anzahl der Elemente/Verbindungen und ändert nix am lokalen Cache beim Benutzer. Der, wie Aristocat richtig hinzugefügt hat, schon bei der zweiten Seite “wirkt”.
*Nachdem* die anderen Punkte optimiert sind macht ein Cache-Plugin Sinn. Vorher? Hm, häufig Augenwischerei.
loading...
Januar 27th, 2012 at 20:24
Am meisten werden hier die Bilder “schuld” an der Geschwindigkeit sein. Die Meisten rechne ich mit IrfanView runter. Allerdings leidet ab einem Bestimmten Punkt die Qualität der Bilder. Ein runter gerechnetes Bild hat dann immer noch 40-50kb. Manche Anleitungen haben 10 Bilder…
Gibts da noch ne andere Möglichkeit, die Bilder noch kleiner zu machen – bei trotzdem ansprechender Qualität? Damit könnte man dann doch die Webseite wieder etwas schneller machen.
Wo genau wird denn “expire” Datum angegeben?
loading...
Januar 28th, 2012 at 03:31
Das sind zwei – ziemlich ähnliche Einträge für die .htaccess
Einmal – der Wert Axxxx, das sind Sekunden.
Im unteren Beispiel, hm, mehr “Klartext”.
An der IfModule Abfrage ist ersichtlich:
wenn im Apache nicht aktiviert, dann macht das
garnix. Keine Veränderung.
Der CSS Eintrag (im Ersten Beispiel) ist erst zu empfehlen,
wenn keine aktuellen Änderungen am Design durchgeführt werden.
Theoretisch wird sonst das Design beim Benutzer nicht geändert
bis eben die 30 Tage rum sind.
… oder F5/Reload gemacht wird
LG
P.S.: Die Zeiten könnten – gerade zu Beginn, beim Testen -
natürlich erstmal deutlich niedriger angesetzt werden.
Beispielsweise A86400 = 1 Tag. Wer heute auf verschiedenen
Seiten stöbert, der erhält z.B. ab der 2.ten Seite das Logo aus
dem Cache. Morgen müsste dann das Bild erst wieder neu
geladen werden.
So etwa
P.P.S.: Beispielsweise das gecachte Javascript im ersten Beispiel
betrifft *nur JS Dateien* auf dem eigenen Server. Nicht z.B. Google
oder FaceBook oder sonstige eingebundene JS. Das wird extern geregelt.
——
Version 1
——
ExpiresActive On
ExpiresDefault A300
ExpiresByType image/gif A2592000
ExpiresByType image/png A2592000
ExpiresByType image/jpg A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/ico A2592000
ExpiresByType text/css A2592000
ExpiresByType text/javascript A2592000
—–
Version 2
—–
ExpiresActive On
ExpiresDefault “access plus 300 seconds”
ExpiresByType image/gif “access plus 1 month 1 hour”
ExpiresByType image/jpg “access plus 1 month 1 hour”
ExpiresByType image/jpeg “access plus 1 month 1 hour”
ExpiresByType image/png “access plus 1 month 1 hour”
ExpiresByType application/x-shockwave-flash “access plus 1 day 1 hour”
loading...
Januar 28th, 2012 at 03:33
Vielleicht siehst Du die If Abfrage, bei meiner Kommetar-Vorschau hat der Parser das gefressen…
Start
“”
Schluss
“”
loading...