Suche Code ausdünnen

Aussage 1: du möchtest Deinen Pagespeed verbessern
Aussage 2: du möchtest nur weniger Code

Für 1: installiere dir ein Caching Plugin, welches dir definitiv zig Bonuspunkte bei Google bringt.

Für 2: Installiere dir minify Plugins um deine Stylesheets und Javascripts zu bündeln ODER bearbeite dein Theme so, dass du das Ganze einmal von Hand minifiest und so dann weniger Scripte hast. Zudem achte auf Bildgrößen, damit deine Besucher statt 5 MB Bilder als Vorschau auch nur paar KB Bilder sehen.



Oder du suchst halt hier jemanden der wirklich Tipp 2 von mir quasi umsetzt, dir dafür etwas berechnet und du es aber schneller und einfacher haben kannst. Siehe Tipp 1. weil schneller wirst auch für Google nicht.
Am besten mit Cache und direkt htacces oder noch besser nginx Konfiguration alles regeln

 

Jedes Plugin verursacht wieder mehr Request, so sollte es auch nicht sein [emoji6].

Wie soll man bei einem Hosting Paket Konfiguration bzw Änderungen am Webserver vornehmen, vor allen, wenn dann noch ein Apache läuft [emoji6] ?

 

Hille eigentlich ist deine Aussage nach meiner Meinung absolut falsch.

1.) Mehr Requests hast du dadurch nicht. Außer du meinst die Laufzeit des Requests bzw. der Memoryverbrauch und alles.

2.) Besonders beim Apache kannst du per htaccess Änderungen "am Webserver" vornehmen bzw. Konfigurationen überschreiben. Beim nginx ginge das nicht.

Außerdem helfen diese Kommentare nicht so wie dann u.a. Meiner, die zumindest in die Richtung der Lösung gehen "könnten". Ganz minimal gesagt: deiner hilft da vielleicht 1% auf meine Aussagen bezogen und meiner 2%, wenn man es ganz hart negativ sieht

 

das ist eine Illusion
außer du bist bereit für die vermutlich komplette Neuaufsetzung deines Themes verdammt tief in die Tasche zu greifen...


die Menge an Code ist irrelevant, was damit geschieht ist relevant

 

a) Wenn Du eine echte Performancesteigerung haben willst, musst Du das System wechseln.
b) Man kann mit einfachen Mitteln relativ viel erreichen. .htaccess richtig optimieren (ich bin geneigt, hier im Forum mal was zur Verfügung zu stellen) und JS/CSS zusammenführen.
c) Autoptimize wirkt als Plugin wunder und bietet ausreichend Spielraum, um auch die verbastelsten Themes zu schrumpfen.
d) Ein eigenes kleines CDN trägt dazu bei, die Anforderungen der Prüfbots zu erfüllen.

Wenn es eilt: http://codeable.io

 

Natürlich entstehen bei jedem Plugin mehr Requests. Jedes Plugin bringt zusätzliche Dateien mit, die geladen werden müssen.

Aber auch nur im beschränkten Maße und auch nur, wenn die benötigten Module aktiviert sind.

 

Dann sind wohl meine ganzen kundenspezifischen Einstellungen seit Jahren wirkungslos.


Das wichtigste an Geschwindigkeitsoptimierungen sind meiner Meinung nach (hier treten ja viele Meinungen zusammen):
1. Serverseitige Komprimierung z.B. via gzip aller relevanten Inhalte
2. Minification und Caching, wobei letzteres auch Bestandteil der serverseitigen Konfiguration sein kann
3. Dann gibts noch die CSS und JS Inhalte die an das Ende des Dokuments verlegt werden sollen, damit die Inhalte schneller angezeigt werden, PSI nennt das "above the fold".
4. Richtige Bildergrößen verwenden, wenn möglich Vektorgrafiken (z.B. für Logos) nutzen. Viele Nutzer quetschen leider 12 Megapixel-Fotos unskaliert aus der Kamera in eine 400x400 Pixel Box.
Insbesondere bei responsive Websites wird die Optimierung von Bildinhalten interessant, da hier noch unterschiedliche Größen und Darstellungen berücksichtigt werden müssen.
5. Überlegen ob danach noch weitere Techniken interessant sind, wie z.B. Lazyloading (gibt es auch als WP-Plugin aber nur für iFrames und Bilder)

 

Michael du kannst nicht die nginx Konfiguration überschreiben per htaccess oder ähnlich.
Du hast deine Konfiguration und kannst maximal dem Benutzer in sein FTP Verzeichnis eine nginx Konfiguration legen die dann aber nur includiert wird.
So wie plesk das auch macht, meine ich.

Aber du hast dann trotzdem keine Einwirkung der htaccess Dateien, die in vielen Systemen wie WordPress standardmäßig existieren.

Außerdem finde ich man muss nicht alles kommentieren. Den Auszug hätte man sich sparen können ...
In dem Sinne kann ich mir den Kommentar auch sparen, aber ich muss halt noch lernen nicht alles rechtfertigen zu wollen

Also psst

 

Ich finde die Herangehensweise (Code ausmisten und zusätzliche Plugins vermeiden) durchaus sinnvoll. Strukturierter Code hat immer nur Vorteile, selbst wenn kein unmittelbarer Geschwindigkeitszuwachs damit zusammenhängt. Es ist vielmehr die Grundvoraussetzung, um überhaupt langfristig etwas zu erreichen, alles andere ist oft nur Bastelei. Habe dir daher eine PM geschickt

 

Will hier nicht den Erbsenzähler machen, aber es ist nunmal ein Unterschied zwischen:

Und:

Letzteres ist eben so schlicht falsch. Zudem wenn die Standardkonfiguration passt, muss man auch nichts überschreiben.

Klar hätte man das unkommentiert lassen können, aber da ich eh wenig schreibe, habe ich die Wertminderung meiner Tastatur durch die zusätzlichen Tastenanschläge mal billigend in Kauf genommen.

 

Du hast eine private Nachricht von mir

 

So, jetzt wo der Tag langsam endet und der Schreck nachlässt: Einige hier müssen sich mal fragen, ob sie tatsächlich in der Lage sind, zu helfen.

1. Bußmann, ein Caching-Plugin bringt nur dann etwas, wenn es bislang kein ordentliches Caching gibt. Das wissen wir aber nicht, weil sich hier keiner die Mühe macht, mal nachzufragen, was Google konkret an der Website bemängelt. Fehlendes oder falsch konfiguriertes Caching kommt zwar häufig vor, aber ist längst nicht der einzige Grund für miese Geschwindigkeit.

2. Bußmann, "weniger Code" hat nur dann eine Auswirkung, wenn der Code vorher wirklich extrem aufgeplustert war. Eine Reduktion von 100 kb auf 80 kb HTML kann extrem viel Arbeit machen, hat auf Googles Pagespeed aber eine Auswirkung knapp oberhalb der Nulllinie und ist damit in der Regel unwirtschaftlich. Bilder sind kein Code, haben aber natürlich mit ihrem Dateivolumen einen Einfluss auf die Ladezeit.

3. Hille, bei weitem nicht jedes Plugin verursacht mehr Requests. Bitte lies mal nach, was ein Request ist. Du verwendest den Begriff falsch. Gerade wenn man viele Posts neben dem Usernamen stehen hat, dann neigen neue Benutzer dazu, den Aussagen mehr zu vertrauen. Um so wichtiger, dass Du nicht so einen Quatsch verzapfst!

4. Moni, Du hast nicht nur viele Posts, sondern gehörst auch noch zum Team. Da gilt das, was ich unter 3 schrieb, um so mehr. Wie kannst Du eine so pauschale Aussage treffen, ohne überhaupt zu wissen, welche Punkte Google konkret an der Website bemängelt?

5. Brawler, wenn Du die Empfehlung, das System zu wechseln, auf Wordpress beziehst, dann ist das das dümmste, was ich hier las. Auch Wordpress kann schnell sein. JS und CSS zusammenführen alleine bringt vielleicht die Hälfte dessen, was in dem Bereich möglich ist. Du musst Scripte in den Footer verschieben und asyncron laden. Speziell wegen jQuery bringt das mit sich, dass auch von Plugins und Themes "wild" in den Code geworfene Scripte in den Footer verschoben werden müssen, mit "Tricks" wie ob_buffer, xPath und Regex. Ein CDN ist so ziemlich der letzte Schritt der Optimierung, weil das neue Komplexität in das Projekt bringt. Projekte, die ein CDN wirklich brauchen, landen üblicherweise nicht in der Jobbörse, sondern sind schon bei einer Agentur untergebracht.

6. MichaelTSWS, danke für Deinen Beitrag. Du scheinst mir zu wissen, wovon Du redest. nginx verarbeitet allerdings definitiv keine .htaccess-Dateien. Ich weiß das, wir hosten seit 2 Jahren oder so ausschließlich damit und mussten unseren Entwicklern erst mal den Verzicht auf die .htaccess beibringen.

Mir ist bewusst, dass ich mit meinem Beitrag Leuten auf die Füße trete. Das ist volle Absicht, aber nicht um persönlich zu werden, sondern weil es um die Sache geht. Was soll denn jemand von diesem Forum halten, wenn er sich auf Grundlage unsachgemäßer, aber mit großer Sicherheit vorgetragener Behauptungen für einen Dienstleister entscheidet, und dann auf die Nase fällt? Das fällt auf uns alle zurück. Deswegen musste das jetzt einfach raus, nachdem es den ganzen Tag an mir genagt hat.

 

Sorry, aber das ist unbegründet, nicht fundiert und low-end geraffel. WordPress ist für seine exzessiven Datenbankabfragen und regulären Ausdrücke bekannt und dahingehend alles andere als Optimal. Wer seine Webseite auf einem einfachen Webspace betreibt, bekommt das über kurz oder lang zu spüren.

Davon abgesehen ist das Schindluder, was mit den Plugins (und auch Themes) betrieben wird, eine weitere erhebliche Problemquelle. Langsame Seite > noch ein Plugin installieren. Und jedes Derivat bringt sein JavaScript und CSS mit. Dafür hat der erfahrene WordPress-Entwickler seine Werkzeuge - die weniger erfahrenen greifen auf vermeintliche Cache-Plugins zurück. Leider muss die Umgebung hier ebenfalls in den allermeisten Fällen angepasst werden, was bei Webspace-Inhabern ausgeschlossen ist.

Ein CDN ist der erste Schritt - nicht der Letzte! Und was hat das mit einer Agentur zu tun?

Wenn ich tatsächlich "Performance"... nein, anders herum: es gibt von vornherein Ausschlusskriterien, wann ich bzw. wir WordPress nicht einsetzen:

1. Das Projekt benötigt ein bestimmtes Maß an Performance (Abhängig von Inhalten, Strukturen und nicht von der Hardware!).
2. Das Projekt benötigt ein Deployment (auch wenn das mit einem ziemlichen Overhead auch bei WordPress möglich ist).
3. Das Projekt legt ein User Management mit Rechtevergabe auf Contentebene zugrunde.
4. Das Projekt setzt einen FAL oder ein DBAL voraus.
5. Das Projekt soll Mehrsprachig umgesetzt werden.
6. Es wird eine eCommerce-Lösung angestrebt.

Man sollte natürlich zwischen den Projektgrößen unterscheiden können. Unterm Strich erlaube ich mir diese Empfehlung aus Basis meiner gesammelten Erfahrungen. Erst kürzlich haben wir eine sehr umfangreiche WordPress-Instanz (Multisite mit mehr als 100.000 Posts) auf... ein anderes System portiert. Die Webseite war extrem langsam, die Redakteure haben die meiste Zeit mit Warten verbracht und das Datenmanagement ein absoluter Wust. Ich spreche dem ehem. Dienstleister damit nicht seine Kompetenz ab - er hat das absolut hervorragend gehandelt. Der nächste Schritt wäre die Investition in sehr teure Hardware gewesen, was wir als nicht notwendig erachtet haben.

Als Fazit: der Systemwechsel hat sich für den Kunden sehr gelohnt. WordPress ist keine eierlegende Wollmilchsau - man sollte die Grenzen kennen.

Und als Tipp kann man in der wp-config.php einfach einmal define('SAVEQUERIES', true) eintragen und sich im Frontend (vor dem schließenden body-Tag) mit <pre> das Query-Array ausgeben lassen. Wer hier mehr als 100 Queries stehen hat, sollte seine Datenbank/en auf eine SSD legen. Das ist direkt ein Performance-Schub!

 

1. woher weißt du, dass es um das Tool Page Speed Insights (Google) geht? Davon steht in der Frage nichts
Es steht Pagespeed => das kann viel sein, sehr viel sein und für manche fängt die Optimierung bei 100/100 beim Tool PageSpeedInsights erst an .



2. lies nach was gewünscht wird:
http://forum.wpde.org/jobboerse/146699-code-ausduennen.html

es wird gewünscht: Code auszudünnen ohne Plugin, Scripte zusammenzuführen ohne Plugin,=> das "ohne Plugin" ist der Hauptwunsch dabei.

Und um das zu beantworten muss ich überhaupt nicht wissen was man am PageSpeed verbessern kann.
PageSpeed an sich kann, aber muss nichts mit Page Speed Insights von Google zu tun haben.

D.h. es ist irrelevant was und ob Google überhaupt was bemängelt, weil dies nicht aus der Frage herauslesbar ist. Es kann sein, muss aber nicht, du kannst 100/100 bei dem Tool Page Speed Insights haben und dennoch kann man die Ladezeit => den PageSpeed noch verbessern, weil dies das Tool nicht sichtbar misst.


Ein Beispiel: du kannst "related articles" mit 12 Datenbankabfragen haben (schon erlebt) oder mit zwei => was glaubst ist in der Menge schneller

Du kannst nun die Datenbankabfragen cachen (meist mit einem Plugin ) die meist kostengünstigste Lösung und daher oft genutzt, was es bringt ist eine andere Sache...
Du kannst nun die "related articles" datenbankschonend neu machen => das kostet und wenn man so Schritt für Schritt das Theme die Plugins durchgeht, brauchst kein neues Plugin aber viel Geld.

CSS ausdünnen => na was meinst was es kostet CSS performant zu schreiben
CSS performt neu zu schreiben ist da 100% günstiger als vorhandens zu ändern, und genau das zb geht mit einem ChildTheme nicht mehr , weil man meist auch das html dann ändern muss.


Um das zu wissen reicht meine Erfahrung.

################

und völlig unabhängig vom Thema:
ich habe eine sehr große private Bitte:
Meine Eltern nannten mich "Moni" und im Andenken an sie, wünscht ich mir, dass "Moni" ihnen vorbehalten bleibt.
Bitte nenne mich Monika, danke!

 

Erst mal: Danke für den coolen Beitrag. Ernsthaft. Wir sind jetzt - gemessen an der Job-Börse - zwar weitgehend OT, aber was soll's

Da gehe ich mit. Trotzdem kommen wir bei Projekten auf 92 Punkte beim Desktop-Pagespeed, auf 60ms Time to first byte etc. Ohne großartige Verrenkungen. Ohne spezielle Hardware. Aber mit Servern, bei denen die Konfiguration auf Wordpress abgestimmt ist (werden wir demnächst unter eigener Marke verkaufen), bei Eigenentwicklung der Themes (statt monströser Kauf-Themes) und bei Einsatz überwiegend selbst entwickelter, speziell auf den jeweiligen Einsatzzweck abgestimmter Plugins (statt Alleskönner-Plugins).

Stimmt. Es gibt kaum gescheites, bezahlbares Hosting - für kein CMS.

Ich kann das mit dem "ersten Schritt" aus der Praxis heraus nicht bestätigen. Sehe mich da durch unsere Ergebnisse bestätigt. Ganz ohne die Zusatzkosten für ein CDN. Genau wegen der Kosten ist das CDN in aller Regel auch das letzte, was Kunden wollen beziehungsweise brauchen. Und vor allem wegen der Kosten sind das eher auch Agentur-Kunden als welche, die in der Job-Börse landen. Versteh meine Formulierung da bitte nicht falsch als "Es braucht eine Agentur für ein CDN", das war nicht gemeint.

1 ist mir zu vage. 2 haben wir im Rahmen unseres Entwicklungsprozesses und mit unserem Hosting weitgehend gelöst. Ohne großen Overhead. Das letzte Problem sind Datenbank-Änderungen am Live-System, während wir in der Entwicklung die Datenbank modifizieren. Da traue ich keinem "automatischen" merge über den Weg. Ist aber in der Praxis weniger bedeutsam als in der Theorie. Bei 3 gehe ich mit, wenn Du damit Freigabe-Workflows und ähnliches meinst, da kann man kaum weniger bieten als Wordpress. 4 ok. 5 nö. 6 ist meistens ein Ausschlusskriterium für Wordpress. Wobei wir da in letzter Zeit ganz gute Erfahrungen damit machen, den Shop mit einer Shop-Software zu betreiben, Wordpress für den Content zu nehmen und beiden ein einheitliches Theme zu verpassen. Weil umgekehrt ist ja auch das Shop-System in aller Regel nicht so besonders komfortabel, wenn's um den Content geht.

Kein Einwand. Aber Dein ursprüngliches "Wenn Du was schnelles willst, dann brauchste was anderes" war mir nun auch zu platt

 

Hey Monika, erst mal sorry für die falsche Anrede, werde darauf achten!

Wissen kann ich's nicht, wird aber doch aktuell sehr häufig in diesem Kontext verwendet. Ist aber letztlich auch nicht so wichtig finde ich. Denn auch das was zum Beispiel gtmetrix, yslow etc. ausspucken weicht im Gehalt nicht nennenswert von Google ab.

Henry Ford: "Wenn ich Kunden gefragt hätte, was sie wollen, dann hätten sie sich von mir eine schnellere Kutsche gewünscht". Im Vordergrund steht doch die Erhöhung der Geschwindigkeit, für besseres Ranking, für mehr Konversionen. Dass dann ein paar Ideen mitgeliefert werden, wie das vermeintlich erreicht werden könnte, erachte ich als weniger wichtig. Da ist eher die Aufklärung durch den Profi gefragt als das stumpfe Umsetzen.

Deine Argumentation beruht ja im wesentlichen darauf, alles wortwörtlich auszulegen. Ich gehe da eher nach dem (aus meiner Praxis heraus erfahrungsgemäß dahinterliegenden) Sinn. Wenn ich's wortwörtlich auslege, dann baue ich die Veränderungen eben ins Theme. Ist dann ja kein Plugin. Wäre aber wohl auch kaum so gemeint.

Häh? (Ernsthaft)

12 Datenbankabfragen statt 2 spielen auf einem nicht ausgelasteten Server mit Low-Traffic-Website nahezu keine Rolle. Sie spielen auch keine Rolle, wenn die Seite eh aus dem Cache kommt (und der Server die Cache-Kopien nach der Auslieferung aktualisiert). Aber sie spielen eine massive Rolle, wenn die Kiste eh schon gut zu tun hat, die Website intensiv frequentiert wird, sich schlecht cachen lässt (wegen vieler eingeloggter Nutzer) etc. Genau deswegen sage ich, man muss sich das angucken, statt Empfehlungen auf Verdacht abzugeben.

Ich will ja nicht bestreiten dass es nicht eleganter ist, wenn man auf der grünen Wiese anfangen darf. Aber solche Projekte habe ich hier in der Job-Börse noch nicht gesehen. Da geht's darum, für ein paar hundert Euro zu machen, was sich machen lässt. Ich hatte im Frühjahr den Fall, wo wir eine mit einem lauen Theme (dano) und x Plugins ausgestattete Website im Nachhinein optimiert haben. Das ging dann mit 8 Stunden Arbeit (ca.) von 62 auf ich glaube 85 Punkte hoch. Wenn Du dann noch auf Billig-Hosting verzichtest, dann bist Du bei Pingdom schon regelmäßig schneller als 95% der übrigen Websites.

Was mich aktuell noch mehr umtreibt ist das Thema der gefühlten Ladezeit. Vgl.

https://de.onpage.org/blog/demystifizierung-des-google-pagespeed-insights-tools

Da spielt dann das Thema "optimales CSS" auch mit rein.

 

Hast du bei Page Speed Insights schon je mal gesehen: Ladezeit xyz sec?
Dieses Tool zeigt die Ladezeit nicht sichtbar an, ob sie es messen ist eine andere Sache...

Alles andere waren Beispiele aus 100derten von Möglichkeiten eine Site schneller zu machen.

Und ja hie und da zeige ich auf, dass die extra betonten Wünsche einer wirklich guten Lösung hinderlich sein können. Das erzähl ich auch meinen Kunden, wenn nötig. Wie ich das genau tu zeige ich aber hier jetzt nicht auf das würde total zu weit führen.

 

Normalerweise wollte ich ich mich hier nicht mehr zu äußern, aber egal.

Definiere mal "ohne großartige Verrenkungen". Würde ich gerne mal live sehen wollen.

P.S. Mir ist bekannt, was Request / Anfragen bedeuten. Evtl. habe mich mir ein wenig ungünstig ausgedrückt.