Rendimiento: URL absolutas vs. relativas

Question

¿Qué es más rápido? Hot linking (inline linking) a un absolute URI o alojando el recurso usted mismo y usando un relative URI?

En su tutorial on how to style HTML5 elements in Internet Explorer, Remy Sharp afirma que la vinculación en caliente genera una "solicitud HTTP [GET] adicional". Estoy de acuerdo si está comparando enlaces activos para copiar & pegando (incrustando) el script en el HTML. Pero, si está comparando los enlaces en caliente con el alojamiento del script localmente y la vinculación a través de una ruta relativa, entonces diría que los enlaces en caliente son (más o menos) más rápidos porque el navegador no tiene que resolver el absoluto URL de la ruta relativa. En ambos casos, sin embargo, se realiza una solicitud HTTP GET adicional, ¿correcto?

Answer 1

La respuesta correcta es - depende.

Hotlinking puede ser lento porque -

1. Se necesita una búsqueda de DNS adicional
2. No es posible volver a utilizar una conexión de socket TCP/IP existente

de alojamiento en el servidor puede ser lento porque -

1. Los navegadores solo permiten n peticiones simultáneas por host. Tener una solicitud más para el mismo host tiene el potencial de introducir colas, que pueden ser lentas. El número 'n' es específico del navegador, y está en cualquier lugar entre 2 y 6. See browserscope > network > connections per host name.

Si supone que ambos servidores son idénticos en todos los aspectos, diría que el alojamiento en su servidor será más rápido. Esto es cierto especialmente en los navegadores nuevos donde el número de conexiones por host es 6.

Pero, por desgracia, las cosas nunca son tan simples. Me gustaría recomendar el uso hotlinking sólo si -

1. Tiene demasiados recursos (imágenes/js) en su dominio
2. El otro servidor es un CDN, y el recurso es un popular suficiente para que haya una oportunidad decente estará presente en la memoria caché del navegador. Piensa en JQuery en los servidores de Google.

Para todos los demás casos de uso, es mejor que aloje en sus propios servidores.

Answer 2

Me imagino que las únicas cosas que afectan a tal situación son las velocidades relativas de los servidores en cuestión (por velocidad) y si espera que este código se ejecute en cualquier otro sitio (para mantenimiento).

Answer 3

Suponiendo que el recurso no está incrustado en el propio documento HTML (es decir, está vinculado) y el recurso está en el mismo servidor con el mismo nombre de host, el tiempo para recuperar el recurso mediante URI absoluto o relativo debe ser virtualmente idéntico. Se enviará una solicitud HTTP adicional de cualquier manera. Si desea dividir el "virtualmente idéntico", me inclinaría hacia la ruta relativa siendo una cantidad muy, muy, muy pequeña, más rápida, debido a la menor cantidad de HTML que se debe analizar, el análisis de la ruta (como usted mencionó) podría ser más rápido (debido a que el tokenizador de cadenas no tiene que lidiar con la parte del dominio de la dirección/la dirección es más corta). La diferencia aquí solo es realista por curiosidad ... No puedo imaginar un sitio optimizado hasta este nivel (aunque puede establecer una buena regla general) El recorrido relativo le permite cambiar libremente el dominio/ruta del sitio. sin tener que volver a escribir todos los URI contenidos dentro ..)

Una cosa a tener en cuenta sería si el recurso es no alojado en el mismo servidor, y el servidor del documento de referencia HTML ha permitido KeepAlive, otro TCP la conexión tendrá que inicializarse para conectarse al segundo servidor (así como una consulta DNS para resolver el nombre de host del otro servidor, suponiendo que el acceso no sea a través de la dirección IP), lo que generará una sobrecarga adicional en comparación con múltiples recursos referenciados en el mismo servidor (donde se emitirían las solicitudes GET dentro de la T existente Conexión CP).

Lo mismo se aplicaría a un servidor que no tiene habilitado KeepAlive; una conexión TCP se inicializará para cada recurso solicitado.

Answer 4

Esto tiene más que ver con cosas de nivel inferior como tcp en lugar de http per-se. Si obtienes dos elementos del mismo servidor web hoy en día, es probable que tu navegador los lleve a través de la misma conexión tcp. Eso es dos transacciones http sobre una conexión tcp. Esto evita la sobrecarga de hacer otra conexión tcp. Esta sobrecarga es pequeña en términos de tráfico, pero puede implicar mucha latencia.

OTOH, haciendo dos transacciones http donde cada una de ellas va a diferentes servidores quizás más rápido, o tal vez no. Es cierto que tiene la sobrecarga de dos conexiones tcp. En este caso, son serializados —, uno debe completarse antes de que pueda comenzar el segundo. Sin embargo, si estuviera tirando de muchos objetos, las conexiones 2da, 3ra, 4ta ... podrían proceder en paralelo, enmascarando el problema de latencia. En este escenario, las cosas pueden ir mucho más rápido ya que los objetos pequeños pueden no estar sujetos a la limitación de ancho de banda de su ISP.

Las aguas son realmente fangosas.

Solo fíjate en la latencia y el ancho de banda. Depende realmente de la cantidad y el tamaño de tus recursos.

Answer 5

El tiempo que el cliente necesita para resolver el URI relativo es absolutamente insignificante.

Así que no hay ninguna diferencia si se vincula a un recurso en el mismo dominio del documento que utiliza URI absolutas o relativas.

La única diferencia será cuando el recurso esté alojado en un servidor diferente. Entonces necesitarás una conexión TCP adicional a ese servidor, mientras que una solicitud HTTP adicional a un servidor al que ya tienes una conexión podría usar esa conexión.