Является ли рекомендация включить CSS перед JavaScript недействительной?

в бесчисленных местах в Интернете я видел рекомендацию включить CSS до JavaScript. Рассуждения, как правило,формы:

когда дело доходит до заказа CSS и JavaScript, вы хотите, чтобы ваш CSS прийти первым. Причина в том, что поток рендеринга имеет все информация о стиле, необходимая для отображения страницы. Если JavaScript включает в себя сначала, движок JavaScript должен проанализировать все это раньше переходим к следующему набор ресурсов. Это означает рендеринг поток не может полностью показать страницу, так как у нее нет всех стили, которые ему нужны.

мое фактическое тестирование показывает что-то совсем другое:

мой тест проводов

Я использую следующий скрипт Ruby для генерации определенных задержек для различных ресурсов:

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

вышеуказанный мини-сервер позволяет мне устанавливать произвольные задержки для файлов JavaScript (как сервера, так и клиента) и произвольного CSS перебои. Например, http://10.0.0.50:8081/test.css?delay=500 дает мне 500 мс задержки передачи CSS.

Я использую следующую страницу для тестирования.

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

когда я сначала включаю CSS, страница занимает 1,5 секунды для рендеринга:

CSS first

когда я сначала включаю JavaScript, страница занимает 1,4 секунды для рендеринга:

JavaScript first

Я получаю аналогичные результаты в Chrome, Firefox и Internet Explorer. В Opera, однако, заказ просто не вопрос.

кажется, что происходит то, что интерпретатор JavaScript отказывается запускаться, пока не будут загружены все CSS. Таким образом, кажется, что наличие JavaScript включает в себя сначала более эффективно, поскольку поток JavaScript получает больше времени выполнения.

Я что-то пропустил, рекомендация разместить CSS включает в себя до JavaScript включает в себя не правильно?

ясно, что мы можем добавить async или использовать setTimeout для освобождения потока рендеринга или put код JavaScript в нижнем колонтитуле или используйте загрузчик JavaScript. Дело здесь в упорядочении основных бит JavaScript и бит CSS в голове.

13 ответов


это очень интересный вопрос. Я всегда ставил свой CSS <link href="...">s перед моим JS <script src="...">s потому что " я читал один раз, что это лучше.- Значит, вы правы, самое время заняться настоящим исследованием!

я настроил свой собственный тестовый жгут в узле (код ниже). В Принципе, Я:

  • убедитесь, что не было кэширования HTTP, поэтому браузер должен будет выполнять полную загрузку каждый раз при загрузке страницы.
  • для имитации реальности, я включил jQuery и the H5BP CSS (так что есть приличное количество скриптов/CSS для разбора)
  • настройте две страницы-одну с CSS перед скриптом, другую с CSS после скрипта.
  • записано, сколько времени потребовалось для внешнего скрипта в <head> для выполнения
  • записано, сколько времени потребовалось для встроенного скрипта в <body> выполнить, что аналогично DOMReady.
  • задержка отправки CSS и / или скрипта в браузер на 500ms.
  • провел тест 20 раз в 3 основных браузерах.

результаты

во-первых, с задержкой файла CSS на 500 мс:

     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

затем я установил jQuery для задержки на 500 мс вместо 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

наконец, я поставил и jQuery и CSS для задержки на 500 мс:

     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

выводы

во-первых, важно отметить, что я работаю под предположение, что у вас есть скрипты, расположенные в <head> вашего документа (в отличие от конца <body>). Существуют различные аргументы относительно того, почему вы можете ссылаться на свои скрипты в <head> по сравнению с концом документа, но это выходит за рамки данного ответа. Это строго о том,<script>s должен идти перед <link>s в <head>.

в современных настольных браузерах, это похоже на ссылку на CSS first никогда обеспечивает увеличение производительности. Ввод CSS после скрипта дает вам тривиальную прибыль, когда CSS и скрипт задерживаются, но дает вам большие выгоды, когда CSS задерживается. (Показано last столбцы в первом наборе результатов.)

учитывая, что ссылка на CSS last, похоже, не повредит производительности, но can обеспечить прибыль при определенных обстоятельствах,вы должны ссылаться на внешние таблицы стилей после вы ссылаетесь на внешние скрипты только в настольных браузерах если производительность старых браузеров не имеет значения. читайте дальше для мобильной ситуации.

почему?

исторически, когда браузер столкнулся с <script> тег, указывающий на внешний ресурс, браузер будет остановка синтаксический анализ HTML, получить скрипт, выполнить его, а затем продолжить синтаксический анализ HTML. Напротив, если браузер столкнулся с <link> для внешней таблицы стилей, это было бы дальше разбор HTML во время извлечения файла CSS (параллельно).

следовательно, широко повторяемый совет поставить таблицы стилей первым-они будут загружаться первыми, и первый скрипт для загрузки может быть загружен параллельно.

однако современные браузеры (включая все браузеры, которые я тестировал выше) реализовали спекулятивный парсинг, где браузер "смотрит вперед" в HTML и начинается загрузка ресурсов до скрипты скачать и выполнить.

в старых браузерах без спекулятивного разбора, размещение скриптов сначала повлияет на производительность, так как они не будут загружаться параллельно.

Поддержка Браузеров

спекулятивный синтаксический анализ был впервые реализован в: (Наряду с процентом пользователей настольных браузеров по всему миру, использующих эту версию или выше по состоянию на январь 2012 года)

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

в общей сложности, примерно 85% настольных браузеров, используемых сегодня, поддерживают спекулятивную загрузку. Размещение скриптов перед CSS будет иметь штраф за производительность на 15% пользователей ; YMMV на основе конкретной аудитории вашего сайта. (И помните, что число сокращается.)

в мобильных браузерах это немного сложнее получить окончательные номера просто из-за того, насколько неоднороден мобильный браузер и ландшафт ОС. Поскольку спекулятивный рендеринг был реализован в WebKit 525 (выпущен Mar 2008), и почти каждый стоящий мобильный браузер основан на WebKit, мы можем сделать вывод, что "большинство" мобильных браузеров должны поддержать его. Согласно quirksmode, iOS 2.2 / Android 1.0 используйте WebKit 525. Я понятия не имею, как выглядит Windows Phone как.

однако, я запустил тест на своем устройстве Android 4, и хотя я видел цифры, похожие на результаты рабочего стола, я подключил его к фантастическому новому удаленный отладчик в Chrome для Android, а вкладка Network показала, что браузер на самом деле ждет, чтобы загрузить CSS, пока JavaScripts не будут полностью загружены – другими словами,даже новейшая версия WebKit для Android не поддерживает спекулятивный анализ. I подозреваю, что он может быть отключен из-за ограничений процессора, памяти и/или сети, присущих мобильным устройствам.

код

простите за небрежность-это был 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>

есть две основные причины поставить CSS перед JavaScript.

  1. старые браузеры (Internet Explorer 6-7, Firefox 2 и т. д.) будет блокировать все последующие загрузки, когда они начали загрузку сценария. Так что если у вас есть a.js следовал по b.css они загружаются последовательно: сначала a, затем b. Если у вас есть b.css затем a.js они загружаются параллельно, поэтому страница загружается быстрее.

  2. ничего не отображается, пока все таблицы стилей загружаются-это верно во всех браузерах. Скрипты разные-они блокируют рендеринг всех элементов DOM, которые являются ниже тега на странице. Если вы помещаете свои скрипты в голову, это означает, что вся страница блокируется от рендеринга до тех пор, пока не будут загружены все таблицы стилей и все скрипты. Хотя имеет смысл блокировать весь рендеринг для таблиц стилей (так что вы получаете правильный стиль в первый раз и избегаете вспышки неустановленного содержимого FOUC), это не имеет смысл блокировать рендеринг всей страницы для скриптов. Часто сценарии не влияют ни на какие элементы DOM или только на часть элементов DOM. лучше всего загружать скрипты как можно ниже на странице или даже лучше загружать их асинхронно.

это весело, чтобы создать примеры с Cuzillion. Например, на этой странице имеет скрипт в голове, поэтому вся страница пуста, пока не будет завершена загрузка. Однако, если мы двинемся сценарий до конца блока BODY заголовок страницы отображается, так как эти элементы DOM находятся над тегом SCRIPT, как вы можете видеть на на этой странице.


Я бы не стал слишком подчеркивать результаты, которые вы получили, я считаю, что это субъективно, но у меня есть причина объяснить вам, что лучше поставить CSS перед js.

во время загрузки вашего сайта, существует два сценария, которые вы увидите:

случай 1: белый экран > нестилизованный сайт > стилизованный сайт > взаимодействие > стиле и интерактивный сайт

Случай 2: белый экран > неустановленный веб-сайт > взаимодействие > стиль веб-сайт > стильный и интерактивный веб-сайт


Честно говоря, я не могу представить, чтобы кто-то выбрал случай 2. Это означало бы, что посетители, использующие медленные интернет-соединения, столкнутся с неустановленным сайтом, который позволяет им взаимодействовать с ним с помощью Javascript (поскольку он уже загружен). Кроме того, количество времени, потраченного на просмотр неустановленного веб-сайта, будет максимизировано таким образом. Зачем кому-то это нужно?

Он также работает лучше, так как в jQuery государства

" при использовании скриптов, которые полагаются на значение свойств стиля CSS, важно ссылаться на внешние таблицы стилей или встраивать стиль элементы перед ссылками на Скрипты".

когда файлы загружаются в неправильном порядке (сначала JS, затем CSS), любой код Javascript, полагающийся на свойства, установленные в файлах CSS (например, ширина или высота div), не будет загружен правильно. Кажется, что с неправильным порядком загрузки, правильные свойства "иногда" известны Javascript (возможно, это вызвано состоянием гонки?). Этот эффект кажется больше или меньше, в зависимости от используемого браузера.


были ли ваши тесты выполнены на вашем персональном компьютере или на веб-сервере? Это пустая страница или сложная онлайн-система с изображениями, базами данных и т. д.? Ваши скрипты выполняют простое действие события наведения или они являются основным компонентом того, как ваш сайт отображает и взаимодействует с пользователем? Есть несколько вещей, чтобы рассмотреть здесь, и актуальность этих рекомендаций почти всегда становятся правилами, когда вы рискуете в высококвалифицированных веб развитие.

цель правила "поместить таблицы стилей вверху и сценарии внизу" заключается в том, что, в общем, это лучший способ достичь оптимального прогрессивный рендеринг, что имеет решающее значение для пользовательского опыта.

все остальное в сторону: предполагая, что ваш тест действителен, и вы действительно производите результаты, противоречащие популярным правилам, это не удивительно. Каждый веб-сайт (и все, что нужно, чтобы все это появилось на экране пользователя) отличается и Интернет постоянно развивается.


Я включаю CSS-файлы перед Javascript по другой причине.

Если мой Javascript должен сделать динамический размер некоторого элемента страницы (для тех угловых случаев, когда CSS действительно является основным в задней части), то загрузка CSS после JS может привести к условиям гонки, где элемент изменяется до применения стилей CSS и, таким образом, выглядит странно, когда стили, наконец, удар. Если я загружу CSS заранее, я могу гарантировать, что все будет работать в намеченном порядке и что окончательный макет-это то, что я хочу.


является ли рекомендация включить CSS перед JavaScript недействительной?

нет, если вы относитесь к нему просто как к рекомендации. Но если вы относитесь к этому как к жесткому и быстрому правилу? да, он недействителен.

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

таблица стилей загружает выполнение сценария блока, поэтому, если у вас есть <script> после <link rel="stylesheet" ...> страница не закончу разбор - а DOMContentLoaded не будет стрелять-пока не загрузится таблица стилей.

похоже, вам нужно знать, на что опирается каждый скрипт, и убедиться, что выполнение скрипта откладывается до момента правильного события завершения. Если сценарий полагается только на DOM, он может возобновиться в ondomready/domcontentloaded, если он полагается на загружаемые изображения или таблицы стилей, которые будут применены, то, если я правильно прочитал приведенную выше ссылку, этот код должен быть отложен до события onload.

I не думайте, что один размер носка подходит всем, хотя именно так они продаются, и я знаю, что один размер обуви не подходит всем. Я не думаю, что есть окончательный ответ, на который нужно сначала загрузить стили или сценарий. Это скорее случай за случаем решение о том, что должно быть загружено в каком порядке и что может быть отложено на потом как не находящееся на "критическом пути".

поговорить с наблюдателем, который прокомментировал, что лучше отложить способность пользователей взаимодействовать до листа красивая. Вас много, и вы раздражаете своих коллег, которые чувствуют обратное. Они пришли на сайт, чтобы выполнить цель, и задержки в их способности взаимодействовать с сайтом, ожидая вещей, которые не имеют значения, чтобы закончить загрузку, очень расстраивают. Я не говорю, что вы неправы, просто вы должны знать, что существует другая фракция, которая не разделяет ваш приоритет.

этот вопрос особенно относится ко всем объявлениям размещенных на веб-сайтах. Мне бы хотелось, чтобы авторы сайта отображали только заполнители для рекламного контента и убеждались, что их сайт загружен и интерактивен, прежде чем вводить объявления в событие onload. Даже тогда я хотел бы, чтобы объявления загружались последовательно, а не все сразу, потому что они влияют на мою способность даже прокручивать содержимое сайта во время загрузки раздутых объявлений. Но это только одна точка зрения.

  • знайте своих пользователей и то, что они значение.
  • знайте своих пользователей и какую среду просмотра они используют.
  • знайте, что делает каждый файл, и каковы его предпосылки. Заставить все работать будет иметь приоритет над скоростью и довольно.
  • используйте инструменты, которые показывают вам линию сетевого времени при разработке.
  • тест в каждой из сред, которые используют пользователи. Может потребоваться динамически (на стороне сервера, при создании страницы) изменять порядок загрузки на основе пользователей окружающая среда.
  • когда вы сомневаетесь, измените порядок и снова измерьте.
  • возможно, что смешивание стилей и скриптов в порядке загрузки будет оптимальным; не все из одного, а все остальные.
  • экспериментируйте не только в каком порядке загружать файлы, но и где. Голова? В Теле? После Тела? Дом готов / заряжен? Заряжен?
  • рассмотрите варианты асинхронности и отсрочки, когда это необходимо, чтобы уменьшить сетевую задержку, которую пользователь будет испытывать, прежде чем сможет взаимодействие со страницей. Проверьте, помогают ли они или вредят.
  • всегда будут компромиссы, которые следует учитывать при оценке оптимального порядка загрузки. Красивые и отзывчивые быть только один.

обновление 2017-12-16

Я не был уверен в тестах в OP. Я решил немного поэкспериментировать и в итоге разрушил некоторые мифы.

синхронно <script src...> будет блокировать загрузку ресурсов ниже, пока он не будет загружен и выполнен

это уже не правда. Посмотрите на водопад, созданный 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> не будет блокировать загрузку и выполнение скрипты под ним

это некорректно. Таблица стилей не будет блокировать загрузку, но это будет блокировать выполнение скрипта (небольшое пояснение здесь). Посмотрите на диаграмму производительности хром 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


имея в виду вышеизложенное, результаты в OP можно объяснить следующим образом:

CSS сначала:

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

JS первый:

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

Я не совсем уверен,как ваше время "рендеринга" тестирования в качестве сценария java. Однако рассмотрим это

одна страница на вашем сайте-50k, что не является необоснованным. Пользователь находится на восточном побережье, а ваш сервер-на западном. MTU определенно не 10k, поэтому будет несколько поездок туда и обратно. Это может занять 1/2 секунды, чтобы получить вашу страницу и стилей. Как правило (для меня) javascript (через плагин jquery и такие) намного больше, чем CSS. Там же, что происходит, когда ваше интернет-соединение задыхается на полпути на странице, но позволяет игнорировать это (это случается со мной иногда, и я считаю, что css визуализирует, но я не уверен на 100%).

поскольку css находится в голове, могут быть дополнительные соединения, чтобы получить его, что означает, что он потенциально может закончить до страницы. В любом случае во время типа остальная часть страницы занимает и файлы javascript (что намного больше байтов) страница не отображается, что делает сайт / соединение медленный.

даже если интерпретатор JS отказывается запускаться, пока CSS не будет сделано время, необходимое для загрузки кода javascript, особенно когда далеко от сервера сокращается время css, что сделает сайт выглядеть не очень красиво.

его небольшая оптимизация, но это причина для этого.


здесь резюме из всех основных ответов выше (или, возможно, ниже позже :)

для современных браузеров, поместите css, где вам нравится. Они будут анализировать ваш HTML-файл (который они называют спекулятивный парсинг) и начать загрузку css параллельно с синтаксическим анализом html.

для старых браузеров продолжайте ставить css сверху (если вы не хотите сначала показывать голую, но интерактивную страницу).

для всех браузеров поместите javascript как можно дальше вниз на странице, насколько это возможно, так как он остановит синтаксический анализ вашего html. Предпочтительно загрузить его асинхронно (т. е. вызов ajax)

есть также некоторые экспериментальные результаты для конкретного случая, который утверждает, что сначала javascript (в отличие от традиционной мудрости первого CSS) дает лучшую производительность, но для него нет логических рассуждений и не хватает проверки в отношении широкой применимости, поэтому вы можете игнорировать его сейчас.

Итак, чтобы ответить на вопрос: Да. Рекомендация включить CSS перед JS недопустима для современных браузеров. Поместите CSS, где хотите, и поместите JS в конец, насколько это возможно.


Стив Содерс уже дал окончательный ответ, но...

интересно, есть ли проблема как с оригинальным тестом Сэма, так и с повторением его Джошем.

оба теста, по-видимому, были выполнены на соединениях с низкой задержкой, где настройка TCP-соединения будет иметь тривиальную стоимость.

Как это влияет на результат теста, я не уверен, и я хотел бы посмотреть на водопады для тестов по "нормальному" латентному соединению но...

первый загруженный файл должны получите соединение, используемое для html-страницы, и второй загруженный файл получит новое соединение. (Промывка ранних изменений этой динамики, но это не делается здесь)

в новых браузерах второе TCP-соединение открывается спекулятивно, поэтому накладные расходы на соединение уменьшаются / исчезают, в старых браузерах это не так, и второе соединение будет иметь накладные расходы открытый.

вполне как/если это влияет на результат тестов, я не уверен.


Я думаю, это не будет верно для всех случаев. Потому что css будет загружать параллельные, но js не может. Рассмотрим для того же случая,

вместо того, чтобы иметь один css, возьмите 2 или 3 css-файла и попробуйте эти способы,

1) в CSS..стиль CSS..Яш 2) в CSS..js..стиль CSS 3) в JS..стиль CSS..в CSS

Я уверен, что css..стиль CSS..Яш даст лучший результат, чем все остальные.


мы должны иметь в виду, что новые браузеры работали над своими движками Javascript, их синтаксическими анализаторами и т. д., оптимизируя общие проблемы кода и разметки таким образом, что проблемы, испытываемые в древних браузерах, таких как


лично Я бы не стал делать слишком большой акцент на такой "народной мудрости".- То, что было правдой в прошлом, может оказаться неправдой и сейчас. Я бы предположил, что все операции, связанные с интерпретацией и рендерингом веб-страницы, полностью асинхронны ("извлечение "чего-то и" действие на него " - это две совершенно разные вещи, которые могут обрабатываться разными потоками, etc.), и в любом случае полностью вне вашего контроля или беспокойство.

Я бы поместил ссылки CSS в" головную " часть документа вместе с любыми ссылками на внешние скрипты. (Некоторые сценарии могут потребовать, чтобы их поместили в тело, и если да, то обязать их.)

дальше ... если вы заметили, что "это кажется быстрее / медленнее, чем это, в этом/этом браузере", рассматривайте это наблюдение как интересное, но не относящееся к делу любопытство и не позволяйте ему влиять на ваши дизайнерские решения. Слишком многое меняется слишком быстро. (кто-нибудь хочет сделать ставки на сколько минут это будет до того, как команда Firefox выйдет с еще одним промежуточным выпуском своего продукта? Да, я тоже.)