Кеширование байкода в V8 и GoogleChrome.
Кеширование откомпилированного JavaScript кода существует с 2015 года с версии v8 4.2,
в чем можно легко убедиться даже просто посмотрев в папку кеша Google Chrome где кеш байткод-а вынесен в отдельную папку.

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

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

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


Существует три стратегии Chrome браузера приводящие к кешированию байткода.

При этом для всех трех стратегий должны выполняться следующие условия:
1. Это должен быть внешний файл. Inline код никогда не кешируется (для байт кода)
2. Размер файла должен быть более 1 килобайта.
3. Кодировка файла и страницы должна быть UTF8 В случае если кодировка не
совпадает - кеш байт кода не используется, но при этом может в некоторых случаях
создаваться.


Стратегия 1
Самая распространенная модель поведения связана с типичной загрузкой Js файла: использования тега script для подключения файла кода.
В рамках этой модели, существует три фазы через которые должен пройти код, чтобы его откомпилированная версия(байт код) попала в кеш.

При первом запросе JS файла, происходят все типичные процессы для запуска кода, при этом откомпилированная версия не сохраняется в кеше. Сохраняется только сам JS файл - его текстовое представление.

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

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

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

Например, в случае загрузки jQuery версии 1.2 где обьем JS кода в несжатом виде составляет около 100кб, только половина его кода компилируется на старте и попадет в кеш байт кода.


Стратегия 2
Вторая модель поведения связана с использованием Cache API. Если JS код запрашивается и подключается при помощи использования этого API, то все происходит ровно так же как и в стратегии 1, за исключением первой подфазы сохранения JS файла. То есть в случае использования Cache API мы ровно на один шаг ближе к цели.


Стратегия 3
Третья модель поведения связана с фазой Install у Service Workera. В этой фазе, все JS файлы которые присутствуют в списке предварительной загрузки, в отличии от двух предыдущих примеров, гарантировано проходят 100% компиляцию, и 100% сохранение в кеш байт кода, в результате чего браузер уже при первом подключении использует 100% откомпилированную версию взятую из кеша байт кода.

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