paginas - ultima version de javascript
¿Por qué mover sus archivos Javascript a un dominio principal diferente que también posee? (10)
¿Sería debido al bloqueo realizado por el spam y los filtros de contenido? Si usan dominios extraños, entonces es más difícil de resolver y / o terminarás bloqueando algo que deseas.
Dunno, solo un pensamiento.
Me di cuenta de que en el último año más o menos, muchos sitios web importantes han hecho el mismo cambio en la forma en que se estructuran sus páginas. Cada uno ha movido sus archivos Javascript para que no se alojen en el mismo dominio que la página en sí (o un subdominio de eso), para ser alojados en un dominio de nombre diferente.
No es simplemente paralelización
Ahora bien, existe una técnica bien conocida para extender los componentes de su página a través de múltiples dominios para paralelizar la descarga. Yahoo lo recomienda al igual que muchos otros. Por ejemplo, www.example.com es donde se aloja su HTML, luego coloca imágenes en images.example.com y javascripts en scripts.example.com . Esto evita el hecho de que la mayoría de los navegadores limitan el número de conexiones simultáneas por servidor para ser buenos ciudadanos netos.
Lo anterior no es de lo que estoy hablando.
No se trata simplemente de una redirección a una red de entrega de contenido (o tal vez lo es - ver la parte inferior de la pregunta)
De lo que estoy hablando es de alojar JavaScript específicamente en un dominio completamente diferente. Déjame ser específico. Solo en el último año más o menos me di cuenta de que:
youtube.com ha movido sus archivos .JS a ytimg.com
cnn.com ha movido sus archivos .JS a cdn.turner.com
weather.com ha movido sus archivos .JS a j.imwx.com
Ahora, sé sobre redes de entrega de contenido como Akamai que se especializan en la contratación externa de esto para sitios web grandes. (El nombre "cdn" en el dominio especial de Turner nos muestra la importancia de este concepto aquí).
Pero tenga en cuenta que con estos ejemplos, cada sitio tiene su propio dominio específicamente registrado para este propósito, y no es el dominio de una red de distribución de contenido u otro proveedor de infraestructura. De hecho, si intenta cargar la página de inicio de la mayoría de estos dominios de scripts, generalmente se redireccionará al dominio principal de la empresa. Y si realiza una búsqueda inversa de las direcciones IP involucradas, a veces parecen apuntar a los servidores de una empresa CDN, a veces no.
¿Porqué me importa?
Habiendo trabajado anteriormente en dos compañías de seguridad diferentes, me han vuelto paranoico los archivos JavaScript maliciosos.
Como resultado, sigo la práctica de los sitios de la lista blanca a los que permitiré que se ejecute Javascript (y otro contenido activo como Java). Como resultado, para hacer que un sitio como cnn.com funcione correctamente, tengo que poner manualmente cnn.com en una lista. Es un dolor en la parte de atrás, pero yo prefiero la alternativa.
Cuando las personas usaban cosas como scripts.cnn.com para paralelizar, funcionaba bien con wildcarding apropiado. Y cuando la gente utilizaba subdominios fuera de los dominios de la compañía CDN, podía simplemente permitir el dominio principal de la compañía CDN con un comodín en el frente y matar a muchos pájaros de un tiro (como * .edgesuite.net y * .akamai.com).
Ahora descubrí que (a partir de 2008) esto no es suficiente. Ahora tengo que buscar en el código fuente de una página que quiero incluir en la lista blanca, y averiguar qué dominio (o dominios) "secretos" usa ese sitio para almacenar sus JavaScript. En algunos casos, he descubierto que debo permitir tres dominios diferentes para que un sitio funcione.
¿Por qué todos estos sitios importantes comenzaron a hacer esto?
EDIT: OK como "onebyone" señaló , parece estar relacionado con la entrega de contenido de CDN. Así que déjame modificar la pregunta ligeramente en base a su investigación ...
¿Por qué weather.com está utilizando j.imwx.com en lugar de twc.vo.llnwd.net ?
¿Por qué youtube.com está utilizando s.ytimg.com en lugar de static.cache.l.google.com ?
Tiene un razonamiento detrás de esto.
Creo que hay algo en la teoría CDN:
Por ejemplo:
$ host j.imwx.com
j.imwx.com CNAME twc.vo.llnwd.net
twc.vo.llnwd.net A 87.248.211.218
twc.vo.llnwd.net A 87.248.211.219
$ whois llnwd.net
<snip ...>
Registrant:
Limelight Networks Inc.
2220 W. 14th Street
Tempe, Arizona 85281-6945
United States
Limelight es un CDN.
Mientras tanto:
$ host s.ytimg.com
s.ytimg.com CNAME static.cache.l.google.com
static.cache.l.google.com A 74.125.100.97
Supongo que este es un CDN para contenido estático ejecutado internamente por Google.
$ host cdn.turner.com
cdn.turner.com A record currently not present
Ah, bueno, no puedo ganarlos a todos.
Por cierto, si usas Firefox con el complemento NoScript, automatizará el proceso de búsqueda en el origen y GUI-fy en el proceso de inclusión en la lista blanca. Básicamente, haga clic en el ícono NoScript en la barra de estado, se le da una lista de dominios con opciones para incluirlos en la lista blanca temporal o permanentemente, incluyendo "todo en esta página".
Creo que respondiste tu propia pregunta.
Creo que su problema está relacionado con la seguridad, en lugar de POR QUÉ.
Quizás una nueva etiqueta META esté en orden para describir CDN válidos para la página en cuestión, entonces todo lo que necesitamos es un complemento de navegador para leerlos y comportarnos en consecuencia.
He trabajado con una empresa que hace esto. Están en un centro de datos con bastante buenas conexiones, por lo que el razonamiento CDN no es tan grande para ellos (tal vez sería útil, pero no lo hacen por ese motivo). Su razón es que ejecutan varios servidores web en paralelo que manejan colectivamente sus páginas dinámicas (scripts PHP) y sirven imágenes y algunos javascript de un dominio separado en el que usan un servidor web rápido y liviano como lighttpd o thttpd para servir imágenes y Javascript estático.
PHP requiere PHP. El Javascript estático y las imágenes no. Se puede eliminar un lote de un servidor web completo cuando todo lo que necesita hacer es el mínimo absoluto.
Claro, probablemente podrían usar un proxy que redirija las solicitudes a un subdirectorio específico a un servidor diferente, pero es más fácil manejar todo el contenido estático con un servidor diferente.
Limitar el tráfico de cookies?
Después de que una cookie se establece en un dominio específico, cada solicitud a ese dominio tendrá la cookie enviada de vuelta al servidor. ¡Cada solicitud!
Eso puede sumarse rápidamente.
Muchas razones:
CDN: un nombre de DNS diferente facilita el desplazamiento de los activos estáticos a una red de distribución de contenido
Paralelismo: las imágenes, las hojas de estilo y el javascript estático utilizan otras dos conexiones que no bloquearán otras solicitudes, como las devoluciones de llamada ajax o las imágenes dinámicas
Tráfico de cookies, exactamente correcto, especialmente con sitios que tienen la costumbre de almacenar mucho más que una simple identificación de sesión en las cookies
Cargue la configuración: incluso sin una CDN, hay buenas razones para alojar los activos estáticos en menos servidores web optimizados para responder de manera extremadamente rápida a una gran cantidad de solicitudes de URL de archivos, mientras que el resto del sitio está alojado en un mayor número de servidores que responden a más solicitudes dinámicas intensivas de procesador
actualización: dos razones por las que no utiliza el nombre DNS de la CDN. El nombre dns del cliente actúa como una clave para la "colmena" adecuada de activos que el CDN está almacenando en caché. Además, dado que su CDN es un servicio básico, puede cambiar el proveedor alterando el registro DNS, para evitar cualquier cambio de página, reconfiguración o redistribución en su sitio.
No es solo javascript que puede moverse a diferentes dominios, pero la mayor cantidad posible de activos generará mejoras de rendimiento.
La mayoría de los navegadores tienen un límite en la cantidad de conexiones simultáneas que puede realizar a un solo dominio (creo que es alrededor de 4), por lo que cuando tiene muchas imágenes, js, css, etc., a menudo se detienen al descargar cada archivo.
Puede usar algo como YSlow y FireBug para ver cuándo se descarga cada archivo del servidor.
Al tener activos en dominios separados, reduces la carga en tu primaria y puedes tener conexiones más simultáneas y descargar más archivos en cualquier momento.
Recientemente lanzamos un sitio web realtate que tiene muchas imágenes (de las casas, duh: P) que utiliza este principio para las imágenes, por lo que es mucho más rápido enumerar los datos.
También lo hemos usado en muchos otros sitios web que tienen un alto volumen de activos.
Si fuera un gran nombre, una compañía multimarca, creo que este enfoque tendría sentido porque desea que el código de JavaScript esté disponible como biblioteca. Me gustaría hacer que tantas páginas sean tan consistentes como sea posible en el manejo de cosas como direcciones, nombres de estado, códigos postales. AJAX probablemente hace que esta preocupación sea prominente.
En el modelo comercial de Internet actual, los dominios son marcas, no nombres de red. Si obtiene marcas compradas o derivadas, terminará con muchos cambios de dominio. Este es un problema incluso para los sitios más destacados.
Todavía hay enlaces que apuntan a documentos útiles en * .netscape.com y * .mcom.com que ya no existen.
Wikipedia para Netscape dice:
"El 12 de octubre de 2004, el popular sitio web para desarrolladores Netscape DevEdge fue cerrado por AOL. DevEdge era un recurso importante para las tecnologías relacionadas con Internet, manteniendo documentación definitiva sobre el navegador Netscape, documentación sobre tecnologías asociadas como HTML y JavaScript, y artículos populares. escrito por líderes de la industria y la tecnología como Danny Goodman. Algunos contenidos de DevEdge han sido republicados en el sitio web de Mozilla ".
Entonces, eso sería, en menos de un período de 10 años:
- Mosaic Communications Corporation
- Netscape Communications Corporation
- AOL
- AOL Time Warner
- Time Warner
Si coloca el código en un dominio que NO es una marca, conserva mucha flexibilidad y no es necesario refaccionar todos los puntos de entrada, control de acceso y referencias de código cuando se renombra el sitio web.
Su pregunta de seguimiento es esencialmente: suponiendo que un sitio web popular utiliza una CDN, ¿por qué usarían su propio TLD como imwx.com en lugar de un subdominio (static.weather.com) o el dominio de la CDN?
Bueno, la razón para usar un dominio que controlan en comparación con el dominio de CDN es que retienen el control; incluso podrían cambiar CDN totalmente y solo tienen que cambiar un registro DNS, en lugar de tener que actualizar enlaces en miles de páginas / aplicaciones.
Entonces, ¿por qué usar nombres de dominio sin sentido? Bueno, una gran cosa con los archivos auxiliares como .js y .css es que quieres que sean almacenados en caché corriente abajo por proxies y navegadores de personas tanto como sea posible. Si una persona accede a gmail.com y todos los archivos .js se cargan de la memoria caché de su navegador, el sitio parece mucho más ágil para ellos, y también ahorra ancho de banda en el extremo del servidor (todo el mundo gana). El problema es que una vez que envía encabezados HTTP para el almacenamiento en caché realmente agresivo (es decir, me guardan en caché durante una semana o un año o para siempre), estos archivos ya no se cargan confiablemente desde el servidor y no puede realizar cambios / correcciones a porque las cosas se romperán en los navegadores de las personas.
Entonces, lo que las empresas tienen que hacer es organizar estos cambios y realmente cambiar las URL de todos estos archivos para obligar a los navegadores a recargarlos. El ciclismo a través de dominios como "a.imwx.com", "b.imwx.com", etc. es cómo se hace esto.
Al usar un nombre de dominio sin sentido, los desarrolladores de Javascript y sus contrapartes de enlace sysadmin / CDN de Javascript pueden tener su propio nombre de dominio / DNS al que están impulsando estos cambios, que son responsables / autónomos.
Luego, si algún tipo de bloqueo de cookies o bloqueo de scripts comienza a suceder en el TLD, simplemente cambian de un TLD sin sentido a kyxmlek.com o lo que sea. No tienen que preocuparse por hacer algo malo accidentalmente que tenga efectos secundarios de contramedida en todos los * .google.com.
Implementé esta solución hace dos o tres años en un empleador anterior, cuando el sitio web comenzó a sobrecargarse debido a la implementación de un servidor web heredado. Al mover las imágenes CSS y de diseño a un servidor Apache, redujimos la carga en el servidor principal y aumentamos la velocidad sin fin.
Sin embargo, siempre he tenido la impresión de que solo se puede acceder a las funciones de Javascript desde el mismo dominio que la página en sí. Los sitios web más nuevos no parecen tener esta limitación: como usted menciona, muchos tienen archivos Javascript en subdominios separados o incluso dominios completamente separados por completo.
¿Alguien puede darme una pista sobre por qué ahora esto es posible, cuando no era hace un par de años?