¿Debería servirse JavaScript referenciado en la sección principal desde el mismo nombre de host que el documento principal?

Tenía la impresión de que para obtener el mejor rendimiento, Javascript debería tratarse como contenido estático y servirse desde un dominio sin cookies junto con archivos CSS, imágenes, etc.

Pero Google dice aquí: no sirva archivos JS externos cargados temprano desde el dominio sin cookies

Para JavaScript referenciado en el encabezado del documento y necesario para el inicio de la página, debe servirse desde el mismo nombre de host que el documento principal. Debido a que la mayoría de los navegadores bloquean otras descargas y renderizaciones hasta que todos los archivos JavaScript se hayan descargado, analizado y ejecutado, es mejor evitar el riesgo de una búsqueda de DNS adicional en este punto del procesamiento.

Entonces ahora estoy en conflicto. No tengo claro qué significa "necesario para el inicio de la página".

Por lo general, tengo dos referencias de JavaScript, JQuery servido desde ajax.googleapis.com y un archivo master.js que contiene principalmente controladores de eventos en la función $ (document) .ready (). ¿Es esto necesario para el inicio de la página?

Dadas las opciones disponibles, (ajax.googleapis.com, dominio estático sin cookies, nombre de host original) ¿dónde se debe servir mi JavaScript?

Entonces ahora estoy en conflicto. No tengo claro qué significa "necesario para el inicio de la página".

Esto depende mucho de cómo funciona su sitio. Básicamente, es el JavaScript que debe ejecutarse antes de que alguien pueda hacer uso de la página web.

Como ejemplo, si va a http://www.weather.com/ , puede ver que la gente buena decidió usar un poco de magia de JavaScript para proporcionar una pista para el formulario de búsqueda del clima. Es decir, las palabras Enter Zip, City or Place (e.g. Disney World)aparecen en el campo de entrada de texto. Desafortunadamente, hay un ligero retraso cuando la página se está cargando, al menos por mi parte. Entonces, si la página es lo suficientemente lenta para cargar y eres lo suficientemente rápido como para comenzar a escribir la entrada de texto antes de que se ejecute JavaScript, lo cual no es una extensión, tu entrada puede ser arruinada por el JavaScript que oculta esa sugerencia texto en el cuadro de entrada.

De acuerdo, esto podría evitarse primero verificando la entrada del usuario en el cuadro de texto o simplemente renunciando a esta técnica anacrónica. Sin embargo, entonces no serviría como un muy buen ejemplo.

Dadas las opciones disponibles, (ajax.googleapis.com, dominio estático sin cookies, nombre de host original) ¿dónde se debe servir mi JavaScript?

Esto realmente no se puede responder sin saber lo que hace su JavaScript. Además, como alude bpeterson76, depende de la situación específica de su sitio. Es decir, ¿qué tan grande es la página? ¿Cuán bien es la demanda de su anfitrión? ¿Cuántos archivos CSS, imágenes, etc. se cargan? ¿Cuántos recursos externos está cargando?

Dependiendo de su situación específica, esto puede ser una optimización prematura.

La regla "todo lo que se requiere antes de que la página comience a representarse debe ser del mismo servidor" generalmente se aplica a suservidores u otros recursos más pequeños: situaciones en las que la búsqueda de DNS puede tomar una fracción notable de un segundo (que puede acumularse rápidamente si sus objetos están esparcidos alrededor de muchos dominios). Con recursos públicos comunes como el caché de jQuery de Google y otras bibliotecas, existe una buena posibilidad de que el navegador de su visitante ya haya realizado esa búsqueda de DNS hoy (porque otros sitios hacen referencia al contenido de ese servicio) y probablemente también tenga el archivo en caché, así que no es necesario realizar la transferencia (o si se realiza una solicitud, es posible que reciba una respuesta breve "304 - no modificado"). Incluso si se necesita una descarga completa para el objeto, la red de entrega de contenido de Google será más rápida para la mayoría de los usuarios que su operación a menor escala.

Una regla relacionada: los objetos que no son necesarios para la función correcta de la página (como lo ve el usuario) deben mencionarse lo más tarde posible en la respuesta HTTP principal. Por ejemplo, cosas como las secuencias de comandos requeridas para los servicios de publicidad / estadísticas (es decir, Google Analytics y su tipo): brinde al usuario su contenido lo más rápido posible y luego cargue el material de fondo que realmente solo le interese. He bloqueado un par de servicios de anuncios / estadísticas (asignándolos a 127.0.0.1 en mi archivo de hosts) porque a menudo son demasiado lentos y los sitios que se refieren a ellos antes solo me dan una página en blanco mientras se esperan los scripts. de referirme a ellos tarde para que pueda leer el contenido que estoy allí mientras las otras cosas se acumulan en el fondo.

La utilidad de un dominio sin cookies para contenido estático es una cuestión de escala. Si todo lo que tiene es una ID de sesión de 10 bytes en las cookies y diez mil visitantes por día que solicitan ~ 20 objetos estáticos por visita, solo está ahorrando ~ 118Mbyte de ancho de banda por mes (20 * 20 * 10000 * 31/1024/1024). Si, por otro lado, su sitio mantiene uno o dos Kbytes de contenido en las cookies, la diferencia puede ser mucho más significativa, especialmente si alguno de sus usuarios accede al sitio a través de conexiones lentas (es decir, GPRS a través de la conexión a un móvil o enlace wifi lleno de gente en un área de alta interferencia) o si recibe millones de visitas por día.

Para resumir, para los scripts que deben cargarse antes de que la página pueda representar mis preferencias serían:

1. ajax.googleapis.com, o similar
2. nombre de host original de la página de llamada
3. dominio estático sin cookies

Para los recursos que no son esenciales para la representación inicial de la página, consúltelos lo más tarde posible e invierta la lista de preferencias anterior (aunque la diferencia entre el nombre de host original y el dominio sin cookies probablemente no sea significativa a menos que esté operando a gran escala) )

Google ejecuta una gran red de contenido distribuida en todo el mundo que acerca el contenido al usuario que cualquier servidor que probablemente esté ejecutando (piense en Akami, pero es propiedad de Google). Entonces, desde el punto de vista de la velocidad, es lógico pensar que Google enviará su archivo al usuario más rápido que su servidor local ... a menos que estén muy cerca de su servidor personal.

Esta pregunta ha dado vueltas y más vueltas en Stackoverflow, y la respuesta anterior parece ser siempre el consenso. Pero desde un punto de vista realista, las ganancias obtenidas al hospedarse en uno frente al otro serán bastante mínimas a largo plazo. Obtendrá beneficios mucho mejores al minimizar, optimizar y reducir las solicitudes http generales de lo que examinará dónde se encuentran físicamente las cosas. En situaciones en las que comienza a importar (hice un trabajo donde una página cargaba más de 1.5 millones de veces / día, por lo que una mejora de 5k significó 5 gigas de ahorro de ancho de banda) generalmente hay un equipo de tomadores de decisiones que tienen la tarea de analizar estas decisiones.

Personalmente, generalmente alojo en Google por la única razón de que me van a dar la copia más actualizada de lo que estoy buscando.

Una cosa importante para recordar es que los navegadores tienen límites sobre cuántos recursos se descargarán simultáneamente desde el mismo dominio, generalmente entre 2 y 6 dependiendo del navegador. El uso de un dominio diferente le permite al navegador descargar más cosas simultáneamente de su dominio.

Entonces, la mejor solución es usar un CDN popular como ajax.googleapis.com, ya que de esa manera no hay cookies. El usuario probablemente ya ha realizado la búsqueda de DNS e incluso puede haber almacenado en caché el recurso. Los CDN están optimizados para la velocidad y probablemente tengan un servidor cerca de su usuario.

Si un CDN no es una opción, entonces si tiene muchas cookies o tiene muchos recursos para descargar (imágenes, etc.), use un dominio libre de cookies (de todos modos, solo necesita buscar DNS una vez).

Si tiene pocos recursos (solo un archivo javascript personalizado) y pocas cookies (solo una pequeña identificación de sesión), aloje el mismo dominio.

Buenos recursos:

http://www.phpied.com/free-falling-waterfalls/

http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/

http://developer.yahoo.com/performance/rules.html

Aunque las respuestas anteriores han analizado la mayor parte de su pregunta, contribuiré en "necesario para el inicio de la página". Traduzco esto a: ¿es este script esencial para usar el sitio web? Por experiencia, generalmente la respuesta es no. Sin embargo, casos en los que yo:

• Validación de formulario
• Una navegación basada en JavaScript (no es ideal de todos modos)
• Si el diseño depende de JavaScript
• Si se usa JavaScript o una biblioteca (como jQuery) para modificaciones DOM que son críticas

Y las pautas de rendimiento YSlow de Yahoo como referencia.