insertar - llamar javascript desde html

¿Por qué JavaScript en línea es malo?

Question

Siempre se recomienda evitar los códigos Javascript en línea poniendo todos los códigos en un archivo JS , que se incluye en todas las páginas. Me pregunto si esto no causa problemas de rendimiento en páginas pesadas.

Por ejemplo, imagina que tenemos decenas de funciones como esta

function function1(element){
var el=document.getElementsByClassName(element);
var size=el.length;
if(size==0) return;
for(i=0;i<size;i++){
// the process
}
}

en cada página, necesitamos ejecutar las funciones para saber si hay elementos correspondientes en el HTML o no.

window.onload = function(){
function1(''a'');
....
function26(''z'');
};

pero si mantiene todas las funciones en un archivo JS externo y llama a las funciones a través de JavaScript línea, solo podemos llamar a las funciones que se requieren en la presente página:

<script type="text/javascript">
window.onload = function(){
function6(''f'');
};
</script>

¿No es beneficioso desde el punto de vista del rendimiento llamar funciones a través de Javascript línea (que, por supuesto, no es la mejor práctica) para evitar la invocación de muchas funciones, que no son necesarias en una página?

Por supuesto, esto no se limita solo a las funciones, ya que tenemos muchos addEventListener para todo el sitio web, que se activan en todas y cada una de las páginas, donde no son necesarias.

Answer 1

Debería leer acerca de javascript discreto, http://en.wikipedia.org/wiki/Unobtrusive_JavaScript .

Existen otras soluciones para no cargar todos los archivos javascript en su directorio de activos para cada página web, uno llamado requirejs que debe verificar, http://requirejs.org/ .

Además, como regla general, no debería agregar todos los detectores de eventos cuando carga la página, ¿qué pasa con los objetos dom que no existen? Lanzará errores de JavaScript y romperá su código más de lo habitual.

Answer 2

Es posible que ejecutar JavaScript innecesario en una página ocasione que la página se cargue lentamente. Depende del JavaScript que se ejecuta.

Puede probar su código de ejemplo cronometrando el tiempo y ver cuánto tarda JavaScript en ejecutar getElementsByClassName repetidamente.

(Apuesto a que no lleva mucho tiempo, incluso si tienes 26 funciones buscando elementos con diferentes nombres de clase, pero con el rendimiento, siempre mide primero).

Si el tiempo de ejecución es un problema, puede escribir su JavaScript para que esté principalmente en un archivo, pero exponga las funciones que ejecuta desde JavaScript en línea en las páginas que necesita, en lugar de ejecutarlo mediante eventos de onload en su archivo JavaScript.

Sin embargo, vale la pena recordar todo lo que tiene que suceder cuando se carga una página:

1. El navegador recupera la página de su caché o envía una solicitud HTTP para ver si la página ha cambiado desde que fue almacenada en caché y / o envía una solicitud HTTP para la página.
2. El navegador analiza y renderiza la página, pausando para buscar y ejecutar cualquier JavaScript externo, y obteniendo hojas de estilo e imágenes simultáneamente con el análisis y la representación.
3. El navegador ejecuta cualquier JavaScript configurado para ejecutarse en el documento listo.
4. El navegador ejecuta cualquier JavaScript configurado para ejecutarse en la carga de la página.

Aunque ciertamente puede escribir JavaScript que se ejecuta lentamente, es probable que sea mejor tener su JavaScript en un archivo externo y, por lo tanto, en el caché del navegador del usuario, en lugar de tener que aumentar el tamaño de página al estar en línea. La red, en general, tiende a ser mucho más lenta que el análisis / ejecución de JavaScript.

Pero, y lo digo de nuevo porque es el punto más importante, todo será diferente dependiendo de tu código. Si desea mantener su rendimiento bueno, su primer y último acto debe ser para medirlo.

Answer 3

Hacer js en línea para todas las páginas hace que la aplicación sea pesada, por lo que deberíamos usar js externos, que incluye requerir páginas que nos ayuden a utilizar el código js para cada funcionalidad.

Answer 4

hay varios casos que deben tenerse en cuenta al colocar el código js.

Para en línea:

1. no es necesario navegar a un archivo externo si necesita cambiar algo rápidamente, por lo que es mejor en la localidad

2. si está utilizando AJAX en algunos elementos de su página, puede perder todo el elemento dom onclick, etc. para esa sección, que obviamente depende de cómo los vinculó. por ejemplo, puede usar live o delegate en caso de que use jQuery para evitar dicho problema ... pero me parece que si js es lo suficientemente pequeño, es preferible ponerlo en línea.

Ahora hay otra teoría para ex

La externalización de javascript es una de las reglas de rendimiento de yahoo:

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

Answer 5

• Evitar js en línea no se basa en el rendimiento ... sino más bien en la capacidad de mantenimiento y en separar la capa de presentación (html) de la capa de controlador (js).

• Tener js en línea en diferentes páginas hará que sea difícil de mantener para usted y para otros a medida que aumente la escala del proyecto.

• Además, al usar archivos js separados, puede alentar la reutilización y el diseño de código modular.

• mantiene limpio tu html y sabes dónde buscar cuando se produce un error js en lugar de varias plantillas.

Answer 6

No se recomienda utilizar recursos estáticos en línea (en su caso, el javascript en línea) ya que no puede almacenarlos en caché .

El almacenamiento en caché de un recurso estático reduce el tamaño de las cargas de página, lo que aumenta la velocidad de carga de la página, para los visitantes que regresan. Sin embargo, tiene el costo de una solicitud HTTP adicional que debe evitarse .

Cada vez que el recurso estático es tan pequeño que el tamaño adicional es insignificante en comparación con una solicitud HTTP , entonces en realidad se recomienda mantener ese recurso en línea.

Por lo general, es una buena idea mantener las bibliotecas de JavaScript en documentos externos (caché), al mismo tiempo que se mantienen pequeñas cantidades de secuencias de comandos en línea.

Por lo tanto, en respuesta a su título , el javascript en línea no es malo per se. Es un equilibrio si vale la pena una solicitud HTTP para almacenar en caché el recurso.

Answer 7

Los estilos / guiones en línea se confunden con el contenido html y pueden ser difíciles de diferenciar. Una de las claves para tener un código que se pueda mantener en el desarrollo web es escribir código que sea fácil de leer para alguien que no lo haya escrito. Mezclar etiquetas de script en tu html puede hacer que sea muy difícil encontrar una función que afecte al resto de tu código. Al colocar Javascript en archivos .js y estilos en archivos CSS, el código es más legible.