0
166
Vistas¿CSS siempre debe preceder a Javascript?
En innumerables lugares en línea he visto la recomendación de incluir CSS antes que JavaScript. El razonamiento es generalmente, de esta forma :
Cuando se trata de ordenar su CSS y JavaScript, desea que su CSS sea lo primero. La razón es que el subproceso de representación tiene toda la información de estilo que necesita para representar la página. Si JavaScript incluye lo primero, el motor de JavaScript tiene que 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.
Mis pruebas reales revelan algo bastante 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 arbitrarias de CSS. Por ejemplo, http://10.0.0.50:8081/test.css?delay=500 me da un retraso de 500 ms al transferir el CSS.
Utilizo 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&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. Sin embargo, en Opera, el orden simplemente no importa.
Lo que parece estar sucediendo es que el intérprete de JavaScript se niega a iniciarse hasta que se descarga todo el CSS. Entonces, parece que tener JavaScript incluido primero es más eficiente ya que el hilo de JavaScript tiene más tiempo de ejecución.
¿Me estoy perdiendo algo? ¿La recomendación de incluir CSS antes de incluir JavaScript no es correcta?
Está claro que podríamos agregar async o usar setTimeout para liberar el hilo 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 orden de los bits esenciales de JavaScript y CSS en la cabeza.
12 Respuestas
Responde la pregunta0
Aquí hay un RESUMEN de todas las respuestas principales anteriores (o tal vez a continuación más adelante :)
Para los navegadores modernos, coloque css donde 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 primero una página desnuda pero interactiva).
Para todos los navegadores, coloque 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 javascript primero (a diferencia de la sabiduría tradicional de poner CSS primero) brinda un mejor rendimiento, pero no se da un razonamiento lógico para ello 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 que JS no es válida para los navegadores modernos. Ponga CSS donde quiera y ponga JS hacia el final, como sea posible.
0
La respuesta de 2020: probablemente no importe
La mejor respuesta aquí fue de 2012, así que decidí probar por mí mismo. En Chrome para Android, los recursos JS y CSS se descargan en paralelo y no pude detectar una diferencia en la velocidad de visualización de la página.
Incluí un artículo más detallado en mi blog.
0
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. Asumiría que todas las operaciones relacionadas con la interpretación y representación de una página web son completamente asincrónicas ("obtener" algo y "actuar en consecuencia" son dos cosas completamente diferentes que podrían estar siendo manejadas por diferentes subprocesos, etc. ), y en cualquier caso, totalmente fuera de su control o de su preocupación.
Pondría referencias de CSS en la parte "encabezado" del documento, junto con cualquier referencia a scripts externos. (Algunos guiones pueden exigir que se coloquen en el cuerpo y, de ser así, complázcalos).
Más allá de eso... si observa que "esto parece ser más rápido/más lento que eso, en este/aquel navegador", trate esta observación como una curiosidad interesante pero irrelevante y no deje que influya en sus decisiones de diseño. Demasiadas cosas cambian demasiado rápido. (¿Alguien quiere hacer apuestas sobre cuántos minutos pasarán antes de que el equipo de Firefox presente otro lanzamiento provisional de su producto? Sí, yo tampoco).
0
¿Sus pruebas se realizaron en su computadora personal o en un servidor web? ¿Es una página en blanco o es un complejo sistema en línea con imágenes, bases de datos, etc.? ¿Sus secuencias de comandos realizan una acción de evento de desplazamiento simple o son un componente central de cómo su sitio web se representa 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 te aventuras en el desarrollo web de alto calibre.
El propósito de la regla "coloque las hojas de estilo en la parte superior y las secuencias de comandos 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.
Dejando todo lo demás de lado: asumiendo que su prueba es válida, y realmente está produciendo resultados contrarios a las reglas populares, no sería una sorpresa, realmente. 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.
0
Hay dos razones principales para anteponer CSS a JavaScript.
Los navegadores antiguos (Internet Explorer 6-7, Firefox 2, etc.) bloquearían todas las descargas posteriores cuando comenzaran a descargar un script. Entonces, si tiene
a.jsseguido deb.css, se descargan secuencialmente: primero a, luego b. Si tieneb.cssseguido dea.js, se descargan en paralelo para que la página se cargue más rápido.No se procesa nada hasta que se descargan todas las hojas de estilo; esto es cierto en todos los navegadores. Los scripts son diferentes: bloquean la representación de todos los elementos DOM que están debajo de la etiqueta del script en la página. Si coloca sus scripts en HEAD, significa que la página completa está bloqueada para que no se represente hasta que se descarguen todas las hojas de estilo y todos los scripts. Si bien tiene sentido bloquear todo el procesamiento de las hojas de estilo (para obtener el estilo correcto la primera vez y evitar el flash de contenido sin estilo FOUC), no tiene sentido bloquear el procesamiento de toda la página para los scripts. A menudo, los scripts no afectan a ningún elemento DOM o solo a una parte de los elementos DOM. Es mejor cargar los scripts lo más abajo 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 un script en HEAD, por lo que toda la página está en blanco hasta que termine de descargarse. Sin embargo, si movemos la secuencia de comandos al final del bloque BODY, el encabezado de la página se representa, ya que esos elementos DOM aparecen encima de la etiqueta SCRIPT, como puede ver en esta página .
0
No haría mucho hincapié en los resultados que has obtenido, 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 blanca > 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 con estilo > sitio web con estilo e interactivo
Honestamente, no puedo imaginar a nadie eligiendo el Caso 2. Esto significaría que los visitantes que usan conexiones de Internet lentas se enfrentarán a un sitio web sin estilo, que les permite interactuar con él usando Javascript (dado 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 dice jQuery
"Al usar secuencias de comandos 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 las secuencias de comandos".
Cuando los archivos se cargan en el orden incorrecto (primero JS, luego CSS), cualquier código Javascript que dependa de 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 se deba a una condición de carrera?). Este efecto parece más grande o más pequeño según el navegador utilizado.
0
Incluyo archivos CSS antes de Javascript por una razón diferente.
Si mi Javascript necesita cambiar el tamaño dinámico de algún elemento de la página (para esos casos de esquina donde CSS es realmente un elemento principal en la parte posterior), entonces cargar el CSS después de que JS se está volviendo loco puede conducir a condiciones de carrera, donde el elemento se redimensiona antes que los estilos CSS. se aplican y, por lo tanto, se ve extraño cuando los estilos finalmente se activan. Si cargo el CSS de antemano, puedo garantizar que las cosas se ejecuten en el orden previsto y que el diseño final sea el que quiero que sea.
0
Debemos tener en cuenta que los nuevos navegadores han trabajado en sus motores Javascript, sus analizadores, etc., optimizando el código común y los problemas de marcado de tal manera que los problemas experimentados en navegadores antiguos como <=IE8 ya no son relevantes, no solo con con respecto al marcado, pero también al uso de variables de JavaScript, selectores de elementos, etc. Puedo ver en un futuro no muy lejano una situación en la que la tecnología ha llegado a un punto en el que el rendimiento ya no es realmente un problema.
0
No estoy exactamente seguro de cómo su prueba 'renderiza' el tiempo cuando usa el script Java. Sin embargo considera esto
Una página en su sitio es 50k que no es irrazonable. El usuario está en la costa este mientras que su servidor está en el oeste. MTU definitivamente no es 10k, por lo que habrá algunos viajes de ida y vuelta. Puede tomar 1/2 segundo recibir su página y hojas de estilo. Por lo general (para mí), javascript (a través del complemento jquery y demás) es mucho más que CSS. También está lo que sucede cuando su conexión a Internet se bloquea a la mitad de la página, pero ignoremos eso (me sucede ocasionalmente y creo que el css se procesa, pero no estoy 100% seguro).
Dado que css está en la cabeza, puede haber conexiones adicionales para obtenerlo, lo que significa que potencialmente puede terminar antes que la página. De todos modos, durante el tipo que toma el resto de la página y los archivos javascript (que son muchos más bytes), la página no tiene estilo, lo que hace que el sitio/la conexión parezcan lentos.
INCLUSO SI el intérprete de JS se niega a iniciarse hasta que se complete el CSS, el tiempo necesario para descargar el código javascript, especialmente cuando está lejos del servidor, está reduciendo el tiempo de css, lo que hará que el sitio no se vea bonito.
Es una pequeña optimización, pero esa es la razón de ello.
0
Steve Souders ya ha dado una respuesta definitiva pero...
Me pregunto si hay un problema tanto con la prueba original de Sam como con la repetición de Josh.
Ambas pruebas parecen haberse realizado en conexiones de baja latencia donde configurar la conexión TCP tendrá un costo trivial.
No estoy seguro de cómo afecta esto al resultado de la prueba y me gustaría ver las cascadas para las pruebas en 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 temprano 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 estar abierta.
No estoy seguro de cómo/si esto afecta el resultado de las pruebas.
0
Actualizado 2017-12-16
No estaba seguro de las pruebas en OP. Decidí experimentar un poco y terminé rompiendo algunos de los mitos.
Synchronous
<script src...>bloqueará la descarga de los recursos debajo de él hasta que se descargue y ejecute
Esto ya no es cierto . Eche un vistazo a la cascada generada por Chrome 63:
<head> <script src="//alias-0.redacted.com/payload.php?type=js&delay=333&rand=1"></script> <script src="//alias-1.redacted.com/payload.php?type=js&delay=333&rand=2"></script> <script src="//alias-2.redacted.com/payload.php?type=js&delay=333&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 ( pequeña explicación aquí ). Eche un vistazo al gráfico de rendimiento generado por Chrome 63:
<link href="//alias-0.redacted.com/payload.php?type=css&delay=666" rel="stylesheet"> <script src="//alias-1.redacted.com/payload.php?type=js&delay=333&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: ◆0
Creo que esto no será cierto para todos los casos. Porque css se descargará en paralelo pero js no puede. 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.