Comments 49
И каково увеличение производительности?
странный вопрос. относительно чего? сферической страницы в вакууме?
Я думаю, было бы очень логично протестировать несколько вариантов разных страниц. А как еще по вашему тесты делают?
вы как раз о сферических страницах в вакууме? параллельную загрузку скриптов делают не чтобы какую-то мифическую «производительность» повышать, а чтобы визуально ускорить для пользователя отклик. пользователь просто не будет видеть задержки, которая происходит при загрузке скриптов, как будто их просто нет.
Можно с реальными страницами крупных сервисов тест произвести
Я думаю, вы ни к чему спорите. Тесты почти всегда синтетические
1) посмотрите как-нибудь на досуге, как устроена статика на фейсбуке. потом на гугле. удачного тестирования.
2) конкретный коэффициент ускорения зависит количества скриптов, их размера, их взаимозависимостей, группировки, и в конце концов, канала пользователя. замерьте две страницы, или двадцать две, это не будет иметь никакого значения. каждая страница будет иметь свой показатель, вы увидите закономерности только на очень похожих страницах.
2) конкретный коэффициент ускорения зависит количества скриптов, их размера, их взаимозависимостей, группировки, и в конце концов, канала пользователя. замерьте две страницы, или двадцать две, это не будет иметь никакого значения. каждая страница будет иметь свой показатель, вы увидите закономерности только на очень похожих страницах.
Тестирование (проверка теории на практике) — обязательное условие жизнеспособности решения.
Мало того, предлагаются к рассмотрению различные варианты организации одной и той же страницы! Одной и той же, улавливаете? Сравнить тут разницу сам бог велел. Ну и еще он был бы просто рад, сравнительной диаграмме на различных примерах страниц.
Мало того, предлагаются к рассмотрению различные варианты организации одной и той же страницы! Одной и той же, улавливаете? Сравнить тут разницу сам бог велел. Ну и еще он был бы просто рад, сравнительной диаграмме на различных примерах страниц.
как я люблю хабр за то, что люди здесь выучивают кучу умных предложений и не вникают в их смысл.
не забудьте перед этим сравнить производительность страницы со скриптами в ней и вынесенными в отдельные файлы. потом потестируйте разницу между стилями в отдельных файлах, и прописанных прямо в тегах. а потом ещё круглый камень в сопку потолкайте.
не забудьте перед этим сравнить производительность страницы со скриптами в ней и вынесенными в отдельные файлы. потом потестируйте разницу между стилями в отдельных файлах, и прописанных прямо в тегах. а потом ещё круглый камень в сопку потолкайте.
Относительного этого:
Существует несколько решений, как то:
— поместить стили и скрипты прямо в страницу;
— установка аттрибутов async/defer тегу script;
— склеить все скрипты в один файл;
— помесить ссылки на скрипты в конец body;
— разместить все файлы на CDN/на разных хостах;
Хотя бы относительно страницы, которую тстировал автор, при виде которой «огонь потух в глазах»
[irony]как много информации-то о yepnope[/irony]
1.6кб для того, чтобы сделать <script>document.write('<script src=«app.js»></script>')</script>?
и да, я понимаю, что бывают случаи сложнее. но кода там максимум строк на 40 будет.
1.6кб для того, чтобы сделать <script>document.write('<script src=«app.js»></script>')</script>?
и да, я понимаю, что бывают случаи сложнее. но кода там максимум строк на 40 будет.
На хабре не так давно был перевод статьи о неблокируемой загрузке данных в страницу: там все не так просто. Я уже точно не помню, но, например, некоторые браузеры, не позволяют вести параллельная загрузку более чем, скажем, 5ти скриптов. Следовательно загрузчик должен уметь это решать.
имхо, если вам надо загружать более, чем 5 скриптов одновременно асинхронно, и вам важно, что они грузятся не параллельно, то вы делаете что-то не так.
чтобы не быть голословным, пример на коффи:
github.com/roundlake/joosy-rails/blob/master/vendor/assets/javascripts/joosy/preloader/development.js.coffee
github.com/roundlake/joosy-rails/blob/master/vendor/assets/javascripts/joosy/preloader/development.js.coffee
Все время вспоминаю эту табличку — spreadsheets.google.com/lv?key=tDdcrv9wNQRCNCRCflWxhYQ, когда читаю про загрузку скриптов.
Я ещё раскидываю скрипты, стили, картинки и т.д. по разным поддоменам, чтобы увеличить количество одновременных соединений.
Не знаю почему минусуют, но этот приём даёт очень заметный эффект, к примеру, при загрузке карт, состоящих из десятков или сотен фрагментов.
Это есть в топике (загрузка с разных доменов), почёрпнуто из известного источника.
Этого я не заметил, я заметил только "— разместить все файлы на CDN/на разных хостах;". Суть того, что предлагает B_Vladi — не использование разных хостов, а обман браузера созданием алиасов одному и тому же хосту.
Ага, это очень ускорит загрузку на медленном одноканальном мобильном соединении =)
Некоторое время использовал $.include.
Сейчас хватает чуть модифицированного $.getScript:
Сейчас хватает чуть модифицированного $.getScript:
$.getScript = function(url, callback, cache){
$.ajax({
type: 'GET',
url: url,
success: callback,
dataType: 'script',
cache: cache || true
});
};Это здорово, но к тому моменту уже должен быть загружен jQuery, а это ожидание загрузки одного из самых больших скриптов.
А что будет, если вызвать так? :)
$.getScript(myUrl, myCallback, FALSE);
Использую один файл в конце body, а социальное барахло грузится только после загрузки всей страницы после события ready. Результат — страница грузится и отображается мгновенно, а уже потом выполняются скрипты и добавляют функционал. Работает на ура.
Стили сжимаю в один файл, спрайты создаются автоматом при выкладке в эфир. Работает на ура.
Стили сжимаю в один файл, спрайты создаются автоматом при выкладке в эфир. Работает на ура.
1) Чем делаются спрайты (своя разработка/стороняя)?
2) Какой алгоритм при принятии решения об объединении картинок в один спрайт (ручное задание/автоматические на основании размеров картинки/автоматическое на основании формата/прочее)?
3) Генератор спрайтов CSS сам меняет?
2) Какой алгоритм при принятии решения об объединении картинок в один спрайт (ручное задание/автоматические на основании размеров картинки/автоматическое на основании формата/прочее)?
3) Генератор спрайтов CSS сам меняет?
1,3: Используется стандартная библиотека css-парсер Tidy, а затем работает разработанный мной алгоритм создания спрайтов, при этом получается css-файл с изменёнными смещениями (входные картинки можно использовать даже спрайты, там простая арифметика =) )
2: Есть два режима — авто и ручной. Авто — проверка на изменение даты css-файлов. В отдельном каталоге создаются нулевого размера «зеркала» файлов (типа для хранения даты), потом сравниваются.
2: Есть два режима — авто и ручной. Авто — проверка на изменение даты css-файлов. В отдельном каталоге создаются нулевого размера «зеркала» файлов (типа для хранения даты), потом сравниваются.
Не поделитесь инструментом с нами? =)
А Compass'а уже не хватает?
Вот здесь тесты: http://headjs.com/#theory
Исходя из своего опыта скажу, что асинхронная подгрузка скриптов действительно визуально ускоряет загрузку страницы, но:
Эффект действительно заметен только на старых браузерах и ie. В современных браузерах, при тестировании я нередко получал обратный эффект (правда очень мизерный).
Если у вас на странице контент, оформление которого зависит от скрипта (чего конечно в идеале нельзя допускать), например слайдер или меню, то при загрузке страница может на мгновение предстать в недооформленном виде.
$(function(){ }); и всякие подобные «документ реди», вызванные инлайн скриптом на загружаемой странице, перестают работать. Так как скрипты подгружаются асинхронно со страницей, то страница может загрузиться до полной загрузки всех скриптов и некоторые функции и переменные могут быть ещё не определены, что взовет ошибку. Надо вызов кода помещать в дополнительную колбек функцию. Например, в случае head.js:
Исходя из своего опыта скажу, что асинхронная подгрузка скриптов действительно визуально ускоряет загрузку страницы, но:
Эффект действительно заметен только на старых браузерах и ie. В современных браузерах, при тестировании я нередко получал обратный эффект (правда очень мизерный).
Если у вас на странице контент, оформление которого зависит от скрипта (чего конечно в идеале нельзя допускать), например слайдер или меню, то при загрузке страница может на мгновение предстать в недооформленном виде.
$(function(){ }); и всякие подобные «документ реди», вызванные инлайн скриптом на загружаемой странице, перестают работать. Так как скрипты подгружаются асинхронно со страницей, то страница может загрузиться до полной загрузки всех скриптов и некоторые функции и переменные могут быть ещё не определены, что взовет ошибку. Надо вызов кода помещать в дополнительную колбек функцию. Например, в случае head.js:
$(function(){
head.ready(
function() {
/*code*/
})
});
Простите, а $ откуда? Похоже, что jQuery грузится не HeadJS'ом, и это печально.
Логичнее бы было так:
Логичнее бы было так:
head.js("jquery.js");
head.ready("jquery.js", function() {
// и $(function(){}) уже не нужен, этот код будет вызван, когда готова страница И jquery
});
Да, правильно
Возможно я ошибаюсь, но если «jquery.js» загрузится до события «DOM ready» возможна ошибка.
Думаю, всё же $(function(){}); стоит оставить.
Думаю, всё же $(function(){}); стоит оставить.
Какого рода ошибка?
Метод, переданный параметром к head.ready будет исполнен только после наступления dom ready. Двойная проверка не нужна. А вот в случае, если инлайновый скрипт загрузится и выполнится до того, как будет загружен jQuery, и соответственно определён $, будет ошибка, говорящая о том, что $ не определён. И единственный способ её избежать — поставить script src=«jquery.js» в head, что задержит начальное отображение страницы на время, необходимое для загрузки и исполнения jquery.js, с чем мы в этом топике как раз и пытаемся бороться.
head.ready делает ровно то же, что и $() — выполняет переданную ему функцию как только выстрелит dom ready. вкладывать одну проверку в другую — смысла нет. Равно как и ждать загрузки для этой цели 50КБ+ скрипта вместо ~3КБ (для head.js и т.п.).
Метод, переданный параметром к head.ready будет исполнен только после наступления dom ready. Двойная проверка не нужна. А вот в случае, если инлайновый скрипт загрузится и выполнится до того, как будет загружен jQuery, и соответственно определён $, будет ошибка, говорящая о том, что $ не определён. И единственный способ её избежать — поставить script src=«jquery.js» в head, что задержит начальное отображение страницы на время, необходимое для загрузки и исполнения jquery.js, с чем мы в этом топике как раз и пытаемся бороться.
head.ready делает ровно то же, что и $() — выполняет переданную ему функцию как только выстрелит dom ready. вкладывать одну проверку в другую — смысла нет. Равно как и ждать загрузки для этой цели 50КБ+ скрипта вместо ~3КБ (для head.js и т.п.).
Если метод, переданный параметром к head.ready будет исполнен только после наступления dom ready, то вы конечно правы (двойная проверка будет излишней).
Да, всё же насчёт 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 к тому моменту уже тоже готов)
});
});
Наверное, следует упомянуть о баге в yepnope, из-за которого «загрузка» скриптов может существенно замедлится в случае, если вы используете complete callback (Замедлится не загрузка скрипта, а время отклика — complete всё время будет вызываться с задержкой 10с). Это справедливо для всех современных браузеров кроме IE9.
Sign up to leave a comment.
Параллельная загрузка JavaScript и CSS без блокирования парсинга страницы