Как оптимизировать загрузку js для многостраничных сайтов?

Question

[dmtr81]

Исходные условия проблемы примерно таковы - есть многостраничный сайт, скажем так "портального" типа, но не очень большой. Бэкэнд традиционно написан на php. На фронтэнде используем jquery со всякими сторонними и своими плагинами для улучшения пользовательского интерфейса - всякие там лайтбоксы, календари, всплывающие подсказки и прочий довольно стандартный зоопарк.

Не так давно нами было решено внедрить модульный подход? асинхронную загрузку с использованием require.js и разделение бэкэнда и фронтэнда. Внедрение прошло удачно, но встал вопрос как теперь оптимизировать загрузку яваскриптов?
Самое популярное решение для require.js, которое предлагается везде, это используя r.js склеить все в один файл и подключать его на продакшене. Но, простите, друзья, для чего мы тогда внедряем всю эту модульность? Только ради удобства в разработке?

У нас в общей сумме на сайте используется около 300-400 кб разного яваскрипта, причем это использование идет совершенно неравномерно по разделам. И мне кажется, что запаковать это все в один файл и отдавать каждому посетителю не совсем правильно. Дело в том, что наш среднестатистический пользователь может никогда не дойдет до страницы или раздела сайта, где мы используем datepicker или загрузку фото, или еще какие-то специфические скрипты. Так зачем мы будем его нагружать этими подарками при первой встрече, заставлять его качать все 400 кб скриптов, а потом заставлять его браузер проводить синтаксический анализ всего этого кода.

Сейчас у нас используется какое-то промежуточное решение, которым мы по прежнему не очень довольны. При первой встрече мы отдаем пользователю минимальный набор необходимых скриптов (100-150 кб), а остальное подтягиваем в виде requirejs модулей. В итоге получаем, что при большом количестве интерактивных элементов на некоторых страницах, в дополнение к базовому набору скриптов у нас запрашивается и качается еще 5-7 javascript файлов. С точки зрения оптимизации, кажется, это тоже не очень красивое решение.

Наверное, не мы первые сталкиваемся с таким вопросом. Сайт у нас не уникальный и проблема тоже.
Что же выгоднее делать с точки зрения правильной клиентской оптимизации:
1. Паковать все скрипты в один файл, отдавать его сразу и не заботиться, что большая часть из этих скриптов не будет востребована многими посетителями сайта?
2. Пытаться как-то поделить скрипты. Отдавать только то, что нужно посетителю на конкретной странице сайта?

Если идти вторым путем, то что делать с оптимизацией? Как быть если страница требует загрузки десятка мелких js модулей?

Answer 1

[Сергей Протько]

минифицировать все и отдавать с gzip с правильными настройками HTTP кэша. Один раз загрузили и больше не дергаем на все страницы.

Comments

[dmtr81]

HTTP кэш включен. С gzip наш итоговый размер js файла сократится раза в 2, наверное. Т.е. пользователь получит 200 кб вместо 400 (а мог бы получить всего 50 кб). При этом нас не заботит, что большая часть этого кода ему, вероятно, никогда не понадобится?
Временем и ресурсами браузера на синтаксический анализ ненужного кода также можно пренебречь?

[Сергей Протько]

@dmtr81 как-то слабова-то. Может посильнее жать? Я обычно на максимум сжимаю файлы при деплое, а nginx умеет отдавать уже пожатые данные.

[Сергей Протько]

@dmtr81 200 килобайт фигня, учитывая что скорее всего удастся ужать еще сильнее.

[dmtr81]

@Fesor все равно не укладывается у меня преимущества этого подхода. А если у нас не 400 кб несжатого js кода, а 800 или 1.5 мб. Когда-то придется остановиться и что-то делать другое.

[Сергей Протько]

@dmtr81 тогда разделить приложение на модули, собрать их через r.js и подгружать по мере требования через тот же require.js, предварительно пожав в gzip и с правильно настроенным кешем.

Answer 2

[Дмитрий Б]

Сделайте подключение javascript файлов в самом javascript.
Например:
- фронтенд получил jquery и jquery ui, и записал их в список полученных скриптов
- далее сервер опять предлагает получить jquery и JQueryCookie, javascript проверяет и в итоге запрашивает только JQueryCookie
В общем записывайте все скрипты, которые получили и при следующих загрузках проверяйте, нужны ли они

Comments

[Дмитрий Б]

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

[Дмитрий Б]

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

Answer 3

[Евгений Петров]

Мне кажется, что вопрос единовременной загрузки скриптов вовсе не в весе. Что такое нынче 300-400 кб? Так, ерунда... (up: для мобильных устройств может оказаться и не ерундой, что не меняет подхода в целом)

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

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

Comments

[dmtr81]

Согласен, что анализ одного javascript файла на 300-400 кб браузером пользователя может визуально выглядеть как подтормаживание сайта. Это можно отнести к недостаткам первого метода.
С другой стороны совершенно не согласен, что 300-400 кб это ерунда. Не забываем про пользователей мобильных устройств.

[Rrooom]

Что такое нынче 300-400 кб? Это почти минута загрузки одной сран*й страницы на мобильном интернете.

[Евгений Петров]

@dmtr81 @Rrooom почему вы мне адресуете вопрос относительно большого размера клиентских скриптов? Я так вообще не представляю функционал страницы, для которой потребовалось бы 400 кб скриптов, ужатых GZIP.

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

[Rrooom]

@Petroveg Спорно. На мобильных уже давно весьма хорошие процы, котоые шустро перемолят весь код. А вот улучшать покрытие нашей родины никто не спешит.

[Евгений Петров]

@Rrooom пока грузится синхронный код, вашему процессору нечего перемалывать. Чего тут спорного?

[Rrooom]

@Petroveg тьфу, не так понял ваш комментарий

[dmtr81]

@Petroveg так в том то и дело, что не требуется на одной странице 400 кб скриптов. Просто большинство мнений высказывается в пользу создания одного большого файла и его загрузке при первом визите.
Если я правильно понял, вы против этого подхода в первую очередь не изза скорости загрузки файла, а изза возможной задержки на синтаксический анализ всей этой кучи ненужного кода при каждом открытии страницы?

[Евгений Петров]

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

Встречал на хабре статью на тему построения страницы.

[dmtr81]

@Petroveg вычитал такую вещь, что require.js умеет делать отложенную инициализацию скриптов. Т.е. код модуля не выполняется пока он явным образом не потребуется для работы пользователя.
В какой-то степени это решает проблему задержки на инициализацию всех скриптов при каждом открытии страницы. Получается, все объединить в один файл и использовать отложенную инициализацию самый интересный вариант.

[Евгений Петров]

@dmtr81 в Require.js есть возможность тонкой настройки config, в котором можно указать, что грузить сразу синхронно, что сразу, но асихронно, что только при выполнении условий. Прекрасный инструмент для управления асинхронной загрузкой. Загрузкой разных файлов.

Поместив код в один файл, мы всё равно получаем синхронную загрузку с последующим анализом кода. Анализ выполняет интерпретатор. Require.js — всего лишь прослойка JS-кода между интерпретатором, производящим анализ, и основным кодом. Так что проблема в этом случае остаётся — ожидание браузера до окончания загрузки единого JS-файла и завершения синтаксического анализа его кода.

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

[dmtr81]

@Petroveg да, вы правы, всегда нужно анализировать условия и смотреть особенности проекта. О нашем проекте я написал в самом вопросе, поэтому рассматриваю ответы в первую очередь относительно этих условий.
По поводу отложенного выполнения уже загруженного кода, я рекомендую посмотреть статью calendar.perfplanet.com/2011/lazy-evaluation-of-co... На данный момент этот подход мне кажется лучшим под наши условия.

Answer 4

[dmtr81]

Благодаря обсуждению в комментариях и еще некоторым изысканиям я пришел к следующему. Во-первых, вопрос оптимизации нужно разделить на 2 пункта и каждый из них обсудить отдельно.
1. Загрузка скриптов на устройство пользователя. Здесь однозначный вариант одобренный всеми - объединить все скрипты в один файл, минифицировать его, сжать и положить в кэш пользователю при первом визите.
2. Выполнение скриптов на устройстве пользователя. Здесь сложнее. Во-первых, оно происходит на каждое открытие страницы независимо от того взят скрипт из кэша или нет. Если вы не проводили никакой оптимизации, а просто объединили все свои скрипты в один файл, то сразу же после загрузки (взятия из кэша) браузер пользователя начнет их анализ и выполнение. Это занимает время, а на это время браузер пользователя "замирает". В зависимости от мощности устройства (десктоп или телефон) и размера вашего объединенного яваскрипта это выполнение можно занимать от долей секунды до нескольких секунд. Но даже замирание в 0.2-0.3 секунды вполне заметно для пользователя.
Полезные ссылки по этой теме:
calendar.perfplanet.com/2011/lazy-evaluation-of-co...
habrahabr.ru/post/145269

Остается вопрос, как совместить первое и второе, т.е. отдать пользователю весь js в одном большом файле, но заставить браузер выполнять только нужный на данной странице код, а ненужный не выполнять. Решение этому есть! Называется отложенное (ленивое) выполнение яваскрипта, по английски, delay (lazy) javascript evaluation. Т.е. если вы весь код объединяете в один файл и у вас этого кода много, позаботьтесь о том, чтобы выполнялся только тот код, который нужен на текущей странице.

В интернете достаточно решений по этому поводу, но т.к. мы используем require.js, я смотрел, как это решено в данной библиотеке. Начиная со 2 версии require.js умеет откладывать выполнение яваскрипта и делает это автоматически для всех модулей объявленных через define. Важно знать, что для скриптов написанных не в формате AMD и подключенных через shim (например плагинов jquery) отложенное выполнение не работает и они выполняются сразу же при загрузке. К сожалению, у нас таких плагинов довольно много и придется что-то делать, например, оборачивать их в модули requirejs. Но, кажется, это не очень большая проблема.

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

Answer 5

[Денис Инешин]

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

Но в целом это лишнее при ваших объемах. Нет ничего страшного в том, что какие-то части скриптов не выполняются в данный момент и юзер до них может и не дойдет никогда. Они ведь не загружают процессор, не вызывают тормозню. Какая вам разница, добрался ли юзер до вашего дейтпикера? В чем будет разница для юзер експириенс, получил ли юзер код для использования дейтпикера сразу или только когда открыл страницу, где он есть?

Есть еще и другое мнение, рассматривать сайт как приложение (ну вот например как на смартфонах). В чем прелесть такого подхода? А в том что при запуске приложения, вся оболочка этого приложения загружается разом. А потом, загружаются только голые данные, что дает небывалую скорость отклика и отзывчивость. На обычных сайтах такого не встретишь. В такой ситуации вам не только скрипты и стили, но еще и всю графику сайта придется как то предзагрузить и хранить на клиенте.

Comments

[Евгений Петров]

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

[Денис Инешин]

@Petroveg значит сайт должен быть одностраничным приложением

[Евгений Петров]

@IonDen есть и такие. Но для таких сайтов вопрос с загрузкой скриптов вообще не стоит:)

Answer 6

[Тимур Сергеевич]

Первый вариант самый правильный!

Comments

[dmtr81]

Почему?

[Тимур Сергеевич]

так как лучьше отдать всё один раз и не париться. 1)Браузер закэширует. 2)500 кб в наше время не что.3)даже для смартфонов.

Answer 7

[Олег Серых]

Сжать через r.js единственно верное решение, даже скрипт весом в 1mb это мелочь по сравнению с общим весом средне–статистической страницы с учетом картинок. А учитывая что скрипт загружается один раз и затем кешируется браузером, то тут и совсем нет повода переживать из за лишнего веса.

Comments

[dmtr81]

А как на счет задержки на инициализацию всей этой кучи яваскрипта? Читал в одной статье, что разбор 1 мб скриптов может занимать 100-300 мс десктопным браузером и примерно в 10 раз дольше на мобильных устройствах.

[Олег Серых]

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

[dmtr81]

@seryh про мобильники вы тактично решили умолчать :)

[Олег Серых]

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

[Евгений Петров]

@seryh речь о том, что загрузка будет синхронной, и на это время браузер замрёт. Если канал слабый, то мощность вашего устройства не имеет значения. Будет ждать, пока 500 кб не загрузится.

А так да — при последующих открытиях при наличии в кэше вопрос с синхронностью не стоит.