End-Slash langsamer als ohne in der URL?

Hallo,
die Beispiele zur Permalink-Struktur von Wordpress in deren offiziellen Anleitung setzt am Schluss bei der "custom structure"
einen Slash "/", siehe http://codex.wordpress.org/Using_Permalinks#Choosing_your_permalink_structure
Also z.B. steht da: /%postname%/

Könnte man den genauso gut weglassen?

Googeln ergibt, dass es scheinbar keine Rolle spielt, solange man konsequent bei einem von beiden bleibt und so kein duplicate content entsteht. Leuchtet ein.
Manche sagen, ohne Slash wäre langsamer.

WP selbst nennt keine Begründung, aber es wird wohl kein Zufall sein, wenn sie sich - wenngleich kommentarlos - für den Slash entscheiden?

Grundsätzlich hängt es vom der verwendeten Server-Software (in diesem Fall WordPress) ab, ob ein Slash am Ende wichtig ist oder nicht. Bei einer strikten Implementierung könnte man z.B. unter "/abc" und "/abc/" verschiedene Seiten aufrufen, aber das sollte man natürlich vermeiden, weil es nur Verwirrung stiftet.

Den Geschwindigkeitsunterschied will ich sehen Vielleicht ist einer da, den man bei 1000 gleichzeitigen Requests irgendwo im Millisekundenbereich nachweisen kann. Der Algorithmus schaut ja in jedem Fall "wo ist mein String zu ende?" und da gibt's nicht viele Möglichkeiten (exakt in dieser Reihenfolge!):
1. Slash
2. Fragezeichen
3. Ende der URL
Also es könnte im Schlimmsten Fall sein, dass er 2 zusätzliche Zeichenvergleiche braucht. Das fällt vielleicht ins Gewicht, wenn du ein paar hundert tausend Besucher am Tag hast.

Grund für die Reihenfolge, eine URL kann so aussehen:
http://localhost/blablabla/
http://localhost/blablabla?q=abc
http://localhost/blablabla

Möglich wäre natürlich auch, dass - wenn man vorher festgelegt hat, dass es auf einen Slash endet - es schneller geht, weil die anderen beiden Vergleiche überhaupt nicht ausgeführt werden.

Du kannst das ja mal benchmarken und dann mitteilen wie viele Requests pro Sekunde man braucht, um 1ms Unterschied zu sehen.

Vielleicht nicht wegen dem Server, sondern dem Browser, der wie bei einem Redirect dann noch ein zweites Mal tätig wird?

Ich weiß nicht, ob er das tut, aber wenn, dann würde sich das vermutlich auswirken.

Wenn der Server einen Redirect schickt für so eine Kleinigkeit, dann hat da jemand ganz großen Mist implementiert. Der soll ja nur ein paar Daten ausliefern und er weiß ja offensichtlich was gemeint ist (sonst könnte er den Redirect nicht machen), also weißt er auch wo er die Daten herbekommt.

Ein Redirect verwendet man, wenn man auf eine andere Domain weiterleiten will oder auf ein anderes System auf derselben Domain (z.B. für SSO), aber nicht so für 'nen trivialen Kram.


EDIT: Und ob der Browser 2x Daten anfordert kannst du auch einfach überprüfen indem du das Inspector Fenster und den Network Tab darin öffnest.

Sorgt den nicht WP selbst ggf. für Redirects in solchen "Trivialfällen", durch deren Standard-Code, den WP selbst in die htaccess schreibt?

Das weiß ich nicht, aber ich hoffe doch nicht, wäre schon irgendwie peinlich für so ein großes System

Hast du es nicht zufällig irgendwo laufen und kannst es testen? Sollte sich dann ja in <5 Minuten klären lassen.

benneque schrieb:

Wenn der Server einen Redirect schickt für so eine Kleinigkeit, dann hat da jemand ganz großen Mist implementiert.

Zum Vergrößern anklicken....

Nicht unbedingt. SEO-technisch macht so ein Redirect durchaus Sinn. domain.tld/blabla und domain.tld/blabla/ sind 2 unterschiedliche URLs. Würden sie den selben Inhalt kodieren, dann muss hier zwingend entweder ein Canonical-Tag her oder gleich ein SEO-Redirect.

Dass es 2 verschiedene URLs sind hab ich ja oben schon gesagt, aber grundsätzlich (finde ich) sollte man es als ein und dieselbe behandeln, wegen Verwechslungsgefahr und weil es auch semantisch keinen Sinn ergibt 2 verschiedene Resources auszugeben.

Im Grunde wäre für so einen Fall natürlich ein HTTP 301 gedacht, der dann aber eigentlich mitteilt, dass die Ursprungsseite (also da wo der Link steht) nicht mehr up-to-date ist bzw. sich nicht an die Konventionen hält.

Also "ja", im Grunde sollte es nur eine der beiden URLs geben, bzw. wenn es beide gibt bekommt eine ein 301 Code. Das Resultat ist dann aber im Grude, dass niemand die falsche URL zu Gesicht bekommt, weil sofort weitergeleitet wird und wenn der Link irgendwo eingebettet wird, ist es dann auch der ohne Redirect, also ist es im Grunde wieder völlig irrelevant bzgl. Performance.

Was für ein Durcheinander, vielleicht steigt ja jemand durch meinen morgendlichen Brain-Flow durch.

Na ja, es ist schon ein Redirect, eben ein 301 Permanent. Aber das Ding kostet keine nennenswerte Zeit.

Naja, können gut und gerne 40-50ms sein bei 'ner durchschnittlichen DSL Leitung. Wenn man mit UMTS unterwegs ist, sind es eher 100-300ms, wobei da die Seite am Ende so lange lädt, dass es nicht mehr ins Gewicht fällt.

Aber nun wissen wir immer noch nicht wie WordPress damit umgeht

Sinnvolle Geschwindigkeitstests kann ich nicht bieten.

WP kennt jedenfalls das Thema als DC-Gefahr und leitet per default um. Wenn du eine URL ohne slash hast und jemand gibt mit slash ein, wird korrekt umgeleitet auf "ohne". Umgekehrt genauso.

Dachte immer, "normal" sei der Slash als ein Zeichen für ein Verzeichnis. Bei WP wird aber per default jede URL jeder Seite mit so einem slash beglückt. Das ließe vermuten, dass sie sich dabei was gedacht haben.

Nö, das sind einfach Naming Conventions, die jeder für sich trifft. Apple hat z.B. trailing slashes, andere Seiten haben keinen.... und Contao-basierte Seiten haben üblicherweise .html hinten dran.

Standardmäßig .html hinten dran? Ha!

Na, dann muss ich mir ja keine Sorgen machen, dass das auf Dauer ausstirbt, siehe anderer Thread.
Wobei ich mittlerweile weiß, dass selbst bei meiner Variante "internes URL-Rewrite + .html" behalten" das .html bei den Sumas wegfällt, solange ich das canonical nicht rausbringe, das WP immer automatisch erzeugt.

Lasse ich es drin - "einfach" rausnehmen verhindert mein Theme - habe ich ohne 301 letztlich doch so etwas Ähnliches, nur ohne Redrect und mit weniger der genannten Nachteile.

URLs sind halt eine völlig beliebige Sache, die vom Server interpretiert wird. Den kann man auch so programmieren, dass er die Zeichenfolge "DiesIstDasTrennzeichen" als Trennzeichen benutzt und dafür den Slash als Zeichen im Resource-Namen akzeptiert. Macht natürlich keiner, weil man sich auf die Slash=Trennzeichen-Konvention geeinigt hat.

Genau so ist es Sache des Servers, ob er Trailing Slashes mit einem Redirect beantwortet. Ich finde diese Praxis etwas "unglücklich" (manche würden es vielleicht "praktisch" nennen), denn als Entwickler lege ich fest welche Form die URLs haben sollen und dann sollten sich die Clients auch dran halten oder sie bekommen halt eine 404, wenn der Link nicht korrekt ist.
Im Normalfall wird ja im Web eh nur mit Copy&Paste gearbeitet, und wenn nicht jemand absichtlich den Slash da hinten dran klatscht, geht auch alles gut.

Das ist ähnlich wie bei vielen Usern hier im Forum, da heißt es: "Ich lasse einfach alle Satzzeichen (besonders die Punkte/Fragezeichen am Ende des Satzes) weg und der Leser wird das schon korrekt interpretieren". Funktioniert zwar oft, aber ich würde auf die Frage dann halt einfach mit "404" antworten
Bekanntes Beispiel: "komm wir essen opa". Ruft da jemanden seinen Großvater zum Essen oder hat jemand den Einfall mit seinem Geschwisterchen den Großvater zu verspeisen?


Meine Systeme arbeiten meist so:
- URLs mit Slash am Ende gibt's nicht.
- Punkte und Slashes sind im Resource Namen verboten, weil Punkte für die Extension (siehe Szenario #2) und Slashes für die Verschachtelung von Resources genutzt werden.

Szenario #1:
1. User ruft "http://.../blabla" auf
2. Server entscheidet anhand des "Accept" Headers, in welchem Format der Inhalt ausgeliefert werden soll, z.B. "Accept: text/html" oder "Accept: application/xml", etc.

Szenario #2:
1. User ruft "http://.../blabla.json" auf
2. Server wählt das Format anhand der "Extension" (also in diesem Fall "json" aus) und ignoriert den "Accept" Header

Man könnte das Ganze auch noch zusätzlich per URL Parameter machen, also z.B. "http://.../blabla?format=xml", aber an sich unnötig wenn man schon die URL Extension anbietet.

Habe folgenden Artikel dazu gefunden:
http://alistapart.com/article/slashforward

Verstehe ich den Artikel richtig, dass ein performance-schädlicher zusätzlicher Request mit Slash nur dann stattfindet, wenn
1.Ein Verzeichnis existiert und aufgerufen werden soll und
2.Der fehlende Slash bei den meisten Servern dann dazu führt, dass er zunächst von einer Datei ausgeht, die er nicht findet ?

Da in meinem Fall immer Dateien URLs "ohne Slash" erhalten, kann dieser evtl. zu einem 2. Request führende Fall gar nicht eintreten.
Und selbst wenn, hinge es noch vom Server ab, was der macht...

--> bei Verzeichnissen besser mit Slash, bei allem anderen ohne

Na vor allem übertreibt der Artikel maßlos...
And most importantly, we’re doing our visitors a favor, because they’re no longer losing a few seconds...
MILLIsekunden trifft es eher.

Außerdem: Das übliche URL Rewriting in Verbindung mit ner Router-Funktion läuft IMMER auf Folgendes hinaus:
Wenn der "aufgerufener Pfad" weder als Verzeichnis noch als Datei existiert, dann sende den Pfad als Parameter an die index.php (oder was es eben für eine Sprache ist) und füttere von da aus den Router.

Das heißt im Umkehrschluss, dass IMMER geprüft wird, ob der Pfad eine real im Dateisystem existierendes Objekt ist. Und weißt du was? SCHEISS DRAUF! Wozu gibts Caching? Abermillionen Server ticken so, und nirgendwo gibts Probleme.