validar validacion vacios insertar formularios formulario enviar ejemplos con codigo campos antes javascript css performance

validacion - validar formulario javascript html5



¿La recomendación de incluir CSS antes de JavaScript no es válida? (13)

En innumerables lugares en línea he visto la recomendación de incluir CSS antes de JavaScript. El razonamiento es generalmente, de esta forma :

Cuando se trata de ordenar su CSS y JavaScript, usted quiere que su CSS sea lo primero. El motivo es que el subproceso de representación tiene toda la información de estilo que necesita para representar la página. Si la inclusión de JavaScript es lo primero, el motor de JavaScript debe analizarlo todo antes de continuar con el siguiente conjunto de recursos. Esto significa que el subproceso de representación no puede mostrar completamente la página, ya que no tiene todos los estilos que necesita.

Mi prueba real revela algo muy diferente:

Mi arnés de prueba

Uso el siguiente script de Ruby para generar retrasos específicos para varios recursos:

require ''rubygems'' require ''eventmachine'' require ''evma_httpserver'' require ''date'' class Handler < EventMachine::Connection include EventMachine::HttpServer def process_http_request resp = EventMachine::DelegatedHttpResponse.new( self ) return unless @http_query_string path = @http_path_info array = @http_query_string.split("&").map{|s| s.split("=")}.flatten parsed = Hash[*array] delay = parsed["delay"].to_i / 1000.0 jsdelay = parsed["jsdelay"].to_i delay = 5 if (delay > 5) jsdelay = 5000 if (jsdelay > 5000) delay = 0 if (delay < 0) jsdelay = 0 if (jsdelay < 0) # Block which fulfills the request operation = proc do sleep delay if path.match(/.js$/) resp.status = 200 resp.headers["Content-Type"] = "text/javascript" resp.content = "(function(){ var start = new Date(); while(new Date() - start < #{jsdelay}){} })();" end if path.match(/.css$/) resp.status = 200 resp.headers["Content-Type"] = "text/css" resp.content = "body {font-size: 50px;}" end end # Callback block to execute once the request is fulfilled callback = proc do |res| resp.send_response end # Let the thread pool (20 Ruby threads) handle request EM.defer(operation, callback) end end EventMachine::run { EventMachine::start_server("0.0.0.0", 8081, Handler) puts "Listening..." }

El mini servidor anterior me permite establecer demoras arbitrarias para archivos JavaScript (tanto del servidor como del cliente) y demoras de CSS arbitrarias. Por ejemplo, http://10.0.0.50:8081/test.css?delay=500 me da un retraso de 500 ms en la transferencia del CSS.

Uso la siguiente página para probar.

<!DOCTYPE html> <html> <head> <title>test</title> <script type=''text/javascript''> var startTime = new Date(); </script> <link href="http://10.0.0.50:8081/test.css?delay=500" type="text/css" rel="stylesheet"> <script type="text/javascript" src="http://10.0.0.50:8081/test2.js?delay=400&amp;jsdelay=1000"></script> </head> <body> <p> Elapsed time is: <script type=''text/javascript''> document.write(new Date() - startTime); </script> </p> </body> </html>

Cuando incluyo el CSS primero, la página tarda 1.5 segundos en procesarse:

Cuando incluyo el JavaScript primero, la página tarda 1.4 segundos en procesarse:

Obtengo resultados similares en Chrome, Firefox e Internet Explorer. En Opera, sin embargo, el ordenamiento simplemente no importa.

Lo que parece estar sucediendo es que el intérprete de JavaScript se niega a iniciarse hasta que se descargue todo el CSS. Por lo tanto, parece que tener JavaScript primero es más eficiente a medida que el hilo de JavaScript obtiene más tiempo de ejecución.

¿Me estoy perdiendo algo? ¿La recomendación de colocar CSS incluye antes de JavaScript no es correcta?

Está claro que podríamos agregar async o usar setTimeout para liberar el subproceso de procesamiento o poner el código JavaScript en el pie de página, o usar un cargador de JavaScript. El punto aquí es sobre el ordenamiento de bits de JavaScript esenciales y bits de CSS en la cabeza.

¿La recomendación de incluir CSS antes de JavaScript no es válida?

No si lo tratas como una simple recomendación. Pero si lo tratas como una regla dura y rápida, sí, no es válido.

Desde https://developer.mozilla.org/en-US/docs/Web/Reference/Events/DOMContentLoaded

La hoja de estilo carga la ejecución del script de bloque, por lo que si tiene un <script> después de un <link rel="stylesheet" ...> la página no finalizará el análisis, y DOMContentLoaded no se activará, hasta que se cargue la hoja de estilos.

Parece que necesita saber en qué se basa cada script y asegurarse de que la ejecución del script se demore hasta después del evento de finalización correcto. Si la secuencia de comandos se basa únicamente en el DOM, se puede reanudar en ondomready / domcontentloaded, si se basa en las imágenes que se cargarán o en las hojas de estilo que se aplicarán, entonces si leo la referencia anterior correctamente, ese código debe aplazarse hasta el evento de carga.

No creo que un tamaño de calcetín se adapte a todos, aunque esa es la forma en que se venden y sé que un tamaño de zapato no se ajusta a todos. No creo que haya una respuesta definitiva para cargar primero, los estilos o el script. Es más una decisión caso por caso de qué se debe cargar en qué orden y qué se puede aplazar hasta más adelante porque no está en la "ruta crítica".

Para hablar con el observador que comentó que es mejor retrasar la capacidad de los usuarios para interactuar hasta que la hoja sea bonita. Hay muchos de ustedes ahí fuera y molestan a sus contrapartes que sienten lo contrario. Llegaron a un sitio para lograr un propósito y demoras en su capacidad para interactuar con un sitio mientras esperan que las cosas que no importan para terminar de cargarse sean muy frustrantes. No estoy diciendo que estés equivocado, solo que debes tener en cuenta que existe otra facción que no comparte tu prioridad.

Esta pregunta se aplica particularmente a todos los anuncios que se colocan en los sitios web. Me encantaría que los autores del sitio presentaran solo divs de marcadores de posición para el contenido del anuncio y se aseguraran de que su sitio estuviera cargado e interactivo antes de inyectar los anuncios en un evento onload. Incluso entonces me gustaría ver los anuncios cargados en serie en lugar de todos a la vez, ya que afectan mi capacidad para desplazar incluso el contenido del sitio mientras se cargan los anuncios hinchados. Pero ese es solo el punto de vista de una persona.

  • Conozca a sus usuarios y lo que ellos valoran.
  • Conozca a sus usuarios y qué entorno de navegación utilizan.
  • Sepa qué hace cada archivo y cuáles son sus requisitos previos. Hacer que todo funcione tenga prioridad sobre la velocidad y la belleza.
  • Use herramientas que le muestren la línea de tiempo de la red al desarrollar.
  • Pruebe en cada uno de los entornos que utilizan sus usuarios. Puede ser necesario para dinámicamente (lado del servidor, al crear la página) alterar el orden de carga en función del entorno de los usuarios.
  • En caso de duda, altera el orden y vuelve a medir.
  • Es posible que los estilos de mezcla y los scripts en el orden de carga sean óptimos; no todos de uno y todos los otros.
  • Experimente no solo en qué orden cargar los archivos sino en dónde. ¿Cabeza? ¿En cuerpo? Después del cuerpo? DOM listo / cargado? ¿Cargado?
  • Considere opciones asíncronas y diferidas cuando sea apropiado para reducir el retraso neto que el usuario experimentará antes de poder interactuar con la página. Prueba para determinar si ayudan o lastiman.
  • Siempre habrá concesiones a considerar al evaluar el orden de carga óptimo. Pretty vs. Responsive siendo solo uno.

¿Se realizaron las pruebas en su computadora personal o en un servidor web? ¿Es una página en blanco o es un sistema en línea complejo con imágenes, bases de datos, etc.? ¿Sus scripts realizan una simple acción de evento de desplazamiento, o son un componente central de cómo su sitio web presenta e interactúa con el usuario? Hay varias cosas a considerar aquí, y la relevancia de estas recomendaciones casi siempre se convierten en reglas cuando se aventura en un desarrollo web de alto calibre.

El propósito de la regla de "poner hojas de estilo en la parte superior y los scripts en la parte inferior" es que, en general, es la mejor manera de lograr una representación progresiva óptima, que es fundamental para la experiencia del usuario.

Aparte de eso: suponiendo que su prueba sea válida y que realmente esté produciendo resultados contrarios a las reglas populares, en realidad no sería una sorpresa. Cada sitio web (y todo lo que se necesita para que todo aparezca en la pantalla de un usuario) es diferente e Internet está en constante evolución.

Aquí hay un RESUMEN de todas las respuestas principales anteriores (o tal vez más adelante)

Para los navegadores modernos, ponga css donde lo desee. Analizarían su archivo html (al que llaman análisis especulativo ) y comenzarían a descargar css en paralelo con el análisis html.

Para los navegadores antiguos, siga poniendo css en la parte superior (si no desea mostrar una página desnuda pero interactiva primero).

Para todos los navegadores, ponga javascript lo más abajo posible en la página, ya que detendrá el análisis de su html. Preferiblemente, descárguelo de forma asíncrona (es decir, llamada ajax)

También hay, algunos resultados experimentales para un caso particular, que afirma que poner primero javascript (a diferencia de la sabiduría tradicional de poner CSS primero) da un mejor rendimiento pero no hay un razonamiento lógico, y carece de validación con respecto a la aplicabilidad generalizada, por lo que puede ignorarlo por ahora

Entonces, para responder a la pregunta: sí. La recomendación de incluir el CSS antes de JS no es válida para los navegadores modernos. Coloca CSS donde quieras, y coloca JS hacia el final, como sea posible.

Creo que esto no será cierto para todos los casos. Porque css se descargará en paralelo pero js cant. Considere para el mismo caso,

En lugar de tener un solo css, tome 2 o 3 archivos css y pruébelo de esta manera,

1) css..css..js 2) css..js..css 3) js..css..css

Estoy seguro de que css..css..js dará mejores resultados que todos los demás.

Debemos tener en cuenta que los nuevos navegadores han funcionado en sus motores de Javascript, sus analizadores, etc., optimizando los problemas comunes de código y marcado de una manera en que los problemas experimentados en navegadores antiguos como <= IE8 ya no son relevantes, no solo con regards to markup but also to use of JavaScript variables, element selectors etc. I can see in the not so distant future a situation where technology has reached a point where performance is not really an issue anymore.

Esta es una pregunta muy interesante. Siempre he puesto mis CSS <link href="..."> antes de mi JS <script src="..."> porque "leí una vez que es mejor". Entonces, tienes razón; Es hora de que hagamos una investigación real!

Configuré mi propio arnés de prueba en Nodo (código a continuación). Básicamente, yo:

  • Asegúrese de que no haya almacenamiento en caché HTTP para que el navegador tenga que realizar una descarga completa cada vez que se carga una página.
  • Para simular la realidad, H5BP jQuery y H5BP CSS (así que hay una cantidad decente de script / CSS para analizar)
  • Configure dos páginas: una con CSS antes del script, una con CSS después del script.
  • Registró el tiempo que tardó en ejecutarse el script externo en el <head>
  • Registró el tiempo que tardó en ejecutarse el script en línea en <body> , que es análogo a DOMReady .
  • Retraso en el envío de CSS y / o script al navegador por 500ms.
  • Corrió la prueba 20 veces en los 3 navegadores principales.

Resultados

Primero, con el archivo CSS retrasado por 500ms:

Browser: Chrome 18 | IE 9 | Firefox 9 CSS: first last | first last | first last ======================================================= Header Exec | | | Average | 583ms 36ms | 559ms 42ms | 565ms 49ms St Dev | 15ms 12ms | 9ms 7ms | 13ms 6ms ------------|--------------|--------------|------------ Body Exec | | | Average | 584ms 521ms | 559ms 513ms | 565ms 519ms St Dev | 15ms 9ms | 9ms 5ms | 13ms 7ms

A continuación, configuré jQuery para retrasar 500 ms en lugar de CSS:

Browser: Chrome 18 | IE 9 | Firefox 9 CSS: first last | first last | first last ======================================================= Header Exec | | | Average | 597ms 556ms | 562ms 559ms | 564ms 564ms St Dev | 14ms 12ms | 11ms 7ms | 8ms 8ms ------------|--------------|--------------|------------ Body Exec | | | Average | 598ms 557ms | 563ms 560ms | 564ms 565ms St Dev | 14ms 12ms | 10ms 7ms | 8ms 8ms

Finalmente, configuré tanto jQuery como el CSS para retrasar 500 ms:

Browser: Chrome 18 | IE 9 | Firefox 9 CSS: first last | first last | first last ======================================================= Header Exec | | | Average | 620ms 560ms | 577ms 577ms | 571ms 567ms St Dev | 16ms 11ms | 19ms 9ms | 9ms 10ms ------------|--------------|--------------|------------ Body Exec | | | Average | 623ms 561ms | 578ms 580ms | 571ms 568ms St Dev | 18ms 11ms | 19ms 9ms | 9ms 10ms

Conclusiones

Primero, es importante tener en cuenta que estoy operando bajo el supuesto de que tiene scripts ubicados en el <head> de su documento (en oposición al final del <body> ). Hay varios argumentos con respecto a por qué puede vincular sus scripts en el <head> frente al final del documento, pero eso está fuera del alcance de esta respuesta. Esto es estrictamente sobre si <script> s debe ir antes de <link> s en el <head> .

En los navegadores DESKTOP modernos, parece que la vinculación a CSS nunca proporciona un aumento de rendimiento. Poner CSS después de la secuencia de comandos le otorga una cantidad trivial de ganancia cuando tanto la CSS como la secuencia de comandos se retrasan, pero le da grandes ganancias cuando la CSS se retrasa. (Se muestra por las last columnas en el primer conjunto de resultados).

Dado que la vinculación a CSS por última vez no parece perjudicar el rendimiento, pero puede proporcionar beneficios en ciertas circunstancias, debe vincular a las hojas de estilo externas después de vincular las secuencias de comandos externas solo en los navegadores de escritorio si el rendimiento de los navegadores antiguos no es una preocupación. Siga leyendo para conocer la situación móvil.

¿Por qué?

Históricamente, cuando un navegador encontró una etiqueta <script> apunta a un recurso externo, el navegador dejaría de analizar el HTML, recuperaría el script, lo ejecutaría y luego continuaría analizando el HTML. En contraste, si el navegador encontró un <link> para una hoja de estilo externa, continuaría analizando el HTML mientras buscaba el archivo CSS (en paralelo).

Por lo tanto, el consejo ampliamente repetido de poner las hojas de estilo en primer lugar: primero se descargarían y el primer script para descargar se podría cargar en paralelo.

Sin embargo, los navegadores modernos (incluidos todos los navegadores con los que probé anteriormente) han implementado el análisis especulativo , donde el navegador "mira hacia adelante" en el HTML y comienza a descargar recursos antes de que los scripts se descarguen y ejecuten.

En los navegadores antiguos sin análisis especulativo, poner los scripts primero afectará el rendimiento, ya que no se descargarán en paralelo.

Soporte del navegador

El análisis especulativo se implementó por primera vez en: (junto con el porcentaje de usuarios de navegadores de escritorio en todo el mundo que utilizan esta versión o superior a partir de enero de 2012)

  • Chrome 1 (WebKit 525) (100%)
  • IE 8 (75%)
  • Firefox 3.5 (96%)
  • Safari 4 (99%)
  • Opera 11.60 (85%)

En total, aproximadamente el 85% de los navegadores de escritorio en uso hoy en día admiten la carga especulativa. Poner los scripts antes de CSS tendrá una penalización de rendimiento en el 15% de los usuarios a nivel mundial ; YMMV basado en la audiencia específica de su sitio. (Y recuerda que el número se está reduciendo).

En los navegadores móviles, es un poco más difícil obtener números definitivos simplemente debido a lo heterogéneo que es el navegador móvil y el panorama del sistema operativo. Dado que la representación especulativa se implementó en WebKit 525 (lanzada en marzo de 2008), y casi todos los navegadores móviles valiosos se basan en WebKit, podemos concluir que "la mayoría" de los navegadores móviles deberían admitirlo. De acuerdo con quirksmode , iOS 2.2 / Android 1.0 usa WebKit 525. No tengo idea de cómo se ve Windows Phone.

Sin embargo, ejecuté la prueba en mi dispositivo Android 4 y, aunque vi números similares a los resultados del escritorio, lo conecté al fantástico nuevo depurador remoto en Chrome para Android, y la pestaña Red mostró que el navegador realmente estaba esperando para descargar el CSS hasta que los JavaScripts estén completamente cargados; en otras palabras, incluso la versión más reciente de WebKit para Android no parece admitir el análisis especulativo. Sospecho que podría estar apagado debido a las limitaciones de la CPU, la memoria y / o la red inherentes a los dispositivos móviles.

Código

Perdona el descuido, esto fue Q&D.

app.js

var express = require(''express'') , app = express.createServer() , fs = require(''fs''); app.listen(90); var file={}; fs.readdirSync(''.'').forEach(function(f) { console.log(f) file[f] = fs.readFileSync(f); if (f != ''jquery.js'' && f != ''style.css'') app.get(''/'' + f, function(req,res) { res.contentType(f); res.send(file[f]); }); }); app.get(''/jquery.js'', function(req,res) { setTimeout(function() { res.contentType(''text/javascript''); res.send(file[''jquery.js'']); }, 500); }); app.get(''/style.css'', function(req,res) { setTimeout(function() { res.contentType(''text/css''); res.send(file[''style.css'']); }, 500); }); var headresults={ css: [], js: [] }, bodyresults={ css: [], js: [] } app.post(''/result/:type/:time/:exec'', function(req,res) { headresults[req.params.type].push(parseInt(req.params.time, 10)); bodyresults[req.params.type].push(parseInt(req.params.exec, 10)); res.end(); }); app.get(''/result/:type'', function(req,res) { var o = ''''; headresults[req.params.type].forEach(function(i) { o+=''/n'' + i; }); o+=''/n''; bodyresults[req.params.type].forEach(function(i) { o+=''/n'' + i; }); res.send(o); });

css.html

<!DOCTYPE html> <html> <head> <title>CSS first</title> <script>var start = Date.now();</script> <link rel="stylesheet" href="style.css"> <script src="jquery.js"></script> <script src="test.js"></script> </head> <body> <script>document.write(jsload - start);bodyexec=Date.now()</script> </body> </html>

js.html

<!DOCTYPE html> <html> <head> <title>CSS first</title> <script>var start = Date.now();</script> <script src="jquery.js"></script> <script src="test.js"></script> <link rel="stylesheet" href="style.css"> </head> <body> <script>document.write(jsload - start);bodyexec=Date.now()</script> </body> </html>

test.js

var jsload = Date.now(); $(function() { $.post(''/result'' + location.pathname.replace(''.html'','''') + ''/'' + (jsload - start) + ''/'' + (bodyexec - start)); });

jquery.js era jquery-1.7.1.min.js

Hay dos razones principales para poner CSS antes de JavaScript.

  1. Los navegadores antiguos (Internet Explorer 6-7, Firefox 2, etc.) bloquearían todas las descargas posteriores cuando comenzaran a descargar un script. Así que si tienes a.js seguido de b.css , se descargan secuencialmente: primero a y luego b. Si tiene b.css seguido de a.js , se descargan en paralelo para que la página se cargue más rápidamente.

  2. No se procesa nada hasta que se descargan todas las hojas de estilo, esto es cierto en todos los navegadores. Las secuencias de comandos son diferentes: bloquean la representación de todos los elementos DOM que están debajo de la etiqueta de secuencia de comandos en la página. Si coloca sus scripts en el HEAD, significa que toda la página está bloqueada para que no se reproduzca hasta que se descarguen todas las hojas de estilo y todos los scripts. Si bien tiene sentido bloquear todas las representaciones para las hojas de estilo (para que obtenga el estilo correcto la primera vez y evite el flash de FOUC sin estilo), no tiene sentido bloquear la representación de toda la página para los scripts. A menudo, los scripts no afectan ningún elemento DOM o solo una parte de los elementos DOM. Es mejor cargar scripts lo más bajo posible en la página, o incluso mejor cargarlos de forma asíncrona.

Es divertido crear ejemplos con Cuzillion . Por ejemplo, esta página tiene una secuencia de comandos en HEAD, por lo que toda la página está en blanco hasta que finaliza la descarga. Sin embargo, si movemos la secuencia de comandos al final del bloque BODY, el encabezado de la página se procesa, ya que esos elementos DOM aparecen por encima de la etiqueta SCRIPT, como puede ver en esta página .

Incluyo archivos CSS antes de Javascript por una razón diferente.

Si mi Javascript necesita hacer el tamaño dinámico de algún elemento de la página (para los casos de esquina donde CSS es realmente un elemento principal en la parte posterior), cargar el CSS después de que el JS se está ejecutando puede llevar a condiciones de carrera, donde el elemento cambia de tamaño antes de los estilos CSS se aplican y, por lo tanto, se ven raros cuando los estilos finalmente se activan. Si carga el CSS de antemano, puedo garantizar que las cosas se ejecuten en el orden previsto y que el diseño final es lo que quiero que sea.

No enfatizaría demasiado en los resultados que obtuviste, creo que es subjetivo, pero tengo una razón para explicarte que es mejor poner CSS antes que js.

Durante la carga de su sitio web, hay dos escenarios que vería:

CASO 1: pantalla en blanco> sitio web sin estilo> sitio web con estilo> interacción> sitio web con estilo e interactivo

CASO 2: pantalla blanca> sitio web sin estilo> interacción> sitio web de estilo> sitio web de estilo e interactivo

Honestamente, no puedo imaginar que alguien elija el Caso 2. Esto significaría que los visitantes que utilizan conexiones de Internet lentas se enfrentarán a un sitio web sin estilo, que les permite interactuar con él mediante Javascript (ya que ya está cargado). Además, la cantidad de tiempo dedicado a mirar un sitio web sin estilo se maximizaría de esta manera. ¿Por qué alguien querría eso?

También funciona mejor como jQuery afirma

"Cuando se utilizan scripts que se basan en el valor de las propiedades de estilo CSS, es importante hacer referencia a hojas de estilo externas o incrustar elementos de estilo antes de hacer referencia a los scripts".

Cuando los archivos se cargan en el orden incorrecto (primero JS, luego CSS), cualquier código Javascript que se base en las propiedades establecidas en los archivos CSS (por ejemplo, el ancho o el alto de un div) no se cargará correctamente. Parece que con el orden de carga incorrecto, las propiedades correctas son ''a veces'' conocidas por Javascript (¿quizás esto es causado por una condición de carrera?). Este efecto parece mayor o menor dependiendo del navegador utilizado.

No estoy exactamente seguro de cómo sus pruebas "procesan" el tiempo que usa su script java. Sin embargo considera esto

Una página en su sitio es 50k, lo que no es irrazonable. El usuario está en la costa este, mientras que su servidor está en el oeste. MTU definitivamente no es 10k, así que habrá algunos viajes de ida y vuelta. Puede tardar medio segundo en recibir tu página y hojas de estilo. Normalmente, para mí, javascript (a través del complemento jquery y demás) es mucho más que CSS. También existe lo que sucede cuando su conexión a Internet se colapsa a mitad de camino en la página, pero ignoremos eso (me sucede a mí ocasionalmente y creo que el css se muestra pero no estoy 100% seguro).

Como css está en la cabecera, puede haber conexiones adicionales para obtenerlo, lo que significa que potencialmente puede finalizar antes de que lo haga la página. De todos modos, durante el tipo, el resto de la página toma y los archivos javascript (que son muchos más bytes) la página no tiene estilo, lo que hace que el sitio / conexión parezca lento.

INCLUSO SI el intérprete de JS se niega a comenzar hasta que CSS haya terminado el tiempo necesario para descargar el código javascript, especialmente cuando lejos del servidor se está reduciendo al tiempo de CSS, lo que hará que el sitio no se vea bien.

Es una pequeña optimización, pero esa es la razón para ello.

Steve Souders ya ha dado una respuesta definitiva pero ...

Me pregunto si hay un problema con la prueba original de Sam y con la repetición de Josh.

Parece que ambas pruebas se han realizado en conexiones de baja latencia en las que la configuración de la conexión TCP tendrá un costo trivial.

Cómo afecta esto al resultado de la prueba, no estoy seguro y querría mirar las cataratas para las pruebas a través de una conexión de latencia "normal", pero ...

El primer archivo descargado debe obtener la conexión utilizada para la página html, y el segundo archivo descargado obtendrá la nueva conexión. (El lavado de los primeros cambios altera esa dinámica, pero no se está haciendo aquí)

En los navegadores más nuevos, la segunda conexión TCP se abre especulativamente, por lo que la sobrecarga de la conexión se reduce / desaparece, en los navegadores más antiguos esto no es cierto y la segunda conexión tendrá la sobrecarga de ser abierta.

Bastante cómo / si esto afecta el resultado de las pruebas, no estoy seguro.

Personalmente, no pondría demasiado énfasis en esa "sabiduría popular". Lo que pudo haber sido cierto en el pasado bien podría no serlo ahora. Supongo que todas las operaciones relacionadas con la interpretación y la representación de una página web son totalmente asíncronas ("buscar" algo y "actuar sobre él" son dos cosas completamente diferentes que pueden ser manejadas por diferentes hilos, etc. ) En cualquier caso, más allá de su control o su preocupación.

Puse las referencias de CSS en la parte "principal" del documento, junto con cualquier referencia a scripts externos. (Algunos scripts pueden exigir que se coloquen en el cuerpo, y si es así, obligarlos).

Más allá de eso ... si observa que "esto parece ser más rápido / lento que eso, en este / ese navegador", considere esta observación como una curiosidad interesante pero irrelevante y no permita que influya en sus decisiones de diseño. Demasiadas cosas cambian demasiado rápido. (¿Alguien quiere apostar sobre cuántos minutos pasarán antes de que el equipo de Firefox salga con otra versión provisional de su producto? Sí, yo tampoco).

Actualizado 2017-12-16

No estaba seguro de las pruebas en OP. Decidí experimentar un poco y terminé rompiendo algunos de los mitos.

Sincrónico <script src...> bloqueará la descarga de los recursos a continuación hasta que se descargue y ejecute

Esto ya no es cierto . Echa un vistazo a la cascada generada por Chrome 63:

<head> <script src="//alias-0.redacted.com/payload.php?type=js&amp;delay=333&amp;rand=1"></script> <script src="//alias-1.redacted.com/payload.php?type=js&amp;delay=333&amp;rand=2"></script> <script src="//alias-2.redacted.com/payload.php?type=js&amp;delay=333&amp;rand=3"></script> </head>

<link rel=stylesheet> no bloqueará la descarga y ejecución de scripts debajo de él

Esto es incorrecto La hoja de estilo no bloqueará la descarga, pero bloqueará la ejecución del script ( poca explicación aquí ). Echa un vistazo al gráfico de rendimiento generado por Chrome 63:

<link href="//alias-0.redacted.com/payload.php?type=css&amp;delay=666" rel="stylesheet"> <script src="//alias-1.redacted.com/payload.php?type=js&amp;delay=333&amp;block=1000"></script>

Teniendo en cuenta lo anterior, los resultados en OP se pueden explicar de la siguiente manera:

CSS Primero:

CSS Download 500ms:<------------------------------------------------> JS Download 400ms:<--------------------------------------> JS Execution 1000ms: <--------------------------------------------------------------------------------------------------> DOM Ready @1500ms: ◆

JS Primero:

JS Download 400ms:<--------------------------------------> CSS Download 500ms:<------------------------------------------------> JS Execution 1000ms: <--------------------------------------------------------------------------------------------------> DOM Ready @1400ms: ◆