philpirj Jan 7 2012 at 15:14

Параллельная загрузка JavaScript и CSS без блокирования парсинга страницы

5 min

67K

Website development*

+84

Comments 49

leMar Jan 7 2012 at 16:06

И каково увеличение производительности?

GearHead Jan 7 2012 at 16:12

странный вопрос. относительно чего? сферической страницы в вакууме?

nick4fake Jan 7 2012 at 17:36

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

GearHead Jan 7 2012 at 17:54

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

nick4fake Jan 7 2012 at 18:22

Можно с реальными страницами крупных сервисов тест произвести

nick4fake Jan 7 2012 at 18:23

Я думаю, вы ни к чему спорите. Тесты почти всегда синтетические

GearHead Jan 7 2012 at 18:31

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

GearHead Jan 7 2012 at 18:31

1) посмотрите как-нибудь на досуге, как устроена статика на фейсбуке. потом на гугле. удачного тестирования.

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

MaxF Jan 8 2012 at 13:21

Тестирование (проверка теории на практике) — обязательное условие жизнеспособности решения.
Мало того, предлагаются к рассмотрению различные варианты организации одной и той же страницы! Одной и той же, улавливаете? Сравнить тут разницу сам бог велел. Ну и еще он был бы просто рад, сравнительной диаграмме на различных примерах страниц.

GearHead Jan 8 2012 at 13:37

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

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

leMar Jan 7 2012 at 18:17

Относительного этого:

Существует несколько решений, как то:
— поместить стили и скрипты прямо в страницу;
— установка аттрибутов async/defer тегу script;
— склеить все скрипты в один файл;
— помесить ссылки на скрипты в конец body;
— разместить все файлы на CDN/на разных хостах;

GearHead Jan 7 2012 at 18:23

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

dmitriid Jan 7 2012 at 21:38

Хотя бы относительно страницы, которую тстировал автор, при виде которой «огонь потух в глазах»

GearHead Jan 7 2012 at 16:10

[irony]как много информации-то о yepnope[/irony]

1.6кб для того, чтобы сделать <script>document.write('<script src=«app.js»></script>')</script>?
и да, я понимаю, что бывают случаи сложнее. но кода там максимум строк на 40 будет.

Omgovich Jan 7 2012 at 17:03

На хабре не так давно был перевод статьи о неблокируемой загрузке данных в страницу: там все не так просто. Я уже точно не помню, но, например, некоторые браузеры, не позволяют вести параллельная загрузку более чем, скажем, 5ти скриптов. Следовательно загрузчик должен уметь это решать.

GearHead Jan 7 2012 at 17:10

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

GearHead Jan 7 2012 at 17:12

чтобы не быть голословным, пример на коффи:
github.com/roundlake/joosy-rails/blob/master/vendor/assets/javascripts/joosy/preloader/development.js.coffee

sHinE Jan 7 2012 at 17:17

Все время вспоминаю эту табличку — spreadsheets.google.com/lv?key=tDdcrv9wNQRCNCRCflWxhYQ, когда читаю про загрузку скриптов.

Romanych Jan 7 2012 at 23:42

Спасибо за ссылку. Просто отлично.

B_Vladi Jan 7 2012 at 17:41

Я ещё раскидываю скрипты, стили, картинки и т.д. по разным поддоменам, чтобы увеличить количество одновременных соединений.

Pilat Jan 7 2012 at 18:19

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

philpirj Jan 8 2012 at 10:18

Это есть в топике (загрузка с разных доменов), почёрпнуто из известного источника.

Pilat Jan 8 2012 at 14:34

Этого я не заметил, я заметил только "— разместить все файлы на CDN/на разных хостах;". Суть того, что предлагает B_Vladi — не использование разных хостов, а обман браузера созданием алиасов одному и тому же хосту.

B_Vladi Jan 8 2012 at 21:24

Именно. Тем более это легко реализуется в nginx или .htaccess.
Моё мнение такое, что всё нужно применять в комплексе и учитывать это с самого начала разработки. Только так будет высокий результат.

philpirj Jan 8 2012 at 22:00

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

B_Vladi Jan 8 2012 at 22:13

Ну да, это уже тонкости.

Methos Aug 30 2017 at 22:04

Ага, это очень ускорит загрузку на медленном одноканальном мобильном соединении =)

G_Z Jan 7 2012 at 19:01

Некоторое время использовал $.include.

Сейчас хватает чуть модифицированного $.getScript:

$.getScript = function(url, callback, cache){
	$.ajax({
		type: 'GET',
		url: url,
		success: callback,
		dataType: 'script',
		cache: cache || true
	});
};

philpirj Jan 8 2012 at 10:20

Это здорово, но к тому моменту уже должен быть загружен jQuery, а это ожидание загрузки одного из самых больших скриптов.

G_Z Jan 8 2012 at 17:56

Именно.

Загрузка jQuery → DOMReady → модификация DOM, только в таком порядке.

philpirj Aug 29 2012 at 21:14

А если нужно, чтобы к моменту загрузки jQuery уже какие-то данные подгрузились откуда-то, например, оказалось получено имя пользователя из вконтакте, иконка с граватара и список рекомендаций друзей с фейсбука? Зачем ждать загрузки эффектов?

safron Jan 9 2012 at 08:29

А что будет, если вызвать так? :)

$.getScript(myUrl, myCallback, FALSE);

G_Z Jan 9 2012 at 08:58

Ничего не будет, переменная FALSE, не определена.

Если же речь идёт о передаче false в качестве параметра, то будет работа как сейчас в jQuery по умолчанию — в адрес будет добавлен get-параметр, для отмены кэширования.

safron Jan 9 2012 at 09:02

Речь идет о передаче false в качестве параметра. В вашем примере свойство cache будет всегда установлено в true.

cache: cache || true

G_Z Jan 9 2012 at 17:51

Да, действительно, недосмотр.
Благодарю.

Methos Jan 8 2012 at 03:06

Использую один файл в конце body, а социальное барахло грузится только после загрузки всей страницы после события ready. Результат — страница грузится и отображается мгновенно, а уже потом выполняются скрипты и добавляют функционал. Работает на ура.

Стили сжимаю в один файл, спрайты создаются автоматом при выкладке в эфир. Работает на ура.

alekciy Jan 8 2012 at 17:43

1) Чем делаются спрайты (своя разработка/стороняя)?
2) Какой алгоритм при принятии решения об объединении картинок в один спрайт (ручное задание/автоматические на основании размеров картинки/автоматическое на основании формата/прочее)?
3) Генератор спрайтов CSS сам меняет?

Methos Jan 8 2012 at 20:32

1,3: Используется стандартная библиотека css-парсер Tidy, а затем работает разработанный мной алгоритм создания спрайтов, при этом получается css-файл с изменёнными смещениями (входные картинки можно использовать даже спрайты, там простая арифметика =) )

2: Есть два режима — авто и ручной. Авто — проверка на изменение даты css-файлов. В отдельном каталоге создаются нулевого размера «зеркала» файлов (типа для хранения даты), потом сравниваются.

B_Vladi Jan 8 2012 at 21:43

Не поделитесь инструментом с нами? =)

philpirj Jan 8 2012 at 21:57

А Compass'а уже не хватает?

Methos Jul 7 2012 at 14:06

Compass появился недавно, а я разрабатывал инструмент для себя в 2008 году.

koteus Jan 8 2012 at 22:02

Вот здесь тесты: http://headjs.com/#theory

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

Эффект действительно заметен только на старых браузерах и ie. В современных браузерах, при тестировании я нередко получал обратный эффект (правда очень мизерный).

Если у вас на странице контент, оформление которого зависит от скрипта (чего конечно в идеале нельзя допускать), например слайдер или меню, то при загрузке страница может на мгновение предстать в недооформленном виде.

$(function(){ }); и всякие подобные «документ реди», вызванные инлайн скриптом на загружаемой странице, перестают работать. Так как скрипты подгружаются асинхронно со страницей, то страница может загрузиться до полной загрузки всех скриптов и некоторые функции и переменные могут быть ещё не определены, что взовет ошибку. Надо вызов кода помещать в дополнительную колбек функцию. Например, в случае head.js:

$(function(){ 
    head.ready(
        function() { 
            /*code*/ 
    }) 
});

philpirj Jan 8 2012 at 23:16

Простите, а $ откуда? Похоже, что jQuery грузится не HeadJS'ом, и это печально.
Логичнее бы было так:

head.js("jquery.js");
head.ready("jquery.js", function() {
  // и $(function(){}) уже не нужен, этот код будет вызван, когда готова страница И jquery
});

koteus Jan 8 2012 at 23:46

Да, правильно

koteus Jan 8 2012 at 23:58

Возможно я ошибаюсь, но если «jquery.js» загрузится до события «DOM ready» возможна ошибка.
Думаю, всё же $(function(){}); стоит оставить.

philpirj Jan 9 2012 at 00:32

Какого рода ошибка?
Метод, переданный параметром к head.ready будет исполнен только после наступления dom ready. Двойная проверка не нужна. А вот в случае, если инлайновый скрипт загрузится и выполнится до того, как будет загружен jQuery, и соответственно определён $, будет ошибка, говорящая о том, что $ не определён. И единственный способ её избежать — поставить script src=«jquery.js» в head, что задержит начальное отображение страницы на время, необходимое для загрузки и исполнения jquery.js, с чем мы в этом топике как раз и пытаемся бороться.
head.ready делает ровно то же, что и $() — выполняет переданную ему функцию как только выстрелит dom ready. вкладывать одну проверку в другую — смысла нет. Равно как и ждать загрузки для этой цели 50КБ+ скрипта вместо ~3КБ (для head.js и т.п.).

koteus Jan 9 2012 at 01:22

Если метод, переданный параметром к head.ready будет исполнен только после наступления dom ready, то вы конечно правы (двойная проверка будет излишней).

philpirj Jan 9 2012 at 02:16

Да, всё же насчёт head.js есть тонкость, исходя из документации, а именно:

head.ready("jquery.js", function() {
  // вызывается, когда загружен и исполнен jquery.js (DOM может быть и не готов) - тут внутри уже имеет смысл использовать $(function(){...}), но никак не наоборот
});

head.ready(function() {
  // вызывается, когда готов DOM и загружены и исполнены ВСЕ скрипты, тут безопасно вызывать любые методы $, но может оказаться, что можно было безболезненно и раньше, до загрузки Google Analytics, например
});

И самый приятный и гибкий вариант:

head.ready(document, function() {
  // вызывается, когда DOM готов
  // имеет смысл поместить сюда вложенный обработчик события загрузки jQuery:
  head.ready("jquery.js", function() {
    // вызывается, когда загружен и исполнен jquery.js (и DOM к тому моменту уже тоже готов)
  });
});

termi Feb 8 2012 at 13:45

Наверное, следует упомянуть о баге в yepnope, из-за которого «загрузка» скриптов может существенно замедлится в случае, если вы используете complete callback (Замедлится не загрузка скрипта, а время отклика — complete всё время будет вызываться с задержкой 10с). Это справедливо для всех современных браузеров кроме IE9.