SSI vs. PHP -> Geschwindigkeit,Suchmaschinen,Vor- u. Nachteile
0 0 0 0 0 0 
Marian
0
SSI vs. PHP -> Geschwindigkeit,Suchmaschinen,Vor- u. Nachteile
Hallo,
Ich möchte in mein Webprojekt (was zur Zeit nur aus HTML Setien besteht)
Datenbankinhalte einfügen.
Ich habe es sowohl mit SSI (mit Perl-Aufruf) und PHP probiert, beides geht.
Der Server ist so konfiguriert das ich direkt in HTML Seiten (.html) SSI
(also mit Perl-Aufruf) einbinden kann.
Nach meinem jetzigen Wissen hätte ich bei SSI -> eine Seite mit .html
und mit PHP eine Seite mit .php. (Die Inhalte sind immer HTML). Mit beiden
Lösungen können die Anforderungen erfüllen. Ich hätte aber gern alles im
HTML-Format. (Ansichtsache lasse mich auch überzeugen)
Was ist nun besser geeignet im Bezug auf die folgenden Punkt:
- Geschwindigkeit beim Aufruf
- Suchmaschinenoptimierung
- Serverbelastung
- andere Vor- Nachteile
Ist es Gefährlich SSI's als normale HTML's auszuführen? (EXEC Commands habe ich
deaktiviert im Apache)
Sind Parameter-Aufruf z.B. "index.php?param123" nachteilig - Problematisch für
Suchmaschinen?
-
hi
Ich hätte aber gern alles im
HTML-Format. (Ansichtsache lasse mich auch überzeugen)Wenn du deinen Webserver entsprechend konfigurierst ist das kein Problem.
so long
Ole
(8-)>--
Stickstoff eignet sich nicht für Handarbeiten. -
Hallo,
ich würde nicht über den Umweg, erst SSI aufrufen zu müssen, gehen, um dann doch eine Scriptsprache aufzurufen, die ebenso Includes abarbeiten kann. Ein nennenswerter Geschwindigkeitsvorteil erwächst Dir zwar nicht aus dem direkten Aufruf der Scripte, aber SSI ist hier dennoch fehl am Platz.
Eine Suchmaschinenoptimierung wird zu keiner Zeit durch Deine Überlegungen tangiert. Da bitte ich gegebenenfalls um genauere Erklärungen.
Gruß aus Berlin!
eddi-
Hi,
Eine Suchmaschinenoptimierung wird zu keiner Zeit durch Deine Überlegungen tangiert. Da bitte ich gegebenenfalls um genauere Erklärungen.
da hatte ich vor einigen Wochen schonmal kurz drauf hingewiesen. Es gibt wohl aus den "Anfängen" der Suchmaschinen, also inbesondere die traditionellen Altavista, Excite etc. ein Design-Paradigma "stay away from dynamic extensions", mit dem Hintergrund "eine dynamische Seite zu indizieren lohnt nicht". Für Google und Konsorten heute wird das wohl nicht mehr gelten, aber zumindest scheint es mal ein derartiges Problem gegeben zu haben.
MfG
Rouven--
-------------------
ie:| fl:| br:> va:| ls:& fo:) rl:( n4:{ ss:) de:] js:| ch:? mo:} zu:|-
Hallo,
da hatte ich vor einigen Wochen schonmal kurz drauf hingewiesen. Es gibt wohl aus den "Anfängen" der Suchmaschinen, also inbesondere die traditionellen Altavista, Excite etc. ein Design-Paradigma "stay away from dynamic extensions", mit dem Hintergrund "eine dynamische Seite zu indizieren lohnt nicht". Für Google und Konsorten heute wird das wohl nicht mehr gelten, aber zumindest scheint es mal ein derartiges Problem gegeben zu haben.
da wäre eher interessant, ob dies heutzutage auch noch zutreffend ist; wenn ja, dann ist entscheident, welche Kriterien zur Identifizierung eines dynamischen Dokuments herangezogen werden. Sind es nur die Dateinamenserweiterungen (.cgi/.shtml/.php), so bedarf es dennoch SSI nicht. Dies ließe sich durch entsprechende Serverkonfigurationen bei angepaßter Strukturierung des Projekts (auf Ebene des Dateisystems) genauso realisieren. Sind es darüber hinaus auch die HTTP-Header wird es etwas schwerer.
Gruß aus Berlin!
eddi-
Hallo,
da wäre eher interessant, ob dies heutzutage auch noch zutreffend ist; wenn ja, dann ist entscheident, welche Kriterien zur Identifizierung eines dynamischen Dokuments herangezogen werden. Sind es nur die Dateinamenserweiterungen (.cgi/.shtml/.php), so bedarf es dennoch SSI nicht. Dies ließe sich durch entsprechende Serverkonfigurationen bei angepaßter Strukturierung des Projekts (auf Ebene des Dateisystems) genauso realisieren. Sind es darüber hinaus auch die HTTP-Header wird es etwas schwerer.
Man tut sich mit session ids etwas schweer weil sich die eindeutige bezeichnung der ressource bei jedem besuch ändert. Wenn die URL sich aber nicht ändert dann gibt es keine Probleme. Wäre ja heutzutage auch schlimm.
Grüße
Jeena Paradies -
Hallo eddi,
da wäre eher interessant, ob dies heutzutage auch noch zutreffend ist; wenn ja, dann ist entscheident, welche Kriterien zur Identifizierung eines dynamischen Dokuments herangezogen werden. Sind es nur die Dateinamenserweiterungen (.cgi/.shtml/.php), so bedarf es dennoch SSI nicht. Dies ließe sich durch entsprechende Serverkonfigurationen bei angepaßter Strukturierung des Projekts (auf Ebene des Dateisystems) genauso realisieren. Sind es darüber hinaus auch die HTTP-Header wird es etwas schwerer.
AFAIK werden da einfach alle Seiten mit Fragezeichen im URL nicht indiziert.
Viele Grüße aus Freiburg,
Marian--
Microsoft broke Volkswagen's world record: Volkswagen only made 22 million bugs!
<!--[if IE]><meta http-equiv="refresh" content="0; URL=http://www.getfirefox.com"><[endif]-->
Mein SelfCode: ie:{ fl:( br:> va:) ls:[ fo:) n4:( ss:) de:] js:| ch:? mo:} zu:)-
Hallo Marian,
AFAIK werden da einfach alle Seiten mit Fragezeichen im URL nicht indiziert.
Das stimmt so pauschal nicht. Man kann zwar davon ausgehen, dass ein Fragezeichen die Wahrscheinlichkeit verringert, dass die Seite indiziert wird, allerdings heißt das nicht pauschal, dass solche Seiten ausgeschlossen werden, wenn ich http://www.google.com/search?q=shop aufrufe sehe ich unter den ersten 10 Suchbegriffen 2 Seiten deren URLs eine Query-String enthalten (mir geht's hier nur um's Prinzip, der Suchbegriff ist willkürlich gewählt und die Seiten habe ich mir nicht angesehen).
Viele Grüße,
Christian--
"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." - Bjarne Stroustrup
-
-
Hi,
Sind es darüber hinaus auch die HTTP-Header wird es etwas schwerer.
Natürlich spielen die auch eine wichtige Rolle. Statische Seiten werden i.d.R. mit eindeutigen Informationen ausgeliefert, die es Suchmaschinen ermöglichen, sie als bekannt oder neu einzustufen. Bei dynamischen Seiten müßte man diese Headerinformationen meist selbst setzen, was aber kaum gemacht wird.
Was die Parameter betrifft, so hatte ich festgestellt, daß Google _einen_ Parameter durchaus mag; konkret waren einige statische Seiten ohne Parameter aufrufbar, aber auch mit diversen Parametern (von Javascript ausgewertet). Google listete die URLs mit Parameter vorrangig, was aber vielleicht an der externen Verlinkung lag.
Ich denke, daß ein Parameter für Google lediglich die erste Navigationsebene beschreibt und genauso berücksichtigt wird, wie Links ohne Parameter. Bei mehreren Parametern sieht es dann erfahrungsgemäß wirklich viel schlechter aus.freundliche Grüße
Ingo
-
-
-
