Schlagwort-Archive: Performance

Beschleunigter Blog

Nachdem ich heute bei Peruns Weblog Möglichkeiten zur Optimierung der Ladezeiten am Blog gefunden habe, habe ich die Änderungen gleich mal hier eingebunden.

Nachdem aber das Firebug-AddIn »YSlow« danach noch immer gemeckert hat, das etwaige JS-Scripte und CSS-Dateien angeblich nicht komprimiert übertragen werden habe ich zusätzlich noch einen MIME-Type spezifischen Filter (in Rot) hinzugefügt.


# mod_deflate (gzip) aktivieren
<filesmatch "\\.(js|css|html|htm|php|xml)$">
SetOutputFilter DEFLATE
</filesmatch>

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript

# ExpiresHeader: verhindert bedingte GET-Anfragen
<ifmodule mod_expires.c>
ExpiresActive on
ExpiresDefault "access plus 35 days"
</ifmodule>

Laut YSlow werden durch die Einstellungen jetzt pro Seitenaufruf (bei leerem) Browser-Cache um ein Drittel weniger Volumen übertragen als vorher. Durch die zusätzliche ExpiresDefault "access plus 35 days" Einstellung, werden nun die meisten Objekte auf der Seite nicht jedesmal wieder vom Server geladen, sondern erstmal aus dem Cache geladen, somit werden bei einem Reload der Seite insgesamt weniger als 100kb Traffic erzeugt.

Ich hoffe, dass die Optimierungen nun langfristig bei den bislang immer wiederkehrenden Performance- und Ladezeitproblemen Abhilfe schaffen. Warten wir es mal ab…

Ausge(wp-)grinst

In der letzten Zeit fällt mir auf, dass das Laden der Webseite ständig zäher wird.

Das hat zum einen damit zu tun, dass ich in der jüngeren Vergangenheit das eine oder andere neue Plugin aktiviert habe, zum anderen dass offensichtlich mein Webspace-Provider ebenfalls erhebliche Antwortzeitprobleme aufweist.

Anhand des Firefox Plugins „Load Time Analyzer“ stellte ich fest, dass es zunächst teilweise 5, in Ausnahmefällen sogar 10 (!!!) Sekunden dauert, bis sich der Webserver überhaupt meldet (da kann ich aber erstmal nichts dran machen) und dann im Laufe des Seitenaufbaus nochmal erheblich Zeit vertrödelt wird um bestimmte Dateien und Skripte abzuarbeiten.

Ein bestimmtes Skript stach dabei massiv ins Auge und betraf das Laden der prototype.js (ca. 80 KB), welche durch das Plugin „WP-Grins“ (von WordPress-Mitentwickler Alex King) bei JEDEM Seitenaufruf – unabhängig ob auf der Seite ein Kommentarfeld mit klickbaren Smilies angezeigt wird oder nicht – neu geladen wird.

Aus dem Grund recherchierte ich nach einer Alternative zu WP-Grins und kam so einem Beitrag „Smiley-Skript austauschen“ auf »Peruns Weblog«. Mit dem dort beschriebenen Alternativskript „Smiley JS Button“ werden für die klickbare Anzeige der Smilies in den Kommentaren keine 80 KB geladen sondern nur etwa 3-4 KB — und die auch nur, wenn die Seite ein Kommetarfeld aufweist.

Auf Umfang der angezeigten Smilies hat dies keine Auswirkung, ich bekomme nachwievor alle — auch meine eigenen hinzugefügten — angezeigt. Ich kann nun sogar steuern, WO die Smilies jetzt beim Textfeld angezeigt werden. WP-Grins stellte diese IMMER direkt über das Textfeld.

Ich werde nun beobachten, ob dies der Weisheit letzter Schluß ist, oder ob ich noch weitere Optimierungen umsetzen muss, z.B. die ggf. vollständige Entfernung Reduzierung der in der Sidebar angezeigten „Buttons“.

Abgegrast ?!

Heute habe ich den Eindruck, dass die Performance unseres Blog mal wieder unter aller Banane ist.

Deshalb habe ich mich mal bei meinem DomainHoster eingeloggt um die Webseitenstatistiken abzurufen und bekam den ersten Schreck als ich die Übersicht des derzeitgen Traffics in diesem Monat gesehen habe.

Beim Aufruf der derzeitigen Monatsstatistik fiel mir auf, dass der größte Batzen lediglich in den letzten zwei Tagen von 3 IP-Adressen erzeugt wurde.

Da scheint irgendein Dienst den Blog komplett abgegrast zu haben. :evil: Wenn das noch ein paar Mal den Monat passieren sollte, sind meine 10 GB Traffice-Freivolumen schnell ausgereizt :mad: