Кэширование объектного кода JavaScript: какое из этих утверждений неверно?

Поскольку я много лет занимаюсь инженерами, я знаю, что если я не предоставил контекст, я собираюсь получить сто ответов на форму "Что вы пытаетесь выполнить?" Я собираюсь дать фон, который мотивирует мой вопрос. Но не путайте фоновый контекст для вопроса, который я задаю, который специально связан с семантикой JavaScript, которая делает объектный код незашифрованным между запросами прокси. Я не собираюсь давать оценки за советы о том, как сделать мой webapp быстрее. Это полностью касательно моего вопроса, который, вероятно, будет отвечать только тем, кто работал над компилятором JavaScript или, по крайней мере, компилятором для динамического языка.

Фон:

Я пытаюсь улучшить производительность веб-приложения. Среди его многочисленных ресурсов он содержит один огромный файл JavaScript с 40-килограммовыми линиями и предиминификацией 1,3 миллиона символов. Постминификация по-прежнему велика и по-прежнему добавляет около 100 мс к событию window.onload при синхронной загрузке, даже когда источник кэшируется на стороне клиента. (Я окончательно исключил возможность того, что ресурс не кэшируется, наблюдая журналы запросов и наблюдая, что он не запрашивается.)

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

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

Объектный код JavaScript не кэшируется в любом современном браузере.

"Код объекта" может означать что угодно: от байтового кода, представляющего простое линеаризованное дерево разбора до собственного машинного кода.
Объектный код JavaScript в веб-браузере трудно кэшировать.

Другими словами, даже если вы включаете исходный файл кешированного JS во внешний тег, линейная стоимость включает этот script на странице, даже если script содержит только определения функций, потому что весь этот источник должен быть скомпилирован в объектный код.
Объектный код JavaScript трудно кэшировать, потому что источник JS должен оцениваться для компиляции.

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

3a. (3) истинно в основном из-за eval().
Оценка может иметь побочные эффекты для DOM.
Поэтому исходный код JavaScript должен быть скомпилирован при каждом запросе страницы.

Бонусный вопрос: какие современные браузеры кэшируют дерево разбора для кэшированных исходных файлов JS? Если нет, почему бы и нет?

Изменить: если все эти утверждения верны, я дам ответ всем, кто может изложить, почему они правильны,, например, предоставив образец кода JS, t быть кэшированным как объектный код, а затем объяснить, почему нет.

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

Ответ 1

Вы правы в том, что он динамически компилируется и оценивается.
Вы правы, что это должно быть.

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

Если ваша программа составляет 10 000 строк процедурного кода, у вас возникла проблема.
Я надеюсь, что это не все процедурные.

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

Это все о восприятии пользователем "скорости" и "отзывчивости", а не о кратчайшей линии до 100% функциональности.

JavaScript в однопоточном формате не может делать так, чтобы и реагировали.
Поэтому сначала будьте отзывчивы.

PS: Добавить бутстрап. интеллектуальный бутстрап. Он должен уметь различать, какие функции необходимы.
RequireJS предназначен для загрузки зависимостей.
Не для того, чтобы выяснить, каковы ваши зависимости.

Дополнительное преимущество - вы можете установить кратковременный кеш в бутстрапе, который укажет на версии модулей. Как это выгодно? Ну, если вам нужно обновить модуль, это простой процесс обновления версии в бутстрапе. Когда кеш-бутстрап истекает, он указывает на новый модуль, который может иметь бесконечное время жизни (поскольку он получил другое имя - с версией или timestamped);