Как заставить скрипты грузиться до картинок?

Есть финт, делать у картинок пустые src, потому яваскриптом перетаскивать из data-*. Но это не будет работать без жабаскрипта, не будет нормально индексироваться.

И много к тебе пользователей без жабаскрипта ходит? Вообще, когда была такая необходимость, я поисковикам подсовывал картинки с нормальными src. Если есть возможность, перед рендером можно парсить контент и менять содержимое параметров в зависимости от юзерагента.

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

Есть финт, делать у картинок пустые src, потому яваскриптом перетаскивать из data-*. Но это не будет работать без жабаскрипта, не будет нормально индексироваться, что меня категорически не устраивает.

Ну пустые лучше не делать, лучше указать какую-нибудь небольшую картинку. А проблему с JS можно решить так:

<img src="placeholder.png" data-src="original_image.png" />
<noscript><img src="original_image.png" /></noscript>

Нет, не все. Для пользователей с JS можно использовать AJAX везде где только можно и предусмотреть режим без JS.

Видел где-то такую штуку. Если JS включен, то URL выглядит так:

http://web.site/#/path/to/page

http://web.site/path/to/page

Кстати да, про noscript я забыл. На паре картинок прокатило бы, но там и проблем с забитым пулом соединений не будет.

У меня немного другой случай - страница с форумными постами. В каждом аватарка + атачменты. Каждую картинку обернуть - получится совсем жесть, и очень гиморная верстка.

noscript как-то уж слишком радикально. По объему гимора будет еще больше, чем ручками зависимости скриптов навтыкать.

Может знаете какую-нибудь _современную_ альтернативу yepnope.js ? У него на прогрузке зависимостей бывают весьма странные артефакты. В свое время нашел только head.js & labs.js, но там апдейтов очень давно не было.

К сожалению не знаю.

По моему прописать noscript для аватарок и аттачей не так уж и сложно. Работы максимум на час.

Фик знает. Сделать реально, но как-то напрягает при html5 верстке втыкать такие мегакостыли по всему сайту. И потом, при отключенном js получится 2 картинки, могут случиться всякие артефакты на :before/after, border и т.п. Это наверное тоже можно дополнительным костылем пролечить, но как-то много костылей набегает.

Я не против такого метода, когда на странице пара картинок. Но затачивать его как основу всего проекта - стрёмно.

Наверное прийдется своего франкенштейна под yepnope сочинять.

В интернетах пишут, что браузер успевает забить очередь загрузки картинками, потому что получает их src немедленно (со страницы), а пока загрузчик скриптов прочухается - пул коннектов уже забит.

У <script> тоже есть src.

Отдавай картинки с другого хоста

Отдавай картинки с другого хоста

+1

а пока загрузчик скриптов прочухается - пул коннектов уже забит

ээ, а какое ограничение? стоит ли nginx для отдачи статики?

а так, если варианты сверху уже испробованы или нет желания заморачиваться с сервером, то надо реализовывать что-то типа методики lazy load - что бы картинки грузились только видимые, и когда пользователь скролит подгружаются остальные, без js тут я думаю не обойтись, но мне это видится самым «правильным» решением.

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

И в развесистых проектах их грузят через всякие require.js, yepnope и т.п.

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

А если нет разницы всё равно ждать, может не делать никаких require.js и прочего ненужно?

А у меня сейчас на демке аватарки как раз с другого хоста и качаются (lorempixel.com). Причем хост иногда подтормахивает. Именно поэтому и обнаружил.

В теме уже описано 2 способа не ждать. Просто хочется что-то попроще.

Глубокая мысль.

По идее эти картинки не должны мешать подгрузке скриптов

они мешают тк пулл забит, представь что их у тебя 200, а сервер отдает только 200 реквестов одновременно ;)

У него картинки с другого хоста, пул свой у каждого хоста

Как заставить скрипты грузиться до картинок?

Загружать картинки скриптами.
// портянку не читал.

Страница показывается действительно быстро, но если там много картинок

Подгружай картинки по мере их появления на экране.
JS-ка какая-то была.

Проще - это и есть забить на все и грузить скрипты по-нормальному. Они по определению будут тормозить если их грузить другими скриптами. Слепи в один файл на сервере и вставляй без костылей.

Помимо лимитов на пул, есть еще лимит на общее количество соединений. Поэтому если картинок много - очередь забить вполне реально.

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

Скрипты можно смержить в один. Картинрки тоже можно смержить. Ну, и с сервером статики что-то надо придумать, т.к. если проект требует большое количество файлов, то и сервер надо соответствующий.

Я про спрайты. По крайней мере, в спрайты можно склеить картинки шаблона. А скрипты склеивать — это вообще первая мысль, которая мне пришла бы в голову при такой проблеме.

Здесь вполне конкретный, и не очень простой вопрос, а не «оптимизация сайтов для пятиклассников».

Решение вопросов Per Rectum — это никакой не признак взрослости.

Да-да, признак взрослости - это наверное советовать про CSS-спрайты людям, которые в CSS вместо картинок используют фонты. А за последний коммент где-то наверное дают ачивки «прокачанный ум» и «мастер стратеги».

Проследуйте пожалуйста в толксы, или дальше.

покажи что-ли диаграмму как оно у тебя загружается, сгенерить ее можно например на http://www.webpagetest.org/

http://www.webpagetest.org/result/130826_SN_7VT/

Там странноватые результаты, лучше самому посмотреть в фаербаге и хроме:

http://dev.nodeca.com/forum/f7/topic3

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

2 коннекта на хост вроде стандартное ограничение.

Вообще, когда была такая необходимость, я поисковикам подсовывал картинки с нормальными src.
менять содержимое параметров в зависимости от юзерагента.

за это можно по голове от поисковика получить

Ну там в том что намерил webpagetest хорошо видно что js прогрузились до lorempixel

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

почему не связано? Скрипты грузятся в начале, событие dom ready возникает еще до загрузки всех картинок, все как ты хотел

- потому что там не показывается та проблема, о которой я говорю.
- потому что «в начале» != быстро.
- потому что в разных браузерах таймлайн разных

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

http://stackoverflow.com/questions/2703468/is-it-possible-to-run-javascript-b...

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

Фаербагу нельзя доверять, он диаграмму наугад рисует. Несколько раз я ловил дикие тормоза и по версии фаербага тормозила именно загрузка статики, а на самом деле тормозил он сам при попытке распарсить скачанные js, но время плюсовал почему-то куда придется.

Ну с бакграундами - почти такая же злая магия как с ноускрипт :) .

Я тут подумал, в принципе можно попробовать картинки массово затирать на старте (перекидывать src в data-*), а потом восстанавливать, когда скрипты всосало.

Вроде самый простой вариант. А чего тогда запихать в src, чтобы корректно было? Data url с гифкой 1х1 ?

гифку «картинки грузяццо..»

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

Обычно для ускорения вывода страницы на экран теги script просто вставляют не в head, а в конец body. Зачем вообще понадобился костыль вроде yepnope?

каждую страницу ручками клепать зависимости

Может я чего-то не понимаю, но какой смысл делать это руками? Проще проманкипатчить yepnope что-бы он выводил куда-нибудь названия загружаемых скриптов в порядке их загрузки, далее делать запрос на страницу и генерировать из полученного списка код, который надо вставить в head. Затем вставляем этот код в head и выкидываем yepnope со страницы.

Если не удастся проманкипатчить, можно получить этот список и другими способами, например из лога веб-сервера или скриптом вставив в начало каждого js-файла строку в духе "(scripts = scripts || []).push('имя скрипта')".

"(scripts = scripts || []).push('имя скрипта')"

"(scripts = scripts || []).push('имя скрипта');"

В загрузке сайта есть 2 этапа:

1. Страница показалась
2. Скрипты «завелись»

Вот я хочу, чтобы быстро было не только [1], но и [2]. Иначе траблы с менюшками, и переход по ссылкам идет не аяксом, а обычным способом.

Как делать быстро [1], у меня уже решено.

Логично, но потянет другие проблемы - все картинки разных размеров (и у большинства он фиксирован через CSS или атрибутами), заскейлится косо. К тому же анимашки традиционно грузят CPU.

Надо будет поэкспериментировать с этой шмагией. Там даже не обязательно ждать, когда загрузятся скрипты. Достаточно убедиться, что теги <script> воткнулись загрузчиком в head и начали качаться, а дальше можно картинки реанимировать, чтобы не терять на параллельной загрузке.

Вообще, мое мнение, нужно собрать js в один ком, а потом просто вызывать то, что нужно для конкретной страницы из общей «библиотеки», т.е. зависимости не нужны, т.к. время компиляции несравнимо с временем запроса. Этот скрипт можно хоть на клиенте сохранить.

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

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

А не надо ли делать так: 0. Грузим скрипты 1. Скрипты «завелись» 2. Грузим контент 3 Скрипты обрабатывают контент 4. Страница показалась

Возможно, я сужу по тенденции, когда объем ядра несоизмерим с кодом его использующим.

В любом случае актуальна задача завести базовую функциональность максимально быстро. Когда на странице со списком тем ссылки и пагинация кликаются не так как надо (с полной прогрузкой) - это не айс. Там могут быть и более сложные вещи, но в 99% случаев юзеру надо перейти к теме или перелистнуть страницу.

Я все это понимаю. Опишу свое предложение подробнее. Во-первых выкиньте yepnope, он похоже не нужен. Во-вторых страницу организуйте следующим образом:

<html>
  <head>
    <!-- здесь подключаем все css -->
    <script type="text/javascript">
      function loadAndEval(scriptNames) {
        // ...
      }

      loadAndEval(scriptNames);
    </script>
  </head>
  <body>
  <!-- куча картинок -->
  </body>
</html>

Где scriptNames - это упорядоченный список адресов скриптов, о которых я говорил. Под упорядоченностью подразумевается что зависимые скрипты идут в списке после тех, от которых они зависят.

loadAndEval это функция которая при вызове, через XMLHttpRequest, сразу начинает асинхронную загрузку всех адресов из scriptNames и евалит их по мере получения. Естественно скрипты могут грузиться не в том порядке, в котором они были указаны в scriptNames, так что нужна логика, которая будет откладывать выполнение загруженных скриптов если еще не подгрузились зависимости.

Само определение функции loadAndEval можно конечно вынести в отдельный файл, но думаю что лучше передавать его прямо в коде страницы. Функция маленькая, так что один HTTP-запрос можно и сэкономить.

Очередь загрузки браузера будет такой как вам надо:

1. Все CSS-файлы
2. Все JS-файлы
3. Картинки

Вместо всей этой конструкции конечно можно просто использовать тег script с атрибутом async, но IE его поддерживает только с десятой версии.

Вот именно при такой схеме картинки могут забить очередь запросов раньше, чем ваш загрузчик навтыкает асинхронные script в страницу. И мы обсуждаем, каким подвывертом это побороть. Кроме физического втыкания <script async> при генерации страницы - в этом случае гарантированно попадет в очередь до картинок.