validar validacion pagina online funcion formularios formulario enviar ejemplos ejecutar despues con cargar carga asincrona antes javascript html css

validacion - validar formulario javascript antes de enviar



¿Carga y secuencia de ejecución de una página web? (7)

1) HTML se descarga.

2) HTML se analiza progresivamente. Cuando se llega a una solicitud de un activo, el navegador intentará descargar el activo. Una configuración predeterminada para la mayoría de los servidores HTTP y la mayoría de los navegadores es procesar solo dos solicitudes en paralelo. IE se puede reconfigurar para descargar un número ilimitado de activos en paralelo. Steve Souders ha podido descargar más de 100 solicitudes en paralelo en IE. La excepción es que las solicitudes de script bloquean las solicitudes de activos paralelos en IE. Por esta razón, se recomienda encarecidamente colocar todo el JavaScript en archivos de JavaScript externos y colocar la solicitud justo antes de la etiqueta de cuerpo de cierre en el HTML.

3) Una vez que se analiza el HTML, el DOM se representa. CSS se representa en paralelo a la representación del DOM en casi todos los agentes de usuario. Como resultado, se recomienda encarecidamente colocar todo el código CSS en archivos CSS externos que se soliciten lo más alto posible en la sección <head> </head> del documento. De lo contrario, la página se representa hasta que se produzca la posición de la solicitud de CSS en el DOM y luego la representación comienza de nuevo desde la parte superior.

4) Solo después de que el DOM se haya procesado completamente y las solicitudes de todos los activos en la página se hayan resuelto o se agote el tiempo de espera, JavaScript se ejecuta desde el evento onload. IE7, y no estoy seguro acerca de IE8, no agota el tiempo de espera de los activos rápidamente si no se recibe una respuesta HTTP de la solicitud del activo. Esto significa que un recurso solicitado por JavaScript en línea a la página, que es JavaScript escrito en etiquetas HTML que no está contenido en una función, puede impedir la ejecución del evento onload durante horas. Este problema se puede desencadenar si tal código en línea existe en la página y no se ejecuta debido a una colisión en el espacio de nombres que provoca una caída del código.

De los pasos anteriores, el que hace más uso de la CPU es el análisis del DOM / CSS. Si desea que su página se procese más rápido, escriba CSS eficiente eliminando instrucciones redundantes y consolidando las instrucciones de CSS en el menor número posible de referencias de elementos. Reducir el número de nodos en su árbol DOM también producirá una representación más rápida.

Tenga en cuenta que cada activo que solicite de su HTML o incluso de sus activos de CSS / JavaScript se solicita con un encabezado HTTP separado. Esto consume ancho de banda y requiere procesamiento por solicitud. Si desea que su página se cargue lo más rápido posible, reduzca el número de solicitudes HTTP y reduzca el tamaño de su HTML. No está haciendo su experiencia de usuario ningún favor al promediar el peso de la página a 180k solo con HTML. Muchos desarrolladores se suscriben a la falacia de que un usuario se decida por la calidad del contenido de la página en 6 nanosegundos y luego borra la consulta de DNS de su servidor y quema su computadora si no está satisfecho, así que en su lugar proporcionan la página más hermosa posible 250k de HTML. Mantenga su HTML corto y dulce para que un usuario pueda cargar sus páginas más rápido. Nada mejora la experiencia del usuario como una página web rápida y receptiva.

He realizado algunos proyectos basados ​​en web, pero no pienso demasiado en la secuencia de carga y ejecución de una página web normal. Pero ahora necesito saber detalles. Es difícil encontrar respuestas de Google o SO, así que creé esta pregunta.

Una página de muestra es así:

<html> <head> <script src="jquery.js" type="text/javascript"></script> <script src="abc.js" type="text/javascript"> </script> <link rel="stylesheets" type="text/css" href="abc.css"></link> <style>h2{font-wight:bold;}</style> <script> $(document).ready(function(){ $("#img").attr("src", "kkk.png"); }); </script> </head> <body> <img id="img" src="abc.jpg" style="width:400px;height:300px;"/> <script src="kkk.js" type="text/javascript"></script> </body> </html>

Asi que aqui están mis preguntas:

  1. ¿Cómo se carga esta página?
  2. ¿Cuál es la secuencia de la carga?
  3. ¿Cuándo se ejecuta el código JS? (inline y externo)
  4. ¿Cuándo se ejecuta el CSS?
  5. ¿Cuándo se ejecuta $ (documento) .ready?
  6. ¿Se descargará abc.jpg? ¿O simplemente descarga kkk.png?

Tengo el siguiente entendimiento:

  1. El navegador carga el html (DOM) al principio.
  2. El navegador comienza a cargar los recursos externos de arriba a abajo, línea por línea.
  3. Si se cumple un <script> , la carga se bloqueará y esperará hasta que el archivo JS se cargue y ejecute y luego continúe.
  4. Otros recursos (CSS / imágenes) se cargan en paralelo y se ejecutan si es necesario (como CSS).

O es así:

El navegador analiza el html (DOM) y obtiene los recursos externos en una matriz o estructura similar a una pila. Una vez que se carga el html, el navegador comienza a cargar los recursos externos en la estructura en paralelo y se ejecuta, hasta que se cargan todos los recursos. Luego, se cambiará el DOM correspondiente a los comportamientos del usuario según el JS.

¿Alguien puede dar una explicación detallada sobre lo que sucede cuando obtiene la respuesta de una página html? ¿Esto varía en diferentes navegadores? ¿Alguna referencia sobre esta pregunta?

Gracias.

EDITAR:

Hice un experimento en Firefox con Firebug. Y se muestra como la siguiente imagen:

AFAIK, el navegador (al menos Firefox) solicita todos los recursos tan pronto como los analiza. Si encuentra una etiqueta img, solicitará esa imagen tan pronto como la etiqueta img haya sido analizada. Y eso puede ser incluso antes de que haya recibido la totalidad del documento HTML ... es decir, aún podría estar descargando el documento HTML cuando eso suceda.

Para Firefox, hay colas de navegador que se aplican, dependiendo de cómo estén configuradas en about: config. Por ejemplo, no intentará descargar más de 8 archivos a la vez desde el mismo servidor ... las solicitudes adicionales se pondrán en cola. Creo que hay límites por dominio, límites por proxy y otras cosas que están documentadas en el sitio web de Mozilla y se pueden configurar en aproximadamente: config. Leí en alguna parte que IE no tiene tales límites.

El evento jQuery ready se activa tan pronto como se descarga el documento HTML principal y se analiza DOM. Luego, el evento de carga se activa una vez que todos los recursos vinculados (CSS, imágenes, etc.) también se han descargado y analizado. Se aclara en la documentación de jQuery.

Si desea controlar el orden en que se carga todo eso, creo que la forma más confiable de hacerlo es a través de JavaScript.

Abre tu página en Firefox y obtén el complemento HTTPFox. Te dirá todo lo que necesites.

Encontré esto en archivist.incuito:

http://archivist.incutio.com/viewlist/css-discuss/76444

Cuando solicita una página por primera vez, su navegador envía una solicitud GET al servidor, que devuelve el HTML al navegador. Luego, el navegador comienza a analizar la página (posiblemente antes de que se haya devuelto todo).

Cuando encuentra una referencia a una entidad externa, como un archivo CSS, un archivo de imagen, un archivo de script, un archivo Flash o cualquier otra cosa externa a la página (ya sea en el mismo servidor / dominio o no), se prepara para hacer una solicitud GET adicional para ese recurso.

Sin embargo, el estándar HTTP especifica que el navegador no debe realizar más de dos solicitudes simultáneas al mismo dominio. Por lo tanto, pone cada solicitud a un dominio particular en una cola y, a medida que se devuelve cada entidad, comienza la siguiente en la cola para ese dominio.

El tiempo que demora la devolución de una entidad depende de su tamaño, la carga que el servidor está experimentando actualmente y la actividad de cada máquina entre la máquina que ejecuta el navegador y el servidor. La lista de estas máquinas puede, en principio, ser diferente para cada solicitud, en la medida en que una imagen pueda viajar desde los EE. UU. Hacia el Atlántico por el Reino Unido, mientras que otra desde el mismo servidor sale a través del Pacífico, Asia y Europa. lo que lleva más tiempo. Por lo tanto, es posible que obtenga una secuencia como la siguiente, donde una página tiene (en este orden) referencias a tres archivos de script y cinco archivos de imagen, todos de diferentes tamaños:

  1. GET script1 y script2; solicitud de cola para script3 e images1-5.
  2. llega script2 (es más pequeño que script1): GET script3, cola imágenes1-5.
  3. llega script1; GET image1, imágenes en cola2-5.
  4. llega image1, GET image2, imágenes en cola3-5.
  5. script3 no llega debido a un problema de red: GET script3 nuevamente (reintento automático).
  6. La imagen2 llega, el script3 todavía no está aquí; GET image3, imágenes en cola4-5.
  7. la imagen 3 llega; GET image4, queue image5, script3 aún en camino.
  8. image4 llega, GET image5;
  9. La imagen5 llega.
  10. llega script3.

En resumen: cualquier orden anterior, según lo que esté haciendo el servidor, lo que está haciendo el resto de Internet, y si algo tiene errores o no y debe ser recuperado. Esto puede parecer una forma extraña de hacer las cosas, pero sería literalmente imposible que Internet (no solo la WWW) funcione con algún grado de confiabilidad si no se hiciera de esta manera.

Además, es posible que la cola interna del navegador no recupere las entidades en el orden en que aparecen en la página; no es obligatorio en ningún estándar.

(Ah, y no olvide el almacenamiento en caché, tanto en el navegador como en los servidores proxy de almacenamiento en caché utilizados por los ISP para facilitar la carga en la red).

La respuesta elegida parece que no se aplica a los navegadores modernos, al menos en Firefox 52. Lo que observé es que las solicitudes de carga de recursos como css, javascript se emiten antes de que el analizador HTML llegue al elemento, por ejemplo

<html> <head> <!-- prints the date before parsing and blocks HTMP parsering --> <script> console.log("start: " + (new Date()).toISOString()); for(var i=0; i<1000000000; i++) {}; </script> <script src="jquery.js" type="text/javascript"></script> <script src="abc.js" type="text/javascript"></script> <link rel="stylesheets" type="text/css" href="abc.css"></link> <style>h2{font-wight:bold;}</style> <script> $(document).ready(function(){ $("#img").attr("src", "kkk.png"); }); </script> </head> <body> <img id="img" src="abc.jpg" style="width:400px;height:300px;"/> <script src="kkk.js" type="text/javascript"></script> </body> </html>

Lo que encontré fue que la hora de inicio de las solicitudes para cargar recursos css y javascript no estaban siendo bloqueadas. Parece que Firefox tiene un escaneo HTML e identifica recursos clave (no se incluye el recurso img) antes de comenzar a analizar el HTML.

Según su muestra,

<html> <head> <script src="jquery.js" type="text/javascript"></script> <script src="abc.js" type="text/javascript"> </script> <link rel="stylesheets" type="text/css" href="abc.css"></link> <style>h2{font-wight:bold;}</style> <script> $(document).ready(function(){ $("#img").attr("src", "kkk.png"); }); </script> </head> <body> <img id="img" src="abc.jpg" style="width:400px;height:300px;"/> <script src="kkk.js" type="text/javascript"></script> </body> </html>

aproximadamente el flujo de ejecución es de la siguiente manera:

  1. El documento HTML se descarga
  2. Se inicia el análisis del documento HTML.
  3. El análisis HTML llega a <script src="jquery.js" ...
  4. jquery.js se descarga y analiza
  5. El análisis de HTML llega a <script src="abc.js" ...
  6. abc.js se descarga, analiza y ejecuta
  7. El análisis de HTML llega a <link href="abc.css" ...
  8. abc.css se descarga y analiza
  9. El análisis de HTML llega a <style>...</style>
  10. Las reglas internas de CSS están analizadas y definidas.
  11. El análisis de HTML llega a <script>...</script>
  12. Javascript interno es analizado y ejecutado
  13. El análisis HTML llega a <img src="abc.jpg" ...
  14. abc.jpg se descarga y se muestra
  15. El análisis HTML llega a <script src="kkk.js" ...
  16. kkk.js se descarga, analiza y ejecuta
  17. El análisis de los documentos HTML termina

Tenga en cuenta que la descarga puede ser asíncrona y no bloqueante debido a los comportamientos del navegador. Por ejemplo, en Firefox existe esta configuración que limita el número de solicitudes simultáneas por dominio.

También dependiendo de si el componente ya ha sido almacenado en caché o no, el componente puede no ser solicitado nuevamente en una solicitud de futuro cercano. Si el componente se ha almacenado en la memoria caché, el componente se cargará desde la memoria caché en lugar de la URL real.

Cuando finaliza el análisis y el documento está listo y cargado, se onload los eventos onload . Por lo tanto, cuando se $("#img").attr("src","kkk.png"); , el $("#img").attr("src","kkk.png"); se ejecuta Asi que:

  1. El documento está listo, onload se dispara.
  2. La ejecución de Javascript golpea $("#img").attr("src", "kkk.png");
  3. kkk.png se descarga y carga en #img

El evento $(document).ready() es en realidad el evento que se activa cuando todos los componentes de la página están cargados y listos. Lea más sobre esto: http://docs.jquery.com/Tutorials:Introducing_$(document).ready()

Editar - Esta parte elabora más sobre el paralelo o no parte:

De forma predeterminada, y según mi entendimiento actual, el navegador normalmente ejecuta cada página en 3 formas: analizador HTML, Javascript / DOM y CSS.

El analizador HTML es responsable de analizar e interpretar el lenguaje de marcado y, por lo tanto, debe poder hacer llamadas a los otros 2 componentes.

Por ejemplo, cuando el analizador se encuentra con esta línea:

<a href="#" onclick="alert(''test'');return false;" style="font-weight:bold">a hypertext link</a>

El analizador hará 3 llamadas, dos a Javascript y una a CSS. En primer lugar, el analizador creará este elemento y lo registrará en el espacio de nombres DOM, junto con todos los atributos relacionados con este elemento. En segundo lugar, el analizador llamará para vincular el evento onclick a este elemento en particular. Por último, hará otra llamada al hilo CSS para aplicar el estilo CSS a este elemento en particular.

La ejecución es de arriba hacia abajo y de un solo hilo. Javascript puede parecer multiproceso, pero el hecho es que Javascript es de un solo hilo. Esta es la razón por la que al cargar un archivo javascript externo, se suspende el análisis de la página HTML principal.

Sin embargo, los archivos CSS se pueden descargar simultáneamente porque las reglas CSS siempre se aplican, lo que significa que los elementos siempre se repintan con las reglas CSS más recientes definidas, lo que hace que se desbloqueen.

Un elemento solo estará disponible en el DOM después de que se haya analizado. Por lo tanto, cuando se trabaja con un elemento específico, la secuencia de comandos siempre se coloca después del evento onload de la ventana o dentro del mismo.

Un script como este causará un error (en jQuery):

<script type="text/javascript">/* <![CDATA[ */ alert($("#mydiv").html()); /* ]]> */</script> <div id="mydiv">Hello World</div>

Porque cuando se analiza el script, el elemento #mydiv aún no está definido. En su lugar, esto funcionaría:

<div id="mydiv">Hello World</div> <script type="text/javascript">/* <![CDATA[ */ alert($("#mydiv").html()); /* ]]> */</script>

O

<script type="text/javascript">/* <![CDATA[ */ $(window).ready(function(){ alert($("#mydiv").html()); }); /* ]]> */</script> <div id="mydiv">Hello World</div>

Si está preguntando esto porque desea acelerar su sitio web, visite la página de Yahoo en Mejores prácticas para acelerar su sitio web. Tiene muchas mejores prácticas para acelerar su sitio web.