registrieren registriertes Mitglied


Anzeige

Anzeige

HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

Fragen zu Servern, Hosting und Webmaster Hardware könnt Ihr hier stellen.
Neues Thema Antworten
supervisior
PostRank 9
PostRank 9
Beiträge: 2718
Registriert: 26.06.2006, 09:11

Beitrag supervisior » 11.11.2020, 15:00 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

Aufbauend auf dem vorausgegangenen HowTo zum Thema QUIC,

viewtopic/t-144811.html

widmet sich dieser Thread der vermutlich besten Methode, wie man die Ladezeit seiner Webseite um bis zu mehreren 1000% verbessern kann. Diese exorbitante Leistungssteigerung bezieht sich dabei auf das Laden des Hauptdokumentes, also quasi der elementarste Anteil beim Laden einer Webseite. Jedoch nicht zu verwechseln mit den sichtbaren Bereichen im Browser. Was aber unscheinbar wirken mag, ist jedoch die zwingende Voraussetzung dafür, dass man im Browser überhaupt was zu sehen bekommt, da alles sichtbare zumeist durch statische Sourcen wie Bilder, CSS und Javascript erst dann geladen wird, wenn vorher das besagte Hauptdokument geladen wurde.

Man kann seine Webseite also noch so gut optimieren, was alles 0 Komma nichts bringt, wenn das Laden des Hauptdokumentes zu langsam erfolgt. Die Gründe für ein langsames Laden des Haupdokumentes können vielfältig sein und erstreckt sich beginnend von einer zu großen Latenz, also der Zeit bis der Server überhaupt mal auf eine Anfrage reagiert, über zu große Datenmengen, eine schlechte Internet Verbindung, ein zu schwacher Server (zumeist Shared Hosting), schlechte Programmierung bis hin zu der meistverbreiteten Ursache. Webserver, PHP und MySQL sind, wenn man so will, der größte Bottleneck ("Engpass, Flaschenhals") und das in Kombination mit einem nicht ausreichend dimensionierten Server, wobei dieser Bottleneck eigentlich immer besteht. Der Flaschenhals hängt jedoch primär mit der Leistungsfähigkeit eines Servers zusammen. Ein billiges Hosting Angebot steht deswegen unmittelbar für langsam(er) oder schnell(er) und was man seinem Server abverlangt. Eine statische Seite ohne PHP und MySQL kann aber durchaus mit einem 3,50 € Hosting schnell sein, aber das ist die Ausnahme, weil 99 von 100 ein CMS verwenden. Und ein CMS braucht nun mal PHP und MySQL.

Lässt man das mit der Leistungsfähigkeit eines Servers zunächst mal außen vor, ergibt sich bereits bei der Wahl des CMS ein grundlegendes Dilemma, dem so ziemlich jeder ausgeliefert ist, wenn er nicht sein CMS indivuell anpassen und das tiefgreifend ändern will. Es hat sich schon vor Jahren bei der Programmierung von CMS eingebürgert, dass diese nur mehr noch unter Nutzung von sog. Frameworks programmiert werden. Dazu gehört auch das Bootstrap CSS Framework, was zwar nicht unmittelbarer Bestandteil bei der Programmierung einer Applikation ist, aber sich die Problematik bei der Nutzung von Frameworks einmal mehr wiederholt.

Wenn ein Framework, vereinfacht dargestellt, nur eine Sammlung an sog. Bibliotheken ist und der Programmierer sich damit viel Zeit bei der Programmierung erspart, weil er nicht jede Funktion erst programmieren muss und sich einfach nur die benötigte Bibliothek aus der Sammlung holt und darauf aufbauend seine gewünschte Funktion programmieren kann, besticht ein Framework vorwiegend dadurch, dass es ebenso vorwiegend der Programmierung dient. Jedoch zunächst ungeachtet welche Fallstricke sich daraus ergeben. Einmal abgesehen von der Qualität des Codes ist eine Applikation ohne Framework im Endergebnis nicht besser oder schlechter als mit Framework. Gerne wird der Einsatz eines Frameworks werbewirksam eingesetzt und soll etwas besseres vorgaukeln, was es unterm Strich aber nicht ist. Vielmehr ist es so, dass der Einsatz eines Frameworks dazu den Programmierer verleiten lässt mehr Code zu verwenden als was er eigentlich bräuchte. Es ist ja so einfach einfach eine Bibliothek seiner Programmierung hinzuzufügen. Und am Ende hat man/bekommt man eine unnormal aufgeblähte Anwendung für die man mehr Speicher und CPU Power braucht. Es gibt genügend Beispiele dafür, die teilweise so extrem sind, dass die jeweilige Anwendung im übertragenen Sinne Gehhilfen braucht, um diese überhaupt installiert zu bekommen. Dieses Phänomen wirkt sich auch dadurch aus, dass Hersteller auch von bekannten Anwendungen erst am Ende einer Entwicklung feststellen, dass man über das Ziel hinausgeschossen hat und in Folge dessen krampfhaft mit Drittlösungen versucht wird die leidende Performance wieder in den Griff zu bekommen. Das ist zwar kein generelles Problem, lässt sich aber sehr oft feststellen.

Bezieht man das beschriebene Problem beispielhaft auf Wordpress, mag es zunächst irritieren, dass es auch dort so sein könnte. Wordpress ist im Auslieferungszustand ja eher schlank, jedoch bedingt dadurch, dass es im Auslieferungszustand nur die elementaren Funktionen mitbringt und deswegen auch sehr flott ist. Die vermutlich meisten WP Nutzer ergänzen aber ihre WP Installation durch entsprechende Plugins und spätestens dann gehen die Probleme los. Teils schlechter Programmierung, meistens aber ganz einfach deswegen weil mehr Code == mehr Funktionen == einen höheren Systemressourcen Bedarf haben, jedoch mit dem Haken versehen, dass das in eine Sackgasse landet, weil ein leistungsfähigerer Server und somit ein Mehr an Kosten oftmals für viele keine Option ist oder/und auch ein besseres Hosting das besagte Bottleneck nicht auflöst.

Wenn dem nun so ist, wie es offensichtlich ist und das volle Potential an Optimierungsmöglichkeiten nicht das zufriedenstellende Ergebnis gebracht hat, stellt sich die unweigerlich die Frage was tun?

Das Internet hält für dieses Problem eine Vielzahl an Möglichkeiten bereit, gute wie weniger gute, teure aber auch preisgünstige und nicht selten aber auch kostenlose. Um nun einen entscheidenden Push zu bekommen, der so ziemliches alles überragt, braucht es Caching. Keine andere Methode als Caching bringt ein besseres Ergebnis hervor. Danach kommt lange nichts, was auch nur annähernd die gleiche Performance abliefern kann. Caching hat nur einen Haken. Gemäß dem Grundprinzip von Caching müssen Daten zumindest einmal (1x) zwischengespeichert sein, um die Vorteile nutzen zu können. Dieser augenscheinlich wirkende Nachteil lässt sich aber auf einfachste Weise beheben, sodass der Nachteil vernachlässigt werden kann.

In der Vielzahl an unterschiedlichen Cache Arten sticht besonders das HTTP Caching hervor, weil es im Ergebnis andere Cache Unterarten vereinnahmt und somit überflüssig macht, das beste Ergebnis abliefert und sich mit verhältnismäßig wenig Aufwand nutzen lässt. HTTP Cache ist jedoch nicht gleich HTTP Cache und zumindest aus meiner Sicht die Bezeichnung HTTP Cache oftmals falsch und irreführend verwendet wird. Ungeachtet dessen löst HTTP Caching aber das eingangs beschriebene Bottleneck Problem. Zwar nicht bei allen erhältlichen Varianten in Perfektion, aber doch in erheblichem Maße.

Vorab gilt es jedoch zu differenzieren, was ein HTTP Cache nicht ist und das in erster Linie was den Browser Cache anbetrifft. Statische Sourcen wie Bilder, CSS und Javascript sind prädestiniert zum Cachen im Browser, ist aber kein HTTP Cache. Wenn es konkret um HTTP Cache geht, dann bescheibt das das Serverseitige Cachen, insbesondere von dynamisch generierten Inhalten, also den Daten die mittels PHP und MySQL bei jedem Aufruf erst generiert und abgefragt werden müssen und zusammen mit dem HTML Output auf dem Server zwischengespeichert werden. Das Ergebnis eines HTTP Cache entspricht vereinfacht dargestellt dem lokalen Speichern einer einzelnen Internet Seite mit der jeweiligen Browser Funktion. Wird nun eine im Cache befindliche Seite/URL aufgerufen, wird im Grunde genommen nur mehr diese auf der Festplatte des Servers gespeicherte Datei aufgerufen. Der ansonsten notwendige Aufruf des PHP Interpretors inkl. Datenbank Abfrage entfällt gänzlich. Daraus ergibt sich folgerichtig eine exorbitant schnelle Ladezeit jedoch begrenzt auf das Hauptdokument. Zu viel CSS, Javascript, schlecht optimierte oder zu große Bilder, ein zu verschachteltes DOM können das ursprüngliche schnelle Laden des Hauptdokumentes aber wieder zunichte machen. Deswegen ist die Konsequenz, dass ein HTTP Cache nur so gut sein kann, wie der Rest an statischen Sourcen optimiert ist.

Wie vorausgehend bereits erwähnt, ist ein HTTP Cache nicht gleich HTTP Cache. Wie gut ein HTTP Cache ist, hängt von mehreren Faktoren ab. Dazu gehört u.a. das Speichermedium, also die Festplatte. Kommt nur eine gewöhnliche SATA HDD zum Einsatz, drosselt diese die Leistung des HTTP Cache nicht unerheblich, weshalb zwingend eine SSD HDD zusammen mit einem HTTP Cache verwendet werden sollte (MUSS).

Am Beispiel Wordpress gibt es dafür ein gutes Dutzend an HTTP Cache Plugins oder sagen wir mal um Plugins, die gerne ein HTTP Cache sein möchten. Zwar erledigen diese Plugins die Aufgabe eines HTTP Cache in ihrer grundsätzlichen Funktion und können jeder WP Installation Flügel verschaffen, jedoch mit teilweise großen Einschränkungen, sodass diese Plugins nicht uneingeschränkt genutzt werden können.

Allen Einschränkungen voran steht, dass diese Plugins, bzw. dessen Ergebnis von der Performance des Webservers abhängt. Zumeist ist dies der Apache Webserver und mal abgesehen von dessen veralteten System Architektur, weiß Apache nicht, dass die Wordpress Installation eine HTTP Cache Funktion hat und schert sich deswegen auch nicht darum und behandelt einen Request wie jeden anderen. Kurzum, die HTTP Cache Funktion könnte zwar sehr schnell sein, wird in Ermangelung einer Abstimmung mit dem Webserver aber ausgebremst. Von daher sind dem Ergebnis von dieser Art HTTP Cache ziemlich enge Grenzen gesetzt, zumal dann, wenn man nur ein geringes Budget für das Hosting hat. So gut wie solche Plugins wirken mögen, kommt es nicht selten vor, dass diese Plugins wieder deinstalliert werden, ohne aber zu verstehen, warum man nicht den Speed bekommt den man augenscheinlich bekommen soll. Spätestens jetzt sollte man aber wenn auch nur in Grundzügen verstehen, dass so ein Plugin allein nur bedingt was bringt.

Zu den weiteren Einschränkungen zählt, wenn die jeweilige Anwendung um Funktionen erweitert wird, die eine Session benötigen oder/und sich Teilbereiche einer einzelnen Seite in Abhängigkeit zum Nutzerverhalten dynamisch verändert. Zur Erinnerung, ein HTTP Cache speichert den HTML Output einer vorher generierten Seite statisch auf dem Server ab. Statisch bedeutet, dass in Ermangelung von PHP auch keine Session mehr existiert. In der Session befinden sich aber flüchtige und nicht selten nutzerbezogene Daten, die es aber widerrum braucht, um den jeweligen Content anzeigen zu können. Ist dies der Fall, könnte man den HTTP Cache von solchen Plugins nicht verwenden. Als unmittelbares Beispiel dient die Warenkorb Funktion in einem Online Shop oder ein angemeldeter Zustand in einem Benutzerkonto. Jedoch stets nur bezogen auf solche Cache Plugins, die im Grunde nur Cache ON/OFF kennen und nicht in der Lage sind nur Teilbereiche einer einzelnen Seite zu cachen oder/und trotz Cache Funktion die Session Funktion aufrecht erhalten können.

Was vorausgehend wie ein sehr tiefer Einschnitt in den doch so hochgelobten HTTP Cache wirken mag, ist in der Tat ein Einschnitt, allerdings ausnahmslos nur dann, wenn man derartige Plugins verwendet. Es gibt noch weit bessere HTTP Cache Lösungen, jedoch kommt nach diesen Plugins erstmal nichts und die Stufe zu einem richtigen HTTP Cache und v.a. ohne Einschränkungen ist hoch, sehr hoch. Aber auch hier nur bezogen auf konventionelle Lösungen wie dem Varnish Cache für den man dann 10.000 $ pro Jahr an Lizenzkosten zahlen muss. Für diesen Betrag bekommt man dann zwar die eigentlich selbstverständliche SSL Unterstützung. Das erspart einem aber nicht die Notwendigkeit eines zusätzlichen Proxy und tiefe Eingriffe in die jeweilige Applikation, um das besonders für Online Shops notwendige partielle Cachen zu bekommen.

Das hört sich nun auch nicht viel besser an als die Plugins, zumal es ja um etwas massentaugliches geht und für nahezu jeden bezahlbar bleiben muss. Die gute Nachricht ist, so was gibt es und besser als alles, was man selbst für noch so viel Geld nicht bekommt. So einfach zu bedienen wie genannten Plugins, jedoch ohne die genannten Einschränkungen und zudem ganzheitlich gelöst. Im Fall Wordpress bedeutet das 1 Lösung, die sowohl einen perfektionierten HTTP Cache zur Verfügung stellt und zusammen damit sämtliche und bislang unbekannte Optimierungen vornimmt.

Der Haken daran ist nur, dass man das nicht an jeder virtuellen Straßenecke bekommt. Wer jetzt auf den Geschmack gekommen ist und gerne mehr erfahren möchte, darf sich gerne per PM an mich wenden.
Zuletzt geändert von supervisior am 12.11.2020, 10:33, insgesamt 1-mal geändert.

Anzeige von:

SEO Telefonberatung bei ABAKUS:
  • Schnelle & kompetente Hilfe
  • Direkte Kommunikation
  • Fachkundige Beratung
  • Geringer Kostenaufwand
Sprechen Sie uns gerne an:
0511 / 300325-0

Lyk
PostRank 10
PostRank 10
Beiträge: 3075
Registriert: 10.08.2009, 16:26

Beitrag Lyk » 11.11.2020, 20:31 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

supervisior hat geschrieben:
11.11.2020, 15:00
Eine statische Seite ohne PHP und MySQL kann aber durchaus mit einem 3,50 € Hosting schnell sein, aber das ist die Ausnahme, weil 99 von 100 ein CMS verwenden.
eigentlich ist ein cms bei vielen webseiten unnötig. html mit css reicht vollkommen aus.
- responsive
- mobilfreundlich
- schnell
- sicher
- benötigt keine updates

nerd
PostRank 10
PostRank 10
Beiträge: 4302
Registriert: 15.02.2005, 04:02

Beitrag nerd » 11.11.2020, 21:12 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

Lyk hat geschrieben:
11.11.2020, 20:31
eigentlich ist ein cms bei vielen webseiten unnötig. html mit css reicht vollkommen aus.
Ja, wenn man nicht mehr als 3 seiten hat.

Es gibt auch file-basierte CMS die dir eine oberflaeche mit formular bieten, und im hintergrund dann die fertigen "html dateien" auf dem webserver schreiben. ich hatte mal eine weile Kirby benutzt, war extrem schnell.

Wenn eine seite langsam ist, dann ist eigentlich immer der betreiber schuld weil er sie mit jeder menge spielerei (20 wordpress plugins und mehr) ueberladen hat.
In den 90ern gab es auch schon webseiten die kleiner als 100kB waren weil die modems und uebertragungskosten nicht mehr hergegeben haben.

Benutzeravatar
arnego2
PostRank 9
PostRank 9
Beiträge: 2273
Registriert: 23.02.2016, 13:55
Kontaktdaten:

Beitrag arnego2 » 11.11.2020, 21:47 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

nerd hat geschrieben:
11.11.2020, 21:12


Ja, wenn man nicht mehr als 3 seiten hat.
Wie kommst du den darauf?
Arnego2 <Webseiten Neu & Umbau ab 80 Euro>

nerd
PostRank 10
PostRank 10
Beiträge: 4302
Registriert: 15.02.2005, 04:02

Beitrag nerd » 12.11.2020, 04:08 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

arnego2 hat geschrieben:
11.11.2020, 21:47
nerd hat geschrieben:
11.11.2020, 21:12


Ja, wenn man nicht mehr als 3 seiten hat.
Wie kommst du den darauf?
Was machst du, wenn du 100 seiten hast, die adresse auf jeder seite im footer steht und sie sich aendert?
includes hast du nicht bei reinen html seiten, frames sind ziehmlich 1990 und die seite erst komplett runterladen, per text editor auf 100 seiten "suchen&ersetzen" (am besten noch mit regex, damit man auch tabs, whitespace, zeilenumbrueche ignoriert) durchlaufen lassen, keine garantie haben dass alles erwischt wurde (und nicht zuviel oder zu wenig!) und dann den ganzen salat wieder hochladen ist auch ziehmlich micky maus...

Mit einem vernuenftigen CMS sind es 5 handgriffe, die man auch vom handy aus jederzeit ohne extra apps erledigen kann.

Anzeige von:


Hochwertiger Linkaufbau bei ABAKUS:
  • Google-konformer Linkaufbau
  • nachhaltiges Ranking
  • Linkbuilding Angebote zu fairen Preisen
  • internationale Backlinks
Wir bieten Beratung und Umsetzung.
Jetzt anfragen: 0511 / 300325-0

staticweb
PostRank 9
PostRank 9
Beiträge: 2317
Registriert: 04.05.2016, 14:34

Beitrag staticweb » 12.11.2020, 07:02 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

> Was machst du, wenn du 100 seiten hast, die adresse auf jeder seite im footer steht und sie sich aendert?

SSG :-)

supervisior
PostRank 9
PostRank 9
Beiträge: 2718
Registriert: 26.06.2006, 09:11

Beitrag supervisior » 12.11.2020, 09:52 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

nerd hat geschrieben:
12.11.2020, 04:08
Was machst du, wenn du 100 seiten hast, die adresse auf jeder seite im footer steht und sie sich aendert?
includes hast du nicht bei reinen html seiten, frames sind ziehmlich 1990 und die seite erst komplett runterladen, per text editor auf 100 seiten "suchen&ersetzen" (am besten noch mit regex, damit man auch tabs, whitespace, zeilenumbrueche ignoriert) durchlaufen lassen, keine garantie haben dass alles erwischt wurde (und nicht zuviel oder zu wenig!) und dann den ganzen salat wieder hochladen ist auch ziehmlich micky maus...

Mit einem vernuenftigen CMS sind es 5 handgriffe, die man auch vom handy aus jederzeit ohne extra apps erledigen kann.
Nicht, dass ich ein Freund von statischen Seiten wäre, aber mit SMARTY gäbs schon ein inlcude von html Seiten. Das setzt zwar PHP voraus, aber wenn keine DB dranhängt, könnte man das tolerieren.

Und so 1990 sind iframes nun auch wieder nicht. Gelegentlich verwende ich schon iframes, aber nur zum Zwecke die Gesamtmenge an Daten für das Hauptdokument zu reduzieren, bzw. den iframe mittels AJAX verzögert zu laden. Heißt sich auch Client Side Scripting.

heinrich
PostRank 10
PostRank 10
Beiträge: 3034
Registriert: 17.08.2006, 11:26

Beitrag heinrich » 12.11.2020, 09:53 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

Also meine Erfahrung ist, dass man etwa WP-Seiten mit einem schlanken Theme genau so schnell liefern kann wie reine handgestrickte html-Seiten. Das Problem sind für mich aber dann immer AdSense oder andere Werbeanbieter, die trotz async oder defer bremsen! Und das unabhängig von der Bauweise!

supervisior
PostRank 9
PostRank 9
Beiträge: 2718
Registriert: 26.06.2006, 09:11

Beitrag supervisior » 12.11.2020, 11:30 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

heinrich hat geschrieben:
12.11.2020, 09:53
Das Problem sind für mich aber dann immer AdSense oder andere Werbeanbieter, die trotz async oder defer bremsen! Und das unabhängig von der Bauweise!
Vielleicht gibts ja eine Bauweise, die Du noch nicht kennst...? Ich hab mit meiner Bauweise in jedem Fall keine Probleme.

heinrich
PostRank 10
PostRank 10
Beiträge: 3034
Registriert: 17.08.2006, 11:26

Beitrag heinrich » 12.11.2020, 13:13 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

Ja. ich kenne deinen einschlägigen Thread, aber das alles hat letztlich keine Änderung gebracht! Das Problem sind und bleiben die komplexen animierten Ads.

Lyk
PostRank 10
PostRank 10
Beiträge: 3075
Registriert: 10.08.2009, 16:26

Beitrag Lyk » 12.11.2020, 13:20 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

nerd hat geschrieben:
12.11.2020, 04:08
Was machst du, wenn du 100 seiten hast, die adresse auf jeder seite im footer steht und sie sich aendert?
ändern^^
gibt editoren, die können alle 100 dokumente auf einmal ändern.

habs aber auch schon 4mal händisch gemacht, ganze 280 seiten 2 mal geändert. das waren mal eben 2240 dokumente die ich ändern musste.
hält sich jedoch im rahmen, besser als jeden monat updaten zu müssen, speed optimieren, server optimieren, bilder optimieren und den ganzen mist mit den codes und javascripts ;)

supervisior
PostRank 9
PostRank 9
Beiträge: 2718
Registriert: 26.06.2006, 09:11

Beitrag supervisior » 12.11.2020, 13:36 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

heinrich hat geschrieben:
12.11.2020, 13:13
Ja. ich kenne deinen einschlägigen Thread, aber das alles hat letztlich keine Änderung gebracht! Das Problem sind und bleiben die komplexen animierten Ads.
Meinst wirklich, dass ich wirklich alles aus dem Nähkästchen veröffentliche....? ;)

Benutzeravatar
arnego2
PostRank 9
PostRank 9
Beiträge: 2273
Registriert: 23.02.2016, 13:55
Kontaktdaten:

Beitrag arnego2 » 12.11.2020, 14:39 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

nerd hat geschrieben:
12.11.2020, 04:08

Was machst du, wenn du 100 seiten hast, die adresse auf jeder seite im footer steht und sie sich aendert?
includes hast du nicht bei reinen html seiten, frames sind ziehmlich 1990 und die seite erst komplett runterladen, per text editor auf 100 seiten "suchen&ersetzen" (am besten noch mit regex, damit man auch tabs, whitespace, zeilenumbrueche ignoriert) durchlaufen lassen, keine garantie haben dass alles erwischt wurde (und nicht zuviel oder zu wenig!) und dann den ganzen salat wieder hochladen ist auch ziehmlich micky maus...

Mit einem vernuenftigen CMS sind es 5 handgriffe, die man auch vom handy aus jederzeit ohne extra apps erledigen kann.
Sicher ist die Kontrolle zeitraubender aber der Vorteil bei html ist u.a. die Unanfälligkeit bei Updates, Leichtigkeit der Umzüge etc. Dazu kommt das bei Seiten in dem Ranking eine Rolle spielt und der Kunde selbst Content zufügen kann damit oft das Gegenteil erreicht.

Von 100 bis 10000 Unterseiten macht ein CMS sicher Sinn gerade wenn dabei auch öfter Mal Inhalt dazukommt. Nur bei 80 % der Seiten macht keiner mehr was. Wenn du weißt das Inhalt dazukommt bereitest du deine html Seite einfach darauf vor.
Wir haben schon Wordpress Onepager machen (müssen) weil der Auftraggeber darauf bestand.
Wordpress Joomla bei Seiten die praktisch Statisch bleiben ist es overkill.
Arnego2 <Webseiten Neu & Umbau ab 80 Euro>

heinrich
PostRank 10
PostRank 10
Beiträge: 3034
Registriert: 17.08.2006, 11:26

Beitrag heinrich » 12.11.2020, 14:53 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

supervisior hat geschrieben:
12.11.2020, 13:36
Meinst wirklich, dass ich wirklich alles aus dem Nähkästchen veröffentliche....? ;)
Immerhin hattest du am Ende des Threads resumiert, dass dein Ansatz nach den Google-Kriterien eher kontraproduktiv sein dürfte. Wenn ich die Ads welcher Provenienz auch immer weglasse, dann haben auch normale WP-Seiten mobil 98% bis 100%.

supervisior
PostRank 9
PostRank 9
Beiträge: 2718
Registriert: 26.06.2006, 09:11

Beitrag supervisior » 12.11.2020, 15:26 HowTo: Der ultimative Speedguide für Wordpress & Co. Part II

heinrich hat geschrieben:
12.11.2020, 14:53
Immerhin hattest du am Ende des Threads resumiert, dass dein Ansatz nach den Google-Kriterien eher kontraproduktiv sein dürfte. Wenn ich die Ads welcher Provenienz auch immer weglasse, dann haben auch normale WP-Seiten mobil 98% bis 100%.
Hab' ich inzwischen auch schon wieder widerlegt, bzw. eine Lösug dafür gefunden. Ein Kackmist ist dieses Content Shifting aber trotzdem.

Antworten
  • Vergleichbare Themen
    Antworten
    Zugriffe
    Letzter Beitrag