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

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

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

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

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

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

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

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

Ответы

Ответ 1

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

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

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

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

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

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

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

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