Confronto di velocità - collegamenti di percorso assoluti vs relativi

Diciamo che voglio collegarmi a una directory principale ( http://example.com/library/) da una sottodirectory ( http://example.com/library/html/basics/).

Il collegamento alla directory principale può essere:

href="../../"
href="https://webmasters.stackexchange.com/library/"
href="http://example.com/library/"

C'è una differenza di velocità in base al modo in cui scrivo il link? Non sto chiedendo della velocità di caricamento del sito Web, ma se c'è una notevole differenza mentre si attraversa la directory.

— Jakub Kliský
fonte

Perché pensi che ci sarebbe una differenza nel percorrere le directory? Per quanto riguarda il server, è solo un successo, l'utente in realtà non si "muoverà" da una directory all'altra - stanno solo richiedendo un'altra risorsa. Se qualcuno va example.comprima e poi example.com/library/books/fiction/1984.htmlcon o senza "attraversare" tutto il percorso dovrebbe essere irrilevante. E ricorda che avrai più utenti: uno potrebbe richiedere la directory di base, mentre un altro è profondamente annidato e il server farebbe lo stesso lavoro.

— VLAZ,

Tutti e 3 questi URL sono identici quando si tratta della richiesta HTTP, quindi per quanto riguarda il server, non c'è alcuna differenza: il browser deve risolvere la richiesta http://example.com/library/in tutti e 3 i casi, altrimenti semplicemente non è valido.

— MrWhite,

Una cosa mancata finora è l'effetto sul mantenimento del sito. L'utilizzo /library/presenta i seguenti vantaggi rispetto alle altre opzioni: non è necessario aggiornare tutti i collegamenti se si modifica il nome del dominio o si passa a SSL ovunque; se cambi il nome della cartella o sposti la cartella figlio puoi trovare e sostituire facilmente il percorso,

— scoprendo

Risposte:

Effetto per il browser:

Anche se questo sembra un po 'di lavoro per il browser web, ma tecnicamente non fa molta differenza. I browser sono troppo veloci per gestire questa struttura relativa dell'URL ed effettuare una chiamata al server delle applicazioni

Effetto per il server delle applicazioni:

Nessuna, poiché deve restituire il file richiesto (il collegamento relativo / assoluto alla fine si associa a un percorso Web)

Effetto sulla dimensione della pagina:

Sì, ci sarebbe una certa riduzione delle dimensioni (di nuovo non qualcosa che farebbe una grande differenza per il rendimento della tua pagina che potrebbe essere ottenuto da qualcosa come la codifica dei contenuti gzip o la riduzione delle risorse)

Quindi penso che tecnicamente gli URL assoluti / relativi non facciano molta differenza sulla velocità della pagina / qualsiasi matrice pesabile .

Sì, fa un'enorme differenza nella gestione di più ambienti come dev, pp, prodpp ecc

Esempio: sul tuo sviluppo locale potresti avere dev.example.com in pre-produzione potresti avere: pp.example.com. .

Quindi in quegli scenari sarebbe relativamente facile gestire il codice con relativi URL (anche se può essere gestito anche dalle impostazioni dell'ambiente)

— abhinsit
fonte

I percorsi basati su HTML / CSS saranno sempre più veloci per la velocità del server, questo perché il server ha meno codice da inviare. I percorsi relativi in formato HTML o CSS vengono tradotti dal browser dell'utente finale e non dal server.

Quindi tecnicamente, è più veloce per il server e più lento per l'utente finale, ma l'utente finale non noterebbe mai la differenza, poiché l'elaborazione richiesta è inferiore a nano-secondi, quindi gli utenti finali hanno molte più probabilità di vedere la differenza da relativo perché il server sarà in grado di servirli meglio.

— Simon Hayter
fonte

"I percorsi basati su HTML / CSS saranno sempre più veloci per la velocità del server, questo perché il server ha meno codice da inviare." Non ci credo proprio. Anche se http://example.com/category/cats.htmlè più lungo di /category/cats.html, non riesco a vedere che abbia un impatto abbastanza significativo sulle prestazioni da essere considerato. La compressione dei dati inviati, che richiede frazioni di secondo, coprirebbe già sia la "inefficienza delle dimensioni" sia qualsiasi "penalità di velocità" che impone.

— VLAZ,

Ho detto tecnicamente più veloce ... e stai scegliendo le corde. anche con la compressione memorizzata nella cache usando gzip, una pagina html con assoluto vs relativo sarà leggermente più grande (relativo gz vs assoluto gz), quindi tecnicamente ... l'utente finale deve decompilare quel gzip e risolvere il relativo, questo è più lento per l'utente finale ... ma questo è così minimo che l'utente finale non se ne accorgerà, di nuovo questo è un dato di fatto. Anche con tecnologie lato server come GZIP un file HTML compresso o file CSS che utilizza percorsi relativi vs assoluti, relativo sarà sempre più piccolo in un file compresso, anche in questo caso, provalo.

— Simon Hayter

Mentre la differenza può essere solo di pochi byte o pochi kb su pagine più grandi, i risparmi per un visitatore non sono importanti, ma nei milioni di utenti che diventano più evidenti ... quindi, tecnicamente più veloci. Ora, se ti stai chiedendo se valga la pena utilizzare il relativo rispetto assoluto per il sito Web medio con solo poche centinaia di visite al giorno? la risposta è probabilmente no ... ma non era questa la domanda.

— Simon Hayter

Il colpo di scena, nella migliore delle ipotesi, sarà trascurabile. Potrebbe anche essere del tutto inesistente. I server sono generalmente bravi in una cosa. È nel loro nome - serve il contenuto. Non credo che pochi byte o un KB sarebbero un problema. È solo contenuto, alla fine. Se le dimensioni fossero un problema, l'HTML che scriviamo sarebbe molto diverso. Non è così. La minimizzazione del contenuto è puramente per comodità dell'utente nel caso in cui la larghezza di banda sia ridotta. Sono fiducioso che l' elaborazione della richiesta e la risposta è dove si trova la prestazione, non nell'atto effettivo di invio dei dati.

— VLAZ,

"i percorsi basati relativi saranno sempre più veloci per la velocità del server" - ma l'OP afferma "Non sto chiedendo della velocità di caricamento del sito Web" - che è l'unico posto dove il sito potrebbe essere più veloce. (Ad essere sincero, non sono davvero sicuro di quale "velocità" stia parlando l'OP?)

— MrWhite