Daria Motorina

https://github.com/lexik/LexikJWTAuthenticationBun...

Вот этот бандл? https://github.com/lexik/LexikJWTAuthenticationBundle

Если да, то так:
https://github.com/lexik/LexikJWTAuthenticationBun...

В общем случае -- стоит.

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

Можно всё сгрести в один огромный бандл. Тогда первичная загрузка будет дольше, особенно ощутимо на медленном интернете. Но навигации по страницам будут быстрее, а нагрузка на сервер меньше. Но при изменении, скажем цвета одной кнопки, пользователю придётся заново качать весь бандл. И наоборот. Можно уйти и в другую сторону: дробить всё на как можно меньшие кусочки. (Например вынести весь код для какой-то модалки отдельно) и загружать каждый чанк только в момент когда он понадобится. Так первичная загрузка будет намного быстрее, но реакция на действия пользователя будет медленнее.

В общем случае -- дробить код сайта на куски и отдавать их частями -- стоит. Но вмеру. А как именно делить -- зависит от вашего случая.

Вот

Используйте unset() для данных, которые больше не нужны.
Ссылка: https://habr.com/ru/post/134784/

function makeHandler(i) {
  return function() {
    alert("This is button: " + i);
  }
}

for (var i = 1; i <= 3; i++) {
  document.getElementById('button-' + i).onclick = makeHandler(i);
}

Смотря чего от вас хотят. В принципе, достаточно var на let заменить в цикле.

или замыканием https://jsfiddle.net/DelphinPRO/uyoa9d5f/
Или то же самое, только по другому https://jsfiddle.net/DelphinPRO/uyoa9d5f/1/

В концепции протоколов TCP главное значение придавалось стабильности, скорость играла второстепенную роль. TCP отправляет небольшой объем данных и ожидает подтверждение о прибытии пакета, прежде чем отправить следующие. Именно таким образом TCP убеждается в доставке пакетов, поэтому его называют «болтливым» протоколом (от англ. chatty protocol). Из-за «болтливости» и неизбежной задержки загрузка по глобальной сети длится существенно дольше, чем по локальной. Так, передача через глобальную сеть вложенного в электронное письмо файла PowerPoint размером 3 Мбайта может занять 20 мин, в то время как по локальной сети — лишь пару секунд.
Прикладные протоколы на основе TCP подвержены той же проблеме и часто отличаются еще большей задержкой. Однако каждый пользовательский протокол работает по-разному, поэтому и «болтливость» проявляется у каждого в разной степени.

В vendor/symfony/framework-bundle/Controller/ControllerResolver.php

По статье всё верно описано. Там в контейнер добавляется
* Container->addCompilerPass(new MessengerPass());

Я просто забыл вызвать компиляцию контейнера
* Container->compile();

Смысл моков - эмулировать объекты с определенным поведением.

Самый банальный пример, помимо http запросов, это эмулирование неправильных объектов.

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

В phpunit есть функционал подсчета покрытия кода тестами - попробуйте на каком-нибудь относительно небольшом модуле добиться 100% покрытия кода тестами - вам обязательно придется использовать хитрые моки, эмулирующие нестандартное поведение объектов.

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