Ads
Comments 49
+6
странный вопрос. относительно чего? сферической страницы в вакууме?
+7
Я думаю, было бы очень логично протестировать несколько вариантов разных страниц. А как еще по вашему тесты делают?
-8
вы как раз о сферических страницах в вакууме? параллельную загрузку скриптов делают не чтобы какую-то мифическую «производительность» повышать, а чтобы визуально ускорить для пользователя отклик. пользователь просто не будет видеть задержки, которая происходит при загрузке скриптов, как будто их просто нет.
+1
Можно с реальными страницами крупных сервисов тест произвести
0
Я думаю, вы ни к чему спорите. Тесты почти всегда синтетические
-3
я думаю, вы высасываете необходимость тестов из пальца. нечего там тестировать.
+1
1) посмотрите как-нибудь на досуге, как устроена статика на фейсбуке. потом на гугле. удачного тестирования.

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

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

Существует несколько решений, как то:
— поместить стили и скрипты прямо в страницу;
— установка аттрибутов async/defer тегу script;
— склеить все скрипты в один файл;
— помесить ссылки на скрипты в конец body;
— разместить все файлы на CDN/на разных хостах;
-3
см. комментарий выше. это всё ускоряет отклик страницы, а не производительность. а фактический коэффициент ускорения отклика уже будет зависеть от канала пользователя. это ускорение не надо мерить. надо просто чтобы для него было сделано всё возможное.
+2
Хотя бы относительно страницы, которую тстировал автор, при виде которой «огонь потух в глазах»
-4
[irony]как много информации-то о yepnope[/irony]

1.6кб для того, чтобы сделать <script>document.write('<script src=«app.js»></script>')</script>?
и да, я понимаю, что бывают случаи сложнее. но кода там максимум строк на 40 будет.
0
На хабре не так давно был перевод статьи о неблокируемой загрузке данных в страницу: там все не так просто. Я уже точно не помню, но, например, некоторые браузеры, не позволяют вести параллельная загрузку более чем, скажем, 5ти скриптов. Следовательно загрузчик должен уметь это решать.
0
имхо, если вам надо загружать более, чем 5 скриптов одновременно асинхронно, и вам важно, что они грузятся не параллельно, то вы делаете что-то не так.
+8
Я ещё раскидываю скрипты, стили, картинки и т.д. по разным поддоменам, чтобы увеличить количество одновременных соединений.
+5
Не знаю почему минусуют, но этот приём даёт очень заметный эффект, к примеру, при загрузке карт, состоящих из десятков или сотен фрагментов.
0
Этого я не заметил, я заметил только "— разместить все файлы на CDN/на разных хостах;". Суть того, что предлагает B_Vladi — не использование разных хостов, а обман браузера созданием алиасов одному и тому же хосту.
0
Именно. Тем более это легко реализуется в nginx или .htaccess.
Моё мнение такое, что всё нужно применять в комплексе и учитывать это с самого начала разработки. Только так будет высокий результат.
0
С самого начала не обязательно, а вот перед выходом в продуктивный режим и перед ожиданием хабраэффекта это необходимо. С самого начала нужно накидать весь минимальный функционал.
0
Ага, это очень ускорит загрузку на медленном одноканальном мобильном соединении =)
0
Некоторое время использовал $.include.

Сейчас хватает чуть модифицированного $.getScript:
$.getScript = function(url, callback, cache){
	$.ajax({
		type: 'GET',
		url: url,
		success: callback,
		dataType: 'script',
		cache: cache || true
	});
};

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

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

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

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

Стили сжимаю в один файл, спрайты создаются автоматом при выкладке в эфир. Работает на ура.
0
1) Чем делаются спрайты (своя разработка/стороняя)?
2) Какой алгоритм при принятии решения об объединении картинок в один спрайт (ручное задание/автоматические на основании размеров картинки/автоматическое на основании формата/прочее)?
3) Генератор спрайтов CSS сам меняет?
+2
1,3: Используется стандартная библиотека css-парсер Tidy, а затем работает разработанный мной алгоритм создания спрайтов, при этом получается css-файл с изменёнными смещениями (входные картинки можно использовать даже спрайты, там простая арифметика =) )

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

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

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

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

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


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


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

+2
Да, всё же насчёт 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 к тому моменту уже тоже готов)
  });
});

+1
Наверное, следует упомянуть о баге в yepnope, из-за которого «загрузка» скриптов может существенно замедлится в случае, если вы используете complete callback (Замедлится не загрузка скрипта, а время отклика — complete всё время будет вызываться с задержкой 10с). Это справедливо для всех современных браузеров кроме IE9.
Only those users with full accounts are able to leave comments.  , please.