¿Localizas tu javascript en la página o tienes un master "application.js" o similar?¿Dónde pones tu javascript?
Si es el último, ¿cuál es la mejor práctica para asegurarse de que su .js no se está ejecutando en las páginas incorrectas?
EDITAR: por javascript Me refiero a javascript personalizado que escribe como desarrollador, no bibliotecas js. No puedo imaginar que alguien copie/pegue la fuente de jQuery en su página, pero nunca se sabe.
Poner todos los js en un solo archivo puede mejorar el rendimiento (sólo una petición contra varios). Y si está utilizando una red de distribución de contenido como Akamai, mejora su índice de aciertos de caché. Además, siempre inserte js en línea en la parte inferior de la página (justo encima de la etiqueta del cuerpo) porque se ejecuta de forma síncrona y puede retrasar el procesamiento de la página.
Y sí, si uno de los archivos js que está utilizando también está alojado en google, asegúrese de usar ese.
Personalmente, intento incluir varios archivos Javascript, ordenados por módulo (like YUI does). Pero de vez en cuando, cuando escribo esencialmente un texto único, lo pongo en la página.
La mejor práctica es, probablemente, ponerlo on Google's servers.
(depende de lo que entendemos por "su" javascript aunque supongo :)
me refiero al código que se escribe, no al código en las bibliotecas. –
¿Es posible que la conexión del usuario al servidor local de Google sea significativamente más rápida que la de su servidor web? Es posible que esto pueda ahorrar ancho de banda y acelerar tu página. (no vote porque no responde la pregunta) –
Aquí están mis "pautas". Tenga en cuenta que ninguno de estos son formales, simplemente parecen lo correcto.
Todo el código JS compartida vive en el directorio SITE/javascripts, pero es cargado en
Para todo el sitio cosas (como jQuery, o mi sitio application.js ancho) 'niveles', la amplia disposición del sitio (esto ser una página maestra en ASP.net) incluye el archivo. Las etiquetas script van en la parte superior de la página.
También hay material para toda la región (p. Ej .: código js que solo se necesita en la sección de administración del sitio). Estas regiones tienen un diseño común (que puede incluir las etiquetas de secuencia de comandos) o generarán un parcial común, y ese parcial puede incluir las etiquetas de secuencia de comandos)
Para elementos menos compartidos (di mi biblioteca que solo se necesita en una algunos lugares) luego puse una etiqueta script en esas páginas HTML individualmente. Las etiquetas de script van en la parte superior de la página.
Para cosas que solo son relevantes para una sola página, solo escribo javascript en línea. Intento mantenerlo lo más cerca posible de su "objetivo". Por ejemplo, si tengo algunos onclick js para un botón, la etiqueta script irá debajo del botón.
Para JS en línea que no tiene un objetivo (por ejemplo: onload eventos) va en la parte inferior de la página.
Entonces, ¿cómo entra algo en una biblioteca localizada o en una biblioteca de todo el sitio ?.
Una queja común acerca de un sistema como este, es que terminas con 10 o 20 pequeños archivos JS, donde 2 o 3 archivos JS grandes funcionarán mejor desde el punto de vista de redes. Sin embargo, ambos raíles y ASP.NET tienen características que manejan la combinación y almacenamiento en caché de múltiples archivos JS en uno o más archivos 'super' js para situaciones de producción.
Recomendaría utilizar funciones como esta en lugar de comprometer la calidad/legibilidad del código fuente real.
De acuerdo. Hay otras maneras de mejorar el rendimiento además de arrojarlo todo en un solo archivo honkin '; especialmente cuando varias páginas usan solo un puñado de funciones (¿es realmente más rápido descargar un archivo de 1MB en vez de 3 archivos de 2KB? ¿Qué tal después de GZIPpilar los archivos más pequeños, o minificarlos, etc.). –
Intento evitar poner funciones de javascript en la página representada. En general, tengo una application.js (o root.js) que tiene una funcionalidad genérica como la manipulación del menú. Si una página dada tiene una función javascript específica, crearé un archivo .js para manejar ese código y simular la estructura dir sobre cómo llegar a ese archivo (también usando el mismo nombre que el archivo procesado).
En otras palabras, si la página representada está en public/dir1/dir2/mypage.html, el archivo js estaría en public/js/dir1/dir2/mypage.js. Descubrí que este estilo funciona bien para mí, especialmente cuando hago plantillas en un sitio. Construyo el motor de plantillas para "cargar automáticamente" mis recursos (css y js) tomando la ruta de solicitud y comprobando los equivalentes css y js en los directorios css y js en la raíz.
Yahoo!'s Exceptional Performance Team tiene algunas sugerencias de gran rendimiento para JavaScript. Steve Souders solía estar en ese equipo (ahora está en Google) y ha escrito algunos interesting tools que pueden ayudarte a decidir dónde colocar JavaScript.
Esto es algo con lo que he estado luchando también. Terminé usando mi script back-end de PHP para construir de forma inteligente una lista de archivos JS necesarios en función del contenido solicitado por el usuario.
Al organizar mis archivos JS en un repositorio que contiene varios archivos organizados por propósito (ya sean de uso general, enfocados para una sola página, una sola sección, etc.) puedo usar la cadena de eventos que crea la página en la parte posterior - para seleccionar de forma selectiva qué archivos JS se incluyen en función de las necesidades (ver ejemplo a continuación).
Esto es después de implementar mi aplicación web sin tener en cuenta este aspecto del código. Ahora, también debo agregar que el javascript que uso mejora pero no forma la base de mi sitio. Si está utilizando algo como SproutCore o Ext, imagino que la solución sería algo diferente.
He aquí un ejemplo de un sitio web PHP: Si su sitio está dividido en secciones y una de esas secciones es el calendario. El usuario navega a "index.phhp? Module = calendar & action = view". Si el código PHP está basado en clases, el algoritmo de enrutamiento crea la clase CalendarModule que está basada en 'Module' y tiene un método virtual 'getJavascript'. Esto devolverá las clases de JavaScript que se requieren para realizar la acción 'ver' en el módulo 'calendario'.También puede tener en cuenta cualquier otro requisito especial y devolver archivos js para esos también. El código de representación puede verificar que no haya duplicados de archivos js cuando la lista de inclusión de JavaScript se crea para la página final. Por lo que el método devuelve una matriz getJavascript como esto
return array('prototype.js','mycalendar.js');
Tenga en cuenta que esto, o alguna forma de esta, no es una idea nueva. Pero me llevó algo de tiempo pensar que era lo suficientemente importante como para tomarse la molestia.
Si solo son unos pocos cientos de bytes o menos, y no necesita ser utilizado en ningún otro lugar, probablemente lo alinearé. La sobrecarga de red para otra solicitud HTTP probablemente superará cualquier ganancia de rendimiento que obtenga al sacarla de la página.
Si necesita ser utilizado en algunos lugares, pondría la función (es) en un archivo externo común, y lo llamo desde un script en línea según sea necesario.
Si se dirige a un iphone, intente guardar en caché todo lo que desee en menos de 25k.
No hay reglas duras y rápidas Realmente, cada enfoque tiene sus pros y sus contras, le recomiendo consultar los artículos que se pueden encontrar en la sección de desarrolladores de yahoo, para que pueda tomar decisiones informadas caso por caso.
¡Excelente sugerencia! Nuestra aplicación ha hecho que sea una buena práctica poner tanto javascript en los archivos js incluidos como sea posible, ya que tenemos un alto porcentaje de usuarios que se espera que marquen a través de los módems de 56K. –
Gracias! Creo que para la mayoría de los desarrolladores arrojar todo en un archivo parece una práctica horrible. Pero a veces el rendimiento supera la limpieza del código. –