Dynamisch = schlechte Performance = schlechtes Ranking?

[Andreas 2012]

Hallo SEO-Freunde,

der Inhalt meiner Homepage besteht größtenteils aus Daten (Namen u. Zahlen), die ich in tabellarischer Form ausgebe. Bisher habe ich alles statisch in Handarbeit aufgebaut. Nun spiele ich mit dem Gedanken, diese Daten in eine MySQL-DB umzuschaufeln und die html-Tabellen künftig über eine Schleife automatisch von dieser DB befüllen zu lassen.

Dass Google mit dynamischen Webseiten keine Probleme mehr hat, ist ja bekannt. Aber kommen dynamische Seiten der genannten Art auch von der Bewertung her an statische Seiten heran? Denn die Performance ist ja wohl um einiges schlechter bzw. hängt ja von der Geschwindigkeit des DB-Servers ab. Wie ist eure Erfahrung aus SEO-Sicht?

Vielen Dank für Eure Antworten im voraus.

Andreas

[Aiken]

db server sollte im gleichen netzwerk oder auf gleicher kiste (localhost), performance veraenderungen wuerde man eigentlich dann nicht spueren..

[mtx93]

Kommt auf die Datenbank an.

Wenn ich dich richtig verstehe, sind die Daten nicht Echtzeit?

Dann Nginx + memcached als Server installieren (sollte man eh tun) und die erzeugten Seiten dann je nach Laune cachen. Da gibt es genug tutorials im Netz, wie das geht.

Debian + Dotdeb bietet nginx + memcached schon als updated package.

Einfach hier das passende package raussuchen.
https://docs.google.com/spreadsheet/ccc ... 2YVE#gid=0

Dotdeb gibt es hier: https://www.dotdeb.org/

[Andreas 2012]

Vielen Dank für Eure Antworten

@mtx93: Leider habe ich bzgl. DB und Server keine Hintergrundkenntnisse. Die Daten werden praktisch erst auf Anfrage (sprich bei Seitenaufruf) aus der DB gezogen. Meintest du das mit "Daten nicht in Echtzeit"?

Nginx und memcached sagt mir leider gar nichts, könntest du kurz erläutern, was das ist? Kann man sowas denn einfach selbst installieren? Ich habe ja keinen eigenen Server bzw. meine Seiten liegen doch bei einem Hoster.

Prinzipiell hört sich das mit dem Cache plausibel an. Heißt das, Google sieht praktisch keinen Unterschied zu einer statischen Seite?

Gruß, Andreas

[luzie]

Ja, ge-cachte Datenbankausgaben _sind_ statische Seiten.

Zwar ist das mit dem Cachen eine gute Idee, ich glaube aber das sollte gar nicht mal nötig sein. Ich betreibe selbst ein solches Konstrukt, bei dem Seiten on-the-fly aus einer MySQL DB zusammengebastelt werden, das geht üblicherweise ruck-zuck, der Performance-Verlust gegenüber statischen Seiten ist minimal (etwa 0.7 Sekunden statt 0.5 Sekunden für die Ausgabe einer Seite, laut Google Webmastertools)

[seonewbie]

Würde es erst mal ganz normal probieren wie Luzie schon sagt
gibt es meist keine Probleme.

Wenn es dann nicht funzt mit Apache und mysql denn memcache
installieren und erst wenn der Server am Limit ist Nginx. Nginx
ist zwar sehr schnell nur spielt er das erst bei sehr vielen gleichzeitigen
Anfragen richtig aus. Weiter finde ich Nginx für SEO oft problematisch
da Nginx htaccess nicht kann und eine andere Syntax nutzt.

Sicher für Wordpress und div CMS gibt es htaccess für Nginx aber
man muß jeden SEO Tip erst mal "übersetzen" was bei komplizierter
Syntax echt nerven kann.

[Andreas 2012]

Danke euch für die Tips

Ich denke, ich werde es erst mal ohne Cache versuchen, um zu sehen, wie schnell der Seitenaufbau ist. Ansonsten setze ich mich mit dem Thema Caching noch mal auseinander.

Gruß, Andreas

[Beloe007]

Ca. 110 Queries -> Seite in 0.043 Sekunden generiert.
Ca. 200 Queries -> Seite in 0.650 Sekunden generiert.

Bei Onlineshops mit vielen Features eine fast normale Querieanzahl. Es kommt nur darauf an wie das Ganze umgesetzt ist.

[mtx93]

Ja, ge-cachte Datenbankausgaben _sind_ statische Seiten.

Zwar ist das mit dem Cachen eine gute Idee, ich glaube aber das sollte gar nicht mal nötig sein. Ich betreibe selbst ein solches Konstrukt, bei dem Seiten on-the-fly aus einer MySQL DB zusammengebastelt werden, das geht üblicherweise ruck-zuck, der Performance-Verlust gegenüber statischen Seiten ist minimal (etwa 0.7 Sekunden statt 0.5 Sekunden für die Ausgabe einer Seite, laut Google Webmastertools)

Das Problem ist ein anderes - bei shared hosts usw. sind die DB Zugriffe limitiert weil sie CPU time verbrauchen. Die Skalieren schnell hoch und die VM, die hinter einem VPS/shared host steht, blockiert dann den thread.

Das sind dann diese seltsamen Zugriffsstörungen, die man oft bei shared hosts sieht. Da kommt eine Seite 3-4 mal sehr schnell, dann dauert es auf einmal. Da wurde dann der thread und damit der DB Zugriff nach hinten geschoben.

Caching verhindert erstens hammering und sorgt für eine sehr viel bessere CPU time - das hilft sehr bei der Performance auf non-roots.

Ich gehe mal davon aus, das der TO seine Seiten eher auf einen shared host hat als auf einen eigenen Server.

[mtx93]

Würde es erst mal ganz normal probieren wie Luzie schon sagt
gibt es meist keine Probleme.

Wenn es dann nicht funzt mit Apache und mysql denn memcache
installieren und erst wenn der Server am Limit ist Nginx. Nginx
ist zwar sehr schnell nur spielt er das erst bei sehr vielen gleichzeitigen
Anfragen richtig aus. Weiter finde ich Nginx für SEO oft problematisch
da Nginx htaccess nicht kann und eine andere Syntax nutzt.

Sicher für Wordpress und div CMS gibt es htaccess für Nginx aber
man muß jeden SEO Tip erst mal "übersetzen" was bei komplizierter
Syntax echt nerven kann.

Der Link hier sollte helfen:
https://www.anilcetin.com/convert-apach ... -to-nginx/

[Barthel]

Heißt das, Google sieht praktisch keinen Unterschied zu einer statischen Seite?

Es gibt für Google keinen Unterschied zwischen einer statischen und einer dynamischen Seite. Der Bot liest nur den fertigen Code. Ob du den als statische Seite gespeichert hast oder dynamisch erstellen lässt, ist zunächst egal. Problematisch wird es nur, wenn das Erstellen der Seite zu lange dauert, weil z.B. die DB zu langsam ist. Das Problem kannst du mit einem Cache umgehen. Hier wird beim ersten Aufruf dynamisch eine Seite erstellt und die dann im Cache gespeichert. Die folgenden Besucher bekommen dann diese statische Seite gezeigt, die nun nicht ständig neu erzeugt werden muss.

[Cognac]

Ca. 110 Queries -> Seite in 0.043 Sekunden generiert.
Ca. 200 Queries -> Seite in 0.650 Sekunden generiert.

Bei Onlineshops mit vielen Features eine fast normale Querieanzahl. Es kommt nur darauf an wie das Ganze umgesetzt ist.

Ich glaube, diese Beispiele verdeutlichen dem Threaderöffner, dass seine Daten in Nullkommanichts generiert werden. Wenn irgendwelche bisherigen Daten ausgegeben wurden, sollte ein geschickter Query reichen. Und wenn es zudem noch eine Seite mit recht wenig Traffic ist, spielt nicht einmal mtx' Post eine Rolle.

Viel entscheidender sind dann aller Wahrscheinlichkeit nach eher Dinge wie Sprites, zu große CSS etc., da lässt sich wohl mehr Performance herausholen (Webpage Speedtests)