WordPress: Performance-Problem der besonderen Art

48 Kommentare

Leute ich habe in den letzten Tagen hier ein Performance-Problem, da würde man am liebsten in die Tischplatte beißen. Das Problem existiert erst seit ein paar Tagen. Uns selber und einigen aufmerksamen Lesern ist aufgefallen, dass unsere Websites langsamer geworden sind.

Gute Werte
Trotz guter Werte schlechte Performance

Ich habe daher in den letzten Tagen viele Testreihen und einige Optimierungsmaßnahmen durchgeführt. In vielen Punkten bin ich schlauer, aber das Performance-Problem konnte ich leider nicht vollständig lösen.

Das Problem: statische Grafiken

Es fing damit an, dass die Response-Zeiten (in der das komplette Dokument geladen wurde) sich erhöht haben und Spitzenwerte von über 4 Sekunden hatten. Durch diverse kleine Maßnahmen, wie z. B. vermehrten Einsatz von Sprites, Flattr statisch anstatt dynamisch auf der Startseite, Optimierung der CSS-Datei etc. konnte ich dieses Problem in den Griff bekommen.

Das Hauptdokument oder besser gesagt, die HTML-Ausgabe der Startseite ist nicht das Problem, sondern kurioserweise statische Komponenten, wie zum Beispiel Layoutgrafiken oder Bilder und das in den meisten Fällen 3-4 Grafiken:

Statische Komponenten laden nicht
Das Problem: statische Komponenten zicken herum

Wie man auf dem Screenshot sehen kann sind es diese drei Grafiken die streiken, in sagen wir 80% der Fälle. Manchmal gesellt sich noch beitrag-hinweis.gif oder Büchercover aus der Sidebar hinzu. Aber auf jeden Fall handelt es sich um statische Grafiken, die entweder im der CSS-Datei oder in footer.php bzw. sidebar.php referenziert werden.

Ich habe diese statische Grafiken sogar auf einer anderen Domain ausgelagert, aber geholfen hat es nicht. Ach ja, und manchmal sind es die Smileys, an die sich die Seite verschluckt.

Deaktiviere ich alle Plugins ändert sich nichts am Problem. Schalte ich auf ein anderes Theme, zum Beispiel auf Default oder auf mein Red Train, dann habe ich keine Probleme mit den Grafiken.

Liegt es also am Theme? Aber was könnte es denn sein? Immerhin habe ich auch noch gestern über eine Stunde zusammen mit Sergej das Problem näher angeschaut und schlauer sind wir auch nicht geworden.

Aber auch wenn es am Theme liegt, dann ist das nur ein Teil des Problems, es sind nämlich alle WP-Seiten des Accounts betroffen (wenn auch nicht so stark) und alle Backends sind unendlich langsam. Zudem sind auch die Smileys manchmal das Problem und diese sind im Theme selber nicht referenziert.

Jens brachte mich auf den Gedanken, dass evtl. die Pfadangaben durcheinander gekommen sein könnten. Daher habe ich die Pfade zu den Bildern absolut notiert und es ändert sich auch hier nichts.

all-inkl so: Alles Roger in Kambodscha

Da mir das ganze etwas komisch vor kam, habe ich den Support von all-inkl kontaktiert und zwei Mal wurde mir versichert, dass mit dem Server alles in Ordnung sei. Bestätigt wurde diese Aussage als ich meine statischen Projekte auf dem gleichen Account getestet habe.

Also muss das Problem irgendwie bei WordPress liegen. Nur was? Wenn man sich dann die erste Abbildung, sprich die recht guten Werte anschaut, dann wird die schlechte Performance um so unlogischer.

Wir arbeiten seit 20 Jahren mit WordPress und bieten diverse Dienst­leistungen rund um das System an. Kontaktiere uns für weitere Informationen oder für ein Angebot.

Verwandte Beiträge:

Über Vladimir

Vladimir Simović arbeitet seit 2000 mit HTML & CSS und seit Januar 2004 mit WordPress. Im Laufe der Jahre hat er diverse Fachbücher und Fachartikel publiziert.

Schlagwörter: , ,

48 Kommentare

  1. hi,

    hast du Trackingsoftware mitlaufen? Statpress o.ä.? Die bremsen auch ganz schön aus.

    Ansonsten, sind die Pics oben eigentlich vorhanden? Oder findet er sie nicht?
    Wie gross sind die?

    ciao
    Frank

    1. @Frank,

      ich habe alle Plugins deaktiviert und es ändert sich nichts. Die Grafiken, mit Ausnahme der Kopfgrafik (24 KByte) sind kleiner als 2 KByte.

  2. Bei mir brauchen alle Deiner Grafik ewig zum laden! 700ms – 19s !!!
    Hast Du irgendwie am zlib rumgespielt? Hast Du es überhaupt an? Wenn ja, hat der Server vielleicht ein Problem damit?

    Übrigens hat dein Retweet button von topsy anscheinend auch ein Problem und braucht bei mir allein 4.5s

  3. Ich hab mal einen Screenshot gemacht, da wird deutlich wo es bereits beim Laden hängt: http://twitpic.com/1wy9gj

    Vielleicht hilft dir das ja weiter. Scheinbar liegt es am Header und/oder der Sidebar. Zumindest würde ich da mal ansetzen und suchen. Artikel sind Ruckzuck geladen bei mir.

    Gruß,
    Andreas

  4. Hast Du es mal mit Sudomains versucht … css.perun.net für die Styles und img.perun.net für die Bilder … anstelle der .eu Domain? Kann mir zwar nicht vorstellen das es was ändert, aber manchmal ist komisch.

  6. […] This post was mentioned on Twitter by Vladimir Simovic, Andreas H. Andreas H said: RT @vlad_perun #WordPress, #Performance-Problem der besonderen Art http://goo.gl/fb/bwdUF #wordpressfaq #wordpresstipps […]

  8. Bei mir will der das JavaScript für das Plugin “Live Comment Preview” nicht laden. Dadurch hängt bei mir die Seite an der Stelle bis zu 21 Sekunden, denn es entsteht ein Loop: Auf Fehlerseite wird wieder versucht das JS zu laden, und immer und immer wieder. Deaktiviere doch mal das Plugin.

    1. @Dennis,

      wie gesagt, ich habe schon mehrfach alles Plugins deaktiviert gehabt. jetzt auch und trotzdem dauert es noch sehr lang.

  9. Im Chrome wurde bei mir gerade gar kein Stylesheet geladen, im Firefox konnte kommentar-icon-klein.gif, sowie quicktags.js und sociable.css nicht geladen werden.
    Wie siehts denn mit der .htaccess aus? Mal leeren/umbennen und in WP die Standardpermalinks einstellen.

  10. Des Weiteren existiert die statische Datei “https://www.perun.net/wp-content/themes/perun5/img/twitter-feed.png” nicht, dadurch landen wir wieder im bekannten Fehlerloop (9s).

  11. Erschreckend, dass selbst euer geballtes Know-how nicht dahinter kommt. Ich drücke die Daumen.

  12. Nachtrag: ich klicke mich hier so durch und merke nichts davon, dass etwas langsam ist. Hast du es schon hinbekommen?

  13. @Perun
    Das ist natürlich sehr ärgerlich, wenn die Webseite nicht so will wie es sein sollte. Die Ladezeit ist wirklich lange … Leider kann ich Dir keinen Tipp geben!

  15. @ocean90 hat Recht. Die Dateien extieren, nur gibt es des öfteren einen 404 an den Kopf. Daher meine Vermutung: .htaccess ist Schuld.

    Noch eine Sache an der JavaScript-Front: Deine Anbindung von Google Analytics ist kaputt: “Fehler: _gat is not defined, Zeile: 413”.

  16. @Perun, ja, aber ohne das “Live Comment Preview” sind es bei mir statt 19 Sekunden “nur noch” 3 Sekunden. Was mir auffällt ist noch, dass bei deinen statischen Dateien keine Caching-HTTP-Header mitgesendet werden.

  17. Hast Du in dem Theme durch die Sprites oder was anderem vielleicht irgendeine dynamische Komponente der Grafikurls gebaut, die jetzt vielleicht lahmt?

    – Es sind ja immer wieder andere Grafiken.
    – Die Grafiken selbst laden fix.
    – Nur das “Connecten” dauert, also der teil, der den Link liefert?

    1. @Viktor,

      ja es sind immer andere Grafiken. Bis jetzt war auch immer das Smiley der Mitbremse, wenn ich den Smiley aus dem Artikel nehme, dann nihmt es sich eine andere Grafik.

  20. Also hier auf meinem PC läuft das Teil jetzt wie Nachbars Lumpy. Alles im Millisekundenbereich.

    Viel schneller geht nimmer.

    Haste was geändert?

    ciao
    Frank

  22. Was natürlich auch sein kann, ist dass dein Shared-Hosting lahmt.

    Neben dir sind noch 47 andere Kunden in deinem Account. Kann sein, dass es daran manchmal hakt, wenn bei denen hoher Traffic ist.

    Hiermit kannste das nachvollziehen:

    http://www.serverdna.de/

    cu
    Frank

  23. Ich – ebenfalls mit all-inkl Shared Hosting – hatte so ein Problem bei mir auch erstmals bemerkt, nachdem ich die URLs so umgestellt hatte, dass Theme-/Header- und einige andere Bilder von zwei Subdomains geladen werden. Nach einiger Zeit war das aber wieder vorbei und seitdem nur noch sehr selten – zumindest bezogen darauf, was ich selber bemerke.

    Ich hab’s dann auf sich beruhen lassen in der Annahme, dass diese gesteigerten gleichzeitigen Zugriffe dem Webserver manchmal, wahrscheinlich wenn er mit anderen Kunden auch gerade viel zu tun hat, eben zu viel auf einmal werden, und in der Hoffnung, dass es nicht zu oft vorkommt…

  24. Es ist tatsächlich die Reaktionszeit des Servers, die (ungebrochen) das Problem darstellt.

    Da es sich nicht umein generelles Server-Problem, sondern um ein Theme-Problem handelt, wäre die .htaccess daher nicht uninteressant einzusehen. Magst Du sie uns posten? Hast Du noch weitere innerhalb Deines Themes-Ordners liegen? Falls ja: bitte auch mal posten.

    Desweiteren könntest Du noch etwas am Caching ändern und dadurch die Requests, auch die schnellen 304er, komplett einsparen, auf dass der Browser alles aus seinem Cache bedient. Ohne Aufruf, kein Lahmen. Nichtsdestotrotz ist das nur Symptom- und keine Ursachenbekämpfung.

    1. @Schepp,

      hier die .htaccess:

      # BEGIN WordPress
      <IfModule mod_rewrite.c>
      RewriteEngine On
      RewriteBase /
      RewriteCond %{REQUEST_FILENAME} !-f
      RewriteCond %{REQUEST_FILENAME} !-d
      RewriteRule . /index.php [L]
      </IfModule>

      # END WordPress

      #RedirectMatch permanent /archiv/category/([^\.]+) /kategorie/$1
      #RedirectMatch permanent /archiv/([^\.]+) /$1

      # RewriteCond %{HTTP_HOST} ^perun.net$
      # RewriteRule ^(.*)$ https://www.perun.net/$1 [R=301,L]

      # RewriteEngine On
      # RewriteCond %{HTTP_HOST} !^www.perun.net
      # RewriteRule (.*) https://www.perun.net%{REQUEST_URI} [R=301,L]

      # RewriteEngine On
      # RewriteCond %{HTTP_HOST} ^perun\.net
      # RewriteRule ^(.*) https://www.perun.net/$1 [L,R=301]

      #order allow,deny
      #deny from 213.96.32.14
      #allow from all

      # protect wpconfig.php
      <files wp-config.php>
      Order deny,allow
      deny from all
      </files>

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

      # cache
      <FilesMatch "\.(ico|jpg|jpeg|png|gif|js|css|swf)$">
      ExpiresActive on
      ExpiresDefault "access plus 35 days"
      #Header unset ETag
      #FileETag None
      </FilesMatch>

      an den Auskommentierung siehst du das ich schon einige Kombinationen versucht habe. Einige der Relikte aus alter Zweit (Umleitung von nicht-www auf www) sind noch auskommentiert drin.

      Innerhalb des Themes-Ordners ist nur der img-Ordner.

  25. Was ich gerade feststellen konnte, dass unter wordpress-buch.de und .vlad-design.de mehr oder weniger das gleiche Problem vorhanden ist: http://grab.by/4WD6 – Problem mit der social.css
    http://grab.by/4WD8 – Längere Ladedauer von navi-oben.gif
    In wie weit hängen die drei zusammen, selbe Installation, WPMU/Multisite?

    1. @ocean90,

      das einzige was die gemein haben ist das ich Sie betreue 🙂 und die alle auf dem gleichen Account liegen.

  26. @Perun
    Ok, heißt also es sind unterschiedliche WordPress Installation. Habe mal den Link von Frank ausprobiert und ein paar Seiten getestet, die laut dieser Liste auch auf *deinem* Server liegen.
    Ergebnis: Du bist nicht der einzige. Bei Seiten mit vielen Bildern musste auf eins-zwei Bilder immer länger gewartet werden. Oder: Es wurde einfach abgebrochen, siehe dazu hier: http://grab.by/4WE6

  27. was du mal spasshalber noch machen kannst, ist das hier noch in die htaccess eintragen:

    php_value memory_limit 128M

    Hast du auch mal ins error.log des Hosters geguckt? Steht da was drin?

    bye

  28. ich bin ja kein ServerJunkey, doch ich las mal, dass man Bilder niemals länger als 30 Tage cachen sollte,weils sonst zu Problemen kommen kann.

    Sprich sie werden dann nicht angezeigt.

    Ich habe das nur in meinem Kopf und kanns nicht belegen,aber vielleicht ist es eine zusätzliche Überlegung wert.

    lg

  29. Auf die schnelle, da ich die Kommentare nicht gelesen habe:
    – JS in den Footer und im Test deaktiveren, daher am besten via wp_enque_script laden.
    – Grafiken via CSS, dann ist da der Platzhalter und per CSS ist es ein geringeres Problem
    – besser noch, hole die statischen Bilder via Bas64 in das CSS
    – prüfe die Rewrite Rules der Pages, eventuell hast du zu viele.
    – prüfe die Queries “Debug Queries” Plugin, auch wenn ich nicht daran glaube
    – MySQL Slow von allinkl abfordern und prüfen
    Schau dir den Traffic an, eventuell hakt es irgendwo, Feed? auch da können Inhalte sein, die bremsen

  31. ocean90 hat die “Lösung”
    Alle Deine IP Nachbarn haben das gleiche Problem!
    => Druck beim Provider machen! Die müssen Dir das Gegenteil beweisen (dass es nicht der Server ist)

  32. Ich hatte das schon mal auf einem Server – da hatte ein Nachbar ein DOS Angriff aufgrund eines Hacks gefahren und es stand auch fast alles Still.

  33. Der Server bzw. ein Switch bei Allinkl hat definitiv nen Hau weg. Hab eben ein Dauerping laufen lassen und von 519 gesendeten Paketen 2 komplett verloren.

    Wenn die sich doof stellen, dann gib doch den anderen Vertragskunden auf dem Server Bescheid (via ServerDNA). Dann macht Ihr mal zusammen Stress 🙂

  35. Hi Vlad,
    ich glaube deinen Aussagen bzgl Allinkl nicht so recht. Ich hab da auch alles liegen und bin mit dem Tempo absolut nicht zufrieden.
    Selbst bei dem teuren Paket hängt es schon sehr lange. Der Test mit einem anderen theme brachte auch nicht wirklich was.
    So wie ich dich “kenne” wird der fehler weniger bei dir zu finden sein sondern auf der Infrastruktur die wir hier nutzen.
    Schade das sich Allinkl da auch nicht wirklich einbringt. Der Support ist schon lange nicht mehr das was er mal war.

  36. wennst ne Empfehlung für 2 gute Provider brauchst, schick mir ne Mail.

    Ich möchte hier nicht öffentlich Werbung machen…… 😉

  38. Tja, leg mal eines deiner betroffenen Projekte auf einen anderen Hoster. Ich tippe auf Allinkl als Quelle des Problems… 👿

    cu +quakemaster+

  40. Nur eine Vermutung. Bei diesem Fehlerbild tippe ich auf DNS. Warum?

    Verzögerung beim statischer Content kann erst mal nicht an WP und PHP liegen. Sicher macht der Apache seine Arbeit klaglos. Aber um beispielsweise seine LOGs zu füllen wird die IP des Aufrufers mit Reverse-DNS in einen Namen gewandelt und im Protokoll vermerkt. Gibt es hier ein DNS-Problem, kommt es immer mal zu Stockungen beim ausliefern. Lege doch mal Dein WP mit DB auf ein anderes Hosting als Kopie… Das meinen auch die anderen Kommentatoren nicht umsonst.

    Richtig? If (Nein) -> remove(Beitrag) 😉

Kommentare sind geschlossen.