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

[leMar]

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

[GearHead]

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

[nick4fake]

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

[GearHead]

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

[nick4fake]

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

[nick4fake]

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

[GearHead]

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

[GearHead]

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

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

[MaxF]

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

[GearHead]

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

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

[leMar]

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

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

[GearHead]

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

[dmitriid]

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

[GearHead]

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

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

[Omgovich]

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

[GearHead]

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

[GearHead]

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

[sHinE]

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

[Romanych]

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

[B_Vladi]

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

[Pilat]

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

[philpirj]

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

[Pilat]

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

[B_Vladi]

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

[philpirj]

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

[B_Vladi]

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

[Methos]

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

[G_Z]

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

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

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

[philpirj]

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

[G_Z]

Именно.

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

[philpirj]

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

[safron]

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

$.getScript(myUrl, myCallback, FALSE);


[G_Z]

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

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

[safron]

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

cache: cache || true


[G_Z]

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

[Methos]

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

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

[alekciy]

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

[Methos]

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

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

[B_Vladi]

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

[philpirj]

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

[Methos]

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

[koteus]

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

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

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

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

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

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

[philpirj]

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

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

[koteus]

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

[koteus]

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

[philpirj]

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

[koteus]

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

[philpirj]

Да, всё же насчёт 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]

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