Верно, нас интересует даже не время начальной загрузки, а время поступления запроса «Request sent», но тогда благодаря механизму pre-loader, который еще в 2008 году реализован на Internet Explorer, WebKit and Mozilla, как указано в Вашей статье имеем:
When the browser is blocked on a script, a second lightweight parser scans the rest of the markup looking for other resources e.g. stylesheets, scripts, images etc., that also need to be retrieved.
The pre-loader then starts retrieving these resources in the background with the aim that by the time the main HTML parser reaches them they may have already been downloaded and so reduce blocking later in the page.
Т.е. прелоадер в фоновом режиме уже подгрузит остальные компоненты сайта, в т.ч. и скрипты. Получается, что ориентироваться на начало Request sent нет смысла и остается только панель Timeline, как Вы правильно меня поправили, с временем начала выполнения каждого из скриптов.
Точнее, не время ожидания (зеленая шкала), а время начала загрузки контента (синяя). Если посмотреть на второе изображение Вашего поста, там видно, что синие шкалы легенды не пересекаются.
Давайте сначала рассмотрим, в чем заключается проблема с загрузкой скриптов. Все заключается в том, что браузер не может сказать, что находится внутри скрипта, не загрузив его полностью. Скрипт может содержать вызовы document.write(), которые изменяют DOM-дерево, или вообще location.href, что отправит пользователя на другую страницу. В последнем случае все компоненты, загруженные на предыдущей странице, могут оказаться ненужными. Чтобы предотвратить загрузки, которые могут оказаться лишними, браузеры сначала загружают, затем анализируют и исполняют каждый скрипт перед тем, как переходить к следующему файлу в очереди на загрузку. В результате каждый вызов скрипта на вашей странице блокирует процесс загрузки и оказывает негативное влияние на скорость загрузки.
В отличие от CSS, т.е. от приостановки вывода страницы.
Учтите, что под блокировкой подразумевается только приостановка вывода страницы. При этом браузер скачивает все CSS-файлы независимо от того, блокируют они вывод или нет. Приоритет скачивания выше у тех файлов, без которых вывод страницы невозможен.
Вывод: «блокировка» в контексте CSS, что на самом деле означает не блокировка, а «приостановка вывода страницы», не одно и тоже, что «блокировка дальнейшей обработки» в контексте JS.
«Вот такая загагулина.»
Должен быть только один удаленный JS-файл и один удаленный CSS-файл.
Бытует мнение, что желательно размещать, к примеру, такие вещи как jQuery и Bootstrap компоненты на удаленных CDN серверах для ускорения загрузки страниц сайта.
В этом случае оптимальнее их разместить на CDN или перетащить к себе на сервер?
Взяться не готов, но идея не плохая и пользовалась бы большей популярностью, если в дополнение к тексту позволяла бы публиковать и графическую информацию, правда это повлечет увеличение накладных расходов.
Для интересующихся:
Посетителей в день: 3700 (http://ru.myip.ms/),
IP НЕТ в черном списке,
Основной язык программирования: PHP 5.3.3, jQuery 1.4.2 (Wappalyzer)
Т.е. прелоадер в фоновом режиме уже подгрузит остальные компоненты сайта, в т.ч. и скрипты. Получается, что ориентироваться на начало Request sent нет смысла и остается только панель Timeline, как Вы правильно меня поправили, с временем начала выполнения каждого из скриптов.
В отличие от CSS, т.е. от приостановки вывода страницы.
От туда-же
Вывод: «блокировка» в контексте CSS, что на самом деле означает не блокировка, а «приостановка вывода страницы», не одно и тоже, что «блокировка дальнейшей обработки» в контексте JS.
«Вот такая загагулина.»
Бытует мнение, что желательно размещать, к примеру, такие вещи как jQuery и Bootstrap компоненты на удаленных CDN серверах для ускорения загрузки страниц сайта.
В этом случае оптимальнее их разместить на CDN или перетащить к себе на сервер?
Для интересующихся:
Посетителей в день: 3700 (http://ru.myip.ms/),
IP НЕТ в черном списке,
Основной язык программирования: PHP 5.3.3, jQuery 1.4.2 (Wappalyzer)