web-dev-qa-db-fra.com

La recommandation d'inclure CSS avant JavaScript est-elle invalide?

Dans d'innombrables endroits en ligne, j'ai vu la recommandation d'inclure CSS avant JavaScript. Le raisonnement est généralement, de cette forme :

Quand il s'agit de commander votre CSS et JavaScript, vous voulez que votre CSS soit la priorité. La raison en est que le fil de rendu dispose de toutes les informations de style nécessaires au rendu de la page. Si le JavaScript inclut en premier, le moteur JavaScript doit tout analyser avant de passer au groupe de ressources suivant. Cela signifie que le fil de rendu ne peut pas afficher complètement la page, car il ne possède pas tous les styles dont il a besoin.

Mes tests actuels révèlent quelque chose d'assez différent:

Mon harnais de test

J'utilise le script Ruby suivant pour générer des retards spécifiques pour diverses ressources:

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..."
}

Le mini-serveur ci-dessus me permet de définir des délais arbitraires pour les fichiers JavaScript (serveur et client) et des délais CSS arbitraires. Par exemple, http://10.0.0.50:8081/test.css?delay=500 me donne un délai de 500 ms pour transférer le CSS.

J'utilise la page suivante pour tester.

<!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>

Lorsque j'inclus le CSS pour la première fois, le rendu de la page prend 1,5 seconde:

CSS first

Lorsque j'inclus d'abord le code JavaScript, le rendu de la page prend 1,4 seconde:

JavaScript first

J'obtiens des résultats similaires dans Chrome, Firefox et Internet Explorer. Cependant, dans Opera, l'ordre n'a pas d'importance.

Il semble que l'interpréteur JavaScript refuse de démarrer tant que tout le CSS n'est pas téléchargé. Donc, il semble qu'avoir JavaScript inclut en premier est plus efficace car le thread JavaScript a plus de temps d'exécution.

Est-ce que quelque chose me manque, est-ce que la recommandation de placer les fichiers CSS avant les fichiers JavaScript est incorrecte?

Il est clair que nous pourrions ajouter async ou utiliser setTimeout pour libérer le fil de rendu ou placer le code JavaScript dans le pied de page, ou utiliser un chargeur JavaScript. Le point ici concerne la commande des bits JavaScript essentiels et des bits CSS dans la tête.

javascriptcssperformance
873
Sam Saffron

C'est une question très intéressante. J'ai toujours mis mes CSS _<link href="...">_ s avant mes JS _<script src="...">_ s parce que "j'ai lu une fois que c'était mieux". Alors tu as raison; Il est grand temps de faire des recherches!

J'ai configuré mon propre faisceau de test dans Node (code ci-dessous). En gros, je:

  • Assurez-vous qu'il n'y a pas de cache HTTP afin que le navigateur doive effectuer un téléchargement complet chaque fois qu'une page est chargée.
  • Pour simuler la réalité, j'ai inclus jQuery et le H5BP CSS (il y a donc une bonne quantité de scripts/CSS à analyser)
  • Configurez deux pages: une avec CSS avant script et une avec CSS après script.
  • Enregistré combien de temps il a fallu au script externe dans le <head> pour s'exécuter
  • Enregistré combien de temps il a fallu pour que le script en ligne dans le <body> soit exécuté, ce qui est analogue à DOMReady.
  • Retard d’envoi de CSS et/ou de script au navigateur de 500 ms.
  • A fait le test 20 fois dans les 3 principaux navigateurs.

Résultats

Tout d’abord, avec le fichier CSS retardé de 500 ms:

_     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
_

Ensuite, j’ai configuré jQuery pour retarder de 500 ms au lieu du 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
_

Enfin, j’ai mis à la fois jQuery et le CSS à retarder de 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
_

Conclusions

Premièrement, il est important de noter que je pars du principe que vous avez des scripts situés dans le _<head>_ de votre document (par opposition à la fin du _<body>_). Il existe différents arguments pour expliquer la possibilité de lier vos scripts dans _<head>_ à la fin du document, mais cela n’entre pas dans le cadre de cette réponse. Il s’agit uniquement de savoir si _<script>_ s doit aller avant _<link>_ s dans le _<head>_.

Dans les navigateurs modernes de type DESKTOP, , il ressemble à un lien vers CSS en premier jamais fournit un gain de performance. Le fait de placer CSS après le script vous procure un gain insignifiant lorsque le CSS et le script sont retardés, mais vous procure des gains importants lorsque le CSS est retardé. (Indiqué par les colonnes last du premier ensemble de résultats.)

Etant donné que la liaison avec CSS en dernier ne semble pas nuire aux performances, mais peut apporter des gains dans certaines circonstances, vous devez créer un lien vers des feuilles de style externes après , vous créez un lien vers des scripts externes uniquement sur les navigateurs de bureau si les performances des anciens navigateurs ne sont pas préoccupantes. . Continuez votre lecture pour la situation mobile.

Pourquoi?

Historiquement, lorsqu'un navigateur rencontrait une balise _<script>_ pointant vers une ressource externe, le navigateur arrêtait en analysant le code HTML, récupérait le script, exécutait puis continuez à analyser le code HTML. En revanche, si le navigateur rencontre un _<link>_ pour une feuille de style externe, il continue analyse le code HTML tout en extrayant le fichier CSS (en parallèle).

Par conséquent, il est généralement conseillé de placer les feuilles de style en premier, le premier script à télécharger pouvant être chargé en parallèle.

Cependant, les navigateurs modernes (y compris tous les navigateurs que j'ai testés ci-dessus) ont implémenté l'analyse spéculative , où le navigateur "anticipe" dans le code HTML et commence à télécharger les ressources avant le téléchargement et l'exécution des scripts .

Dans les anciens navigateurs sans analyse spéculative, placer les scripts en premier affectera les performances car ils ne téléchargeront pas en parallèle.

Prise en charge du navigateur

L'analyse spéculative a été mise en œuvre pour la première fois dans: (avec le pourcentage d'utilisateurs de navigateurs de bureau mondiaux utilisant cette version ou une version plus récente à compter de janvier 2012)

  • Chrome 1 (WebKit 525) (100%)
  • IE 8 (75%)
  • Firefox 3.5 (96%)
  • Safari 4 (99%)
  • Opéra 11,60 (85%)

Au total, environ 85% des navigateurs de bureau utilisés aujourd'hui prennent en charge le chargement spéculatif. Placer des scripts avant CSS aura un impact négatif sur les performances de 15% des utilisateurs globalement ; YMMV en fonction du public spécifique de votre site. (Et rappelez-vous que ce nombre diminue.)

Sur les navigateurs mobiles, il est un peu plus difficile d'obtenir des chiffres définitifs simplement à cause de l'hétérogénéité du navigateur et du paysage de système d'exploitation. Depuis que le rendu spéculatif a été implémenté dans WebKit 525 (sorti en mars 2008) et que presque tous les navigateurs mobiles valables sont basés sur WebKit, nous pouvons en conclure que "la plupart" des navigateurs mobiles devraient le prendre en charge. . Selon quirksmode , iOS 2.2/Android 1.0 utilise WebKit 525. Je ne sais pas du tout à quoi ressemble Windows Phone.

Cependant, , j'ai exécuté le test sur mon appareil Android 4 et, même si j'ai vu des chiffres similaires aux résultats de l'ordinateur, je l'ai raccroché. jusqu’à la nouvelle fantastique débogueur distant dans Chrome pour Android, et l’onglet Réseau a montré que le navigateur attendait réellement le téléchargement du fichier CSS jusqu’à ce que les scripts Java soient complètement chargés - en d’autres termes, Même la dernière version de WebKit pour Android ne semble pas prendre en charge l'analyse spéculative. Je soupçonne qu'elle pourrait être désactivée en raison du processeur , mémoire et/ou contraintes de réseau inhérentes aux appareils mobiles.

Code

Pardonnez la négligence - c'était 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 était jquery-1.7.1.min.js

694
josh3736

Il y a deux raisons principales pour mettre CSS avant JavaScript.

  1. Les anciens navigateurs (Internet Explorer 6-7, Firefox 2, etc.) bloquaient tous les téléchargements ultérieurs lorsqu'ils commençaient à télécharger un script. Donc, si vous avez a.js suivi de b.css, ils sont téléchargés séquentiellement: d'abord a puis b. Si vous avez b.css suivi de a.js, ils sont téléchargés en parallèle afin que la page se charge plus rapidement.

  2. Rien n'est rendu jusqu'à ce que toutes les feuilles de style soient téléchargées - ceci est vrai dans tous les navigateurs. Les scripts sont différents: ils bloquent le rendu de tous les éléments DOM situés sous la balise de script de la page. Si vous placez vos scripts dans HEAD, cela signifie que le rendu de la page entière sera bloqué jusqu'à ce que toutes les feuilles de style et tous les scripts soient téléchargés. Bien qu'il soit judicieux de bloquer tout le rendu des feuilles de style (afin d'obtenir le style correct dès la première fois et d'éviter le flash de contenu non traité), cela n'a pas de sens de bloquer le rendu de la page entière pour les scripts. Souvent, les scripts n'affectent aucun élément du DOM ou seulement une partie de ceux-ci. Il est préférable de charger les scripts aussi bas que possible dans la page, voire mieux de les charger de manière asynchrone.

C'est amusant de créer des exemples avec Cuzillion . Par exemple, cette page a un script dans le HEAD, de sorte que la page entière est vierge jusqu'à la fin du téléchargement. Cependant, si nous déplaçons le script à la fin du bloc BODY, l'en-tête de la page est rendu, car ces éléments DOM apparaissent au-dessus de la balise SCRIPT, comme vous pouvez le voir sur cette page .

299
Steve Souders

Je ne voudrais pas trop insister sur les résultats que vous avez obtenus, je pense que c'est subjectif, mais j'ai une raison de vous expliquer qu'il vaut mieux mettre en CSS avant js.

Lors du chargement de votre site Web, il existe deux scénarios que vous verriez:

CAS 1: écran blanc> site Web non stylé> site Web stylé> interaction> site Web stylé et interactif

CAS 2: écran blanc> site Web non stylé> interaction> site Web stylé> site Web stylé et interactif

Honnêtement, je ne peux pas imaginer que quelqu'un choisisse Case 2. Cela voudrait dire que les visiteurs utilisant des connexions Internet lentes seront confrontés à un site Web déshabillé, qui leur permet d'interagir avec ce site en utilisant Javascript (car il est déjà chargé). De plus, le temps passé à regarder un site Web non stylé serait ainsi optimisé. Pourquoi quelqu'un voudrait-il cela?

Cela fonctionne également mieux comme états de jQuery

"Lorsque vous utilisez des scripts qui reposent sur la valeur des propriétés de style CSS, il est important de référencer les feuilles de style externes ou les éléments de style incorporés avant de référencer les scripts".

Lorsque les fichiers sont chargés dans le mauvais ordre (d'abord JS, puis CSS), le code Javascript s'appuyant sur les propriétés définies dans les fichiers CSS (par exemple, la largeur ou la hauteur d'un div) ne sera pas chargé correctement. Il semble qu'avec un ordre de chargement incorrect, les propriétés correctes sont "parfois" connues de Javascript (ceci est peut-être causé par une situation de concurrence critique?). Cet effet semble plus ou moins important selon le navigateur utilisé.

41
defau1t

Vos tests ont-ils été effectués sur votre ordinateur personnel ou sur un serveur Web? C'est une page blanche ou s'agit-il d'un système en ligne complexe avec des images, des bases de données, etc.? Vos scripts effectuent-ils une simple action d'événement survol ou sont-ils un élément essentiel de la manière dont votre site Web rend et interagit avec l'utilisateur? Il y a plusieurs choses à considérer ici, et la pertinence de ces recommandations deviennent presque toujours des règles lorsque vous vous aventurez dans un développement Web de haut calibre.

Le but de la règle "mettre les feuilles de style en haut et les scripts en bas" est que, en général, c'est le meilleur moyen d'obtenir un rendu optimal , qui est critique pour l'expérience utilisateur.

Tout le reste mis à part: si votre test est valide et que vous produisez des résultats contraires aux règles populaires, ce n'est vraiment pas une surprise. Chaque site Web (et tout ce qu'il faut pour que tout cela apparaisse sur l'écran d'un utilisateur) est différent et Internet évolue constamment.

25
skippr

J'inclus les fichiers CSS avant Javascript pour une raison différente.

Si mon Javascript nécessite un dimensionnement dynamique de certains éléments de page (pour les angles où CSS est vraiment un élément principal à l'arrière), le chargement du CSS après le traitement de JS peut conduire à des conditions de concurrence critique, où l'élément est redimensionné avant les styles CSS sont appliqués et ont donc l’air bizarre lorsque les styles entrent enfin en jeu. Si je charge le CSS à l’avance, je peux garantir que les choses se déroulent dans l’ordre prévu et que la présentation finale correspond à ce que je veux.

21
hugomg

La recommandation d'inclure CSS avant JavaScript est-elle invalide?

Pas si vous le traitez comme une simple recommandation. Mais si vous traitez cela comme une règle absolue ?, oui, il est invalide.

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

Stylesheet charge l'exécution du script en bloc. Ainsi, si vous avez un <script> après un <link rel="stylesheet" ...>, l'analyse de la page ne sera pas terminée - et DOMContentLoaded ne se déclenchera pas - jusqu'à ce que la feuille de style soit chargée.

Il semble que vous ayez besoin de savoir sur quoi chaque script s'appuie et de vous assurer que l'exécution du script est retardée après le bon événement d'achèvement. Si le script ne s'appuie que sur le DOM, il peut reprendre dans ondomready/domcontentloaded, s'il repose sur des images à charger ou sur des feuilles de style à appliquer, alors si je lis correctement la référence ci-dessus, ce code doit être différé jusqu'à l'événement onload.

Je ne pense pas qu'une taille de chaussette convient à tous, même si c'est la façon dont elles sont vendues et je sais qu'une taille de chaussure ne convient pas à tous. Je ne pense pas qu'il existe une réponse définitive à laquelle charger en premier, les styles ou les scripts. Il s’agit plus d’une décision prise au cas par cas pour déterminer ce qui doit être chargé dans quel ordre et ce qui peut être reporté à une date ultérieure car il n’est pas sur le "chemin critique".

Pour parler à l'observateur qui a commenté qu'il était préférable de retarder la capacité des utilisateurs à interagir jusqu'à ce que la feuille soit belle. Vous êtes nombreux et ennuyez vos homologues qui pensent le contraire. Ils sont venus sur un site pour atteindre un objectif et il est très frustrant de pouvoir retarder leur capacité à interagir avec un site tout en attendant que des tâches sans importance soient terminées. Je ne dis pas que vous avez tort, mais seulement que vous devez savoir qu’il existe une autre faction qui ne partage pas votre priorité.

Cette question s'applique particulièrement à toutes les annonces placées sur des sites Web. J'adorerais que les auteurs de site rendent juste des divs d'espace réservé pour le contenu de l'annonce et s'assurent que leur site est chargé et interactif avant d'injecter les annonces dans un événement onload. Même dans ce cas, j'aimerais que les annonces soient chargées en série plutôt qu'en une seule fois, car elles ont un impact sur ma capacité à même faire défiler le contenu du site pendant le chargement des annonces surchargées. Mais ce n'est que le point de vue d'une personne.

  • Connaissez vos utilisateurs et ce qu’ils apprécient.
  • Connaissez vos utilisateurs et leur environnement de navigation.
  • Sachez ce que fait chaque fichier et quels sont ses pré-requis. Pour que tout fonctionne correctement, la priorité sera donnée à la vitesse et à la beauté.
  • Utilisez des outils qui vous indiquent la chronologie du réseau lors du développement.
  • Testez dans chacun des environnements utilisés par vos utilisateurs. Il peut être nécessaire de modifier dynamiquement (côté serveur, lors de la création de la page) l'ordre de chargement en fonction de l'environnement de l'utilisateur.
  • En cas de doute, modifiez l'ordre et mesurez à nouveau.
  • Il est possible que le mélange des styles et des scripts dans l'ordre de chargement soit optimal; pas tous l'un puis tous les autres.
  • Expérimentez non seulement dans quel ordre charger les fichiers, mais où. Tête? Dans le corps? Après le corps? DOM prêt/chargé? Chargé?
  • Envisagez les options asynchrone et différée, le cas échéant, afin de réduire le délai net que l'utilisateur rencontrera avant de pouvoir interagir avec la page. Testez pour déterminer s'ils aident ou blessent.
  • Il y aura toujours des compromis à prendre en compte lors de l'évaluation de l'ordre de chargement optimal. Pretty vs. Responsive étant juste un.
10
Ted Cohen

Mis à jour le 2017-12-16

Je n'étais pas sûr des tests en OP. J'ai décidé d'expérimenter un peu et j'ai fini par briser certains des mythes.

Synchronous <script src...> bloquera le téléchargement des ressources en dessous jusqu'à son téléchargement et son exécution.

Ce n'est plus vrai . Regardez la cascade générée par 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>

Chrome net inspector -> waterfall

<link rel=stylesheet> ne bloquera pas le téléchargement et l'exécution des scripts situés en dessous.

Ceci est incorrect . La feuille de style ne bloquera pas le téléchargement mais bloquera l'exécution du script ( petite explication ici ). Consultez le tableau de performances généré par 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>

Chrome dev tools -> performance

Compte tenu de ce qui précède, les résultats en OP peuvent être expliqués comme suit:

CSS d'abord:

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

JS First:

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

Je ne sais pas exactement comment vos tests "rendent" le temps comme votre script using Java. Cependant, considérez ceci

Une page sur votre site fait 50k, ce qui n’est pas déraisonnable. L'utilisateur est sur la côte est alors que votre serveur est à l'ouest. MTU n'est certainement pas 10k, donc il y aura quelques allers et retours. Cela peut prendre une demi-seconde pour recevoir votre page et vos feuilles de style. Typiquement (pour moi) javascript (via le plugin jquery et autres) est beaucoup plus que CSS. Il y a aussi ce qui se passe lorsque votre connexion Internet s'étouffe au milieu de la page mais permet de l'ignorer (cela m'arrive de temps en temps et je crois que le rendu css est rendu mais je ne suis pas sûr à 100%).

Puisque css est en tête, il peut y avoir des connexions supplémentaires pour l'obtenir, ce qui signifie qu'il peut éventuellement se terminer avant la page. Quoi qu’il en soit, pendant le type, le reste de la page prend et les fichiers javascript (qui sont beaucoup plus d’octets), la page est sans style, ce qui rend le site/la connexion plus lent.

MÊME SI l'interpréteur JS refuse de démarrer tant que le CSS n'a pas terminé, le temps nécessaire pour télécharger le code javascript, en particulier lorsque le serveur coupe loin dans le temps CSS, ce qui rendra le site moins attrayant.

C'est une petite optimisation mais c'est la raison.

4
user34537

Voici un SUMMARY de toutes les réponses majeures ci-dessus (ou peut-être ci-dessous plus tard :)

Pour les navigateurs modernes, placez css où bon vous semble. Ils analysent votre fichier html (qu'ils appellent analyse spéculative) et commencent à télécharger css en parallèle avec l'analyse html.

Pour les anciens navigateurs, continuez à mettre les CSS au premier plan (si vous ne souhaitez pas afficher une page nue mais interactive en premier).

Pour tous les navigateurs, mettez le javascript aussi loin que possible sur la page, car cela arrêterait l’analyse de votre code HTML. De préférence, téléchargez-le de manière asynchrone (c'est-à-dire, appel ajax)

Il existe également des résultats expérimentaux pour un cas particulier qui prétendent placer le javascript en premier (par opposition à la sagesse traditionnelle de mettre le CSS en premier) donne de meilleures performances, mais aucun raisonnement logique ne le justifie et manque de validation concernant une applicabilité étendue. l'ignorer pour l'instant.

Donc, pour répondre à la question: oui. La recommandation d'inclure le CSS avant JS n'est pas valide pour les navigateurs modernes. Placez CSS où vous voulez et mettez JS vers la fin, autant que possible.

3
mehmet

Steve Souders a déjà donné une réponse définitive mais ...

Je me demande s'il y a un problème avec le test original de Sam et la répétition de Josh.

Les deux tests semblent avoir été effectués sur des connexions à faible temps de latence, où la configuration de la connexion TCP aura un coût trivial.

En quoi cela affecte-t-il le résultat du test? Je ne suis pas sûr et j'aimerais examiner les cascades pour les tests via une connexion de latence "normale", mais ...

Le premier fichier téléchargé devrait obtient la connexion utilisée pour la page html, et le deuxième fichier téléchargé obtiendra la nouvelle connexion. (Flushing le début modifie cette dynamique, mais ce n'est pas fait ici)

Dans les nouveaux navigateurs, la deuxième connexion TCP est ouverte de manière spéculative, de sorte que la surcharge de la connexion est réduite/disparaît. Dans les navigateurs plus anciens, cela n'est pas vrai et la deuxième connexion aura la surcharge d'être ouverte.

Comment/si cela affecte le résultat des tests, je ne suis pas sûr.

1
Andy Davies

Je pense que ce ne sera pas vrai pour tous les cas. Parce que css va télécharger en parallèle mais js ne peux pas. Considérer pour le même cas,

Au lieu d’avoir un seul fichier CSS, prenez 2 ou 3 fichiers CSS et essayez-le de cette manière,

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

Je suis sûr que css..css..js donnera un meilleur résultat que tous les autres.

1
harishkumar329

Nous devons garder à l’esprit que les nouveaux navigateurs ont travaillé sur leurs moteurs Javascript, leurs analyseurs syntaxiques, etc., optimisant ainsi les problèmes de code et de balisage courants de manière à ce que les problèmes rencontrés avec les anciens navigateurs tels que <= IE8 ne soient plus pertinents, pas seulement. En ce qui concerne le balisage, mais aussi l’utilisation de variables JavaScript, de sélecteurs d’éléments, etc. Je vois dans un avenir pas si lointain une situation où la technologie a atteint un point où la performance n’est plus vraiment un problème.

0
George Katsanos