Comparación de velocidad: enlaces de ruta absoluta frente a relativa

Digamos que quiero vincular a un directorio padre ( http://example.com/library/) desde un subdirectorio ( http://example.com/library/html/basics/).

El enlace al directorio principal puede ser:

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

¿Existe una diferencia de velocidad en función de la forma en que escribo el enlace? No estoy preguntando sobre la velocidad de carga del sitio web, pero si hay una diferencia notable al recorrer el directorio.

— Jakub Kliský
fuente

¿Por qué crees que habría una diferencia al recorrer los directorios? En lo que respecta al servidor, es solo un éxito, el usuario en realidad no se "movería" de un directorio a otro, solo está solicitando otro recurso. Si alguien va example.comprimero y luego example.com/library/books/fiction/1984.htmlcon o sin "atravesar" todo el camino debería ser irrelevante. Y recuerde que tendrá varios usuarios: uno podría estar solicitando el directorio base, mientras que otro sería un anidado profundo y el servidor estaría haciendo el mismo trabajo.

— VLAZ

Las 3 de esas URL son idénticas cuando se trata de la solicitud HTTP, por lo que en lo que respecta al servidor, no hay diferencia: el navegador debe resolver la solicitud http://example.com/library/en los 3 casos, de lo contrario, simplemente no es válido.

— MrWhite

Una cosa perdida hasta ahora es el efecto en el mantenimiento del sitio. El uso /library/tiene las siguientes ventajas sobre las otras opciones: no necesita actualizar todos sus enlaces si cambia su nombre de dominio o se cambia a SSL en todas partes; si cambia el nombre de la carpeta, o mueve la carpeta secundaria, puede encontrar y reemplazar la ruta fácilmente,

— resolviendo

Respuestas:

Efecto para el navegador:

Aunque esto parece un poco de trabajo para el navegador web, pero técnicamente no hace mucha diferencia. Los navegadores son demasiado rápidos para manejar esta estructura de URL relativa y realizar una llamada al servidor de aplicaciones

Efecto para el servidor de aplicaciones:

Ninguno, ya que necesita devolver el archivo solicitado (el enlace relativo / absoluto finalmente se asigna a una ruta web)

Efecto sobre el tamaño de la página:

Sí, habría una reducción en el tamaño (de nuevo, no es algo que marcaría una gran diferencia en el rendimiento de su página que podría lograrse mediante algo como codificación de contenido gzip o recurso minificador)

Por lo tanto, creo que técnicamente las URL absolutas / relativas no hacen una gran diferencia en la velocidad de la página / cualquier matriz ponderable .

Sí, hace una gran diferencia en la gestión de múltiples entornos como dev, pp, prodpp, etc.

Ejemplo: en su desarrollo local, puede tener dev.example.com en preproducción, puede tener: pp.example.com. .

Entonces, en esos escenarios, sería relativamente fácil administrar el código con direcciones URL relativas (aunque también se puede administrar mediante la configuración del entorno)

— abhinsit
fuente

Las rutas basadas en HTML / CSS relativas siempre serán más rápidas para la velocidad del servidor, esto se debe a que el servidor tiene menos código para enviar. Las rutas relativas en formato HTML o CSS son traducidas por el navegador del usuario final y no por el servidor.

Técnicamente, es más rápido para el servidor y más lento para el usuario final, pero el usuario final nunca notaría la diferencia, ya que el procesamiento requerido es inferior a nanosegundos, por lo tanto, es mucho más probable que los usuarios finales vean la diferencia. relativo porque el servidor podrá servirles mejor.

— Simon Hayter
fuente

"Las rutas basadas en HTML / CSS relativas siempre serán más rápidas para la velocidad del servidor, esto se debe a que el servidor tiene menos código para enviar". Realmente no lo creo. Si bien http://example.com/category/cats.htmles más largo que /category/cats.html, no puedo ver que esto tenga un impacto lo suficientemente significativo en el rendimiento como para ser considerado. Descomprimir los datos enviados, que toma fracciones de segundo, ya cubriría la "ineficiencia de tamaño" y cualquier "penalización de velocidad" que imponga.

— VLAZ

Dije técnicamente más rápido ... y estás escogiendo cuerdas. incluso con la compresión en caché usando gzip, una página html con absoluto vs relativo será un poco más grande (gz relativo vs gz absoluto), por lo tanto técnicamente ... el usuario final tiene que descompilar ese gzip y resolver el relativo, esto es más lento para el usuario final ... pero esto es tan mínimo que el usuario final no lo notará, nuevamente esto es un hecho. Incluso con tecnologías del lado del servidor, como GZIP, un archivo HTML comprimido o un archivo CSS que utiliza rutas relativas frente a absoluto, el relativo siempre será más pequeño en un archivo comprimido, de nuevo, esto es un hecho, pruébelo.

— Simon Hayter

Si bien la diferencia puede ser solo unos pocos bytes o pocos kb en páginas más grandes, el ahorro para un visitante no es importante, pero en los millones de usuarios se hace más notable ... por lo tanto, técnicamente más rápido. Ahora, si está preguntando si vale la pena usar relativo versus absoluto para el sitio web promedio con solo unos pocos cientos de visitas al día. la respuesta es probablemente no ... pero esa no era la pregunta que se hacía.

— Simon Hayter

El éxito en el rendimiento, en el mejor de los casos, será insignificante. También podría ser completamente inexistente. Los servidores son generalmente buenos en una cosa. Está en su nombre, sirviendo contenido. No creo que unos pocos bytes o un KB sean un problema. Es solo contenido, al final. Si el tamaño fuera un problema, el HTML que escribimos se vería muy diferente. Ese no es el caso. La minificación del contenido es puramente para conveniencia del usuario en caso de que su ancho de banda sea pequeño. Estoy seguro de que procesar la solicitud y responder es donde está el rendimiento, no en el acto real de enviar los datos.

— VLAZ

"las rutas relativas siempre serán más rápidas para la velocidad del servidor", pero el OP dice: "No estoy preguntando sobre la velocidad de carga del sitio web", que es el único lugar donde el sitio podría ser más rápido. (Para ser sincero, no estoy realmente seguro de qué "velocidad" está hablando el OP?)

— MrWhite