Я хочу, чтобы сайты открывались мгновенно

4) Я не имел в виду конкретно хостинг. Тот же VPS может быть с ограниченным трафиком
7) Весь кеш все равно не сгенерируешь и сервер все равно придется ждать

В общем это довольно спорный момент. Нужно пробовать оптимизировать на конкретном проекте очень аккуратно и с умом. Если делать в лоб, то можно и потерять в скорости. Основная моя мысль была в этом.

Я хочу, чтобы сайты открывались мгновенно

Статья интересная. Автору спасибо. Хоть я и не увидел ничего нового, но кое с чем я с автором не согласен:

Мм, окей. Давайте тогда объединим все-все js файлы в 1 и все-все css файлы в 1. Тогда же уместимся в лимиты любого браузера, ну и грузиться будет быстро.

На правильном пути, но это всё ещё некорректно. Вам не нужны все-все js и css файлы для начальной отрисовки страницы. Даже если часть не используется — они все равно занимают канал и процессорное время. Ну и ещё при любом изменении самого маленького файлика кэш инвалидируется и пользователю загружать всё заново.

Я раньше много экспериментировал с оптимизацией, сжатием и http кешем и пришел к следующему выводу: в случае css лучше объединять все в 1 файл, а в случае js можно попробовать разбить на компоненты, но аккуратно

1. если дополнительные стили подгружать через js мы потеряем время на исполнение js кода отвечающего за загрузку стилей
2. если загружать через link то потерь будет меньше, но появится проблема с очередью загрузки, ведь мы хотим что бы дополнительные стили грузились после загрузки основных данных. В случае загрузки дополнительных js модулей их можно разместить в конце html документа
3. мы потеряем время на загрузку дополнительных стилей. еще запрос, ожидание, загрузка, рендор. В сумме это будет дольше чем 1 большой запрос. Для css это критично, а для js нет
4. мы увеличиваем количество запросов к серверу, что может быть критично для сервера, канала и тарифного плана хостера
5. в данном случае мы рассматриваем первую загрузку на холодном кеше, при следующем запросе css и js будут браться из локального кеша браузера и в этом случае будет быстрее если это будет один файл. Даже если данные запрашиваются из кеша, это все равно запрос и чем меньше запросов тем быстрее
6. аргумент с изменением файлов тоже не аргумент потому что это относится к последующим запросам, а файл css или js меняется, если меняется, только после деплоя который в нормальных проектах делается не более 2 раз в неделю. Если изменения произошли в 3 файлах из 5, то мы загрузим 3 новых файла или 1 если все 5 файлов сжаты в 1. Объем больше, но запросов меньше
7. вообще в случае деплоя нормально сбрасывать весь кеш и в этом случае первый пользователь после деплоя генерит не только локальных кеш, но и кеш на сервере и от этого никуда не деться
8. так же не стоит забывать об обфускации css и js кода которая может дать до 40% уменьшения объема и тем самым повышение скорости загрузки
9. можно еще использовать gzip компрессию уменьшив размер файлов еще на ~5%. Но я правда не знаю хранит ли браузер в локальном кеше сжатую версию или нет. Если хранит сжатую то на каждый запрос браузер будет тянуть из кеша, разжимать и применять. В этом случае сжатие будет только вредить
10. реальная экономия получится только если будет загружаться 0-2 из 10 дополнительных модулей/файлов, а если таких файлов 5-15 на запрос, то выигрыша особого уже не будет

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

Становимся профессиональными PHP разработчиками. Часть 1: Недостающее звено

Толку не много потому что это только каталог шаблонов, не все из которых имеют смысл в php, но без понимания что такое «шаблоны проектирования» и например чем Singleton отличается от Lazy Load, далеко не уедешь.

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

Ну и про GRASP тоже книжка есть.

Становимся профессиональными PHP разработчиками. Часть 1: Недостающее звено

Ну, я бы не сказал что книги не стоит читать. Да, книги безусловно быстро устаревают, но читая статьи ты набираешь информации только поверхам, а для глубинного понимания и структурирования информации нужно читать книги.
Профессионалом не стать без прочения хотя бы GoF.

Локализация IT-сайта силами пользователей и возможностями GitHub

Я храню документацию на GitHub и вывожу ее на сайте. Написал hook который на pull request обновляет документацию на сайте. Таким образом получил live update документации на сайте и сайт не дергает GitHub без необходимости

Внедряем Bootstrap 3 Datepicker в SonataAdminBundle

а если сделать как советует korotovsky и вынести DataTransformer в отдельный класс то кода станет еще меньше

Внедряем Bootstrap 3 Datepicker в SonataAdminBundle

Проблема в том что в sonata используется устаревшая версия 3.1.3 от 16 августа 2014. В актуальной версии 4.17.37 от 10 сентября 2015 эту проблему исправили, но если просто перейти на версию 4.17.37 мы получим ошибку:

Uncaught TypeError: option pickTime is not recognized!

Генерируемый JavaScript код

$('#dtp_s5666a539ecb69_duration').datetimepicker({
    "pickTime":true,
    "useCurrent":true,
    "minDate":"1\/1\/1900",
    "maxDate":null,
    "showToday":true,
    "language":"ru",
    "defaultDate":"",
    "disabledDates":[],
    "enabledDates":[],
    "icons":{
        "time":"fa fa-clock-o",
        "date":"fa fa-calendar",
        "up":"fa fa-chevron-up",
        "down":"fa fa-chevron-down"
    },
    "useStrict":false,
    "sideBySide":false,
    "daysOfWeekDisabled":[],
    "useMinutes":true,
    "useSeconds":true,
    "minuteStepping":1
});

Соответственно необходимо переопределять поведение DateTimePickerType что бы поменять опции передаваемые datetimepicker-у или переопределять шаблон SonataCoreBundle:Form:datepicker.html.twig и писать в нем большой if-else.

Внедряем Bootstrap 3 Datepicker в SonataAdminBundle

В том то и дело что нет. В приведенном мною примере указывается формат HH:mm:ss, что говорит о том что дата выводится не должна и если создавать поля как в статье или как документации Bootstrap Datepicker, то оно так и работает. Однако, при использовании sonata_type_datetime_picker это не срабатывает. Очень похоже на то что sonata под капотом выполняет какие-то свои манипуляции с датой.
Сейчас попробовал использовать поле time из статьи совместно с sonata_type_datetime_picker и получил такой же результат как в моем комментарии.

И это не смотря на то что код JavaScript имеет вид

 $('.form-field-time').each(function () {
        var el = $(this),
            options = {locale: 'ru'};
        if (el.data('with-seconds') == 1) {
            options.format = 'HH:mm:ss';
        } else {
            options.format = 'HH:mm';
        }
        el.datetimepicker(options);
});

Завтра попробую подробней разобраться в проблеме.

Внедряем Bootstrap 3 Datepicker в SonataAdminBundle

Однако для выбора времени поле в существующем виде не подходит

выбор времени

$formMapper->add('duration', 'sonata_type_datetime_picker', [
    'label' => 'Продолжительность',
    'required' => false,
    'format' => 'HH:mm:ss',
    'date_format' => 'HH:mm:ss'
])

Внедряем Bootstrap 3 Datepicker в SonataAdminBundle

добавил ссылку

Внедряем Bootstrap 3 Datepicker в SonataAdminBundle

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

Внедряем Bootstrap 3 Datepicker в SonataAdminBundle

у меня не работало форматирование даты в transform(), а после вашего комментария я понял почему. спасибо

Внедряем Bootstrap 3 Datepicker в SonataAdminBundle

Спасибо за ссылку. Я его не нашел в документации