Я написал эту часть руководства.
Вы определенно не хотите жить в процессе компиляции.
Когда у вас есть компиляция, вот что происходит:
Каждый запрос файла в / assets передается в Sprockets. При первом запросе для каждого актива он компилируется и кэшируется во все, что Rails использует для кэширования (обычно файловая система).
При последующих запросах Sprockets получает запрос и должен найти имя файла с отпечатками пальцев, проверить, что файл (изображение) или файлы (css и js), составляющие ресурс, не были изменены, а затем, если есть кэшированная версия, выполнить это.
Это все в папке активов и в любых папках vendor / assets, используемых плагинами.
Это много накладных расходов, так как, если честно, код не оптимизирован по скорости.
Это повлияет на скорость передачи активов клиенту и негативно скажется на времени загрузки страницы вашего сайта.
Сравните со значением по умолчанию:
Когда ресурсы предварительно скомпилированы и компиляция выключена, ресурсы скомпилированы и сняты с отпечатком пальца public/assets
. Sprockets возвращает таблицу сопоставления имен файлов с простым отпечатком в Rails, а Rails записывает это в файловую систему. Файл манифеста (YML в Rails 3 или JSON со случайным именем в Rails 4) загружается в Memory при помощи Rails при запуске и кэшируется для использования вспомогательными методами ресурсов.
Это делает создание страниц с правильными отпечатками очень быстрыми, а сами файлы обрабатываются с помощью веб-сервера из файловой системы. Оба значительно быстрее, чем живая компиляция.
Чтобы получить максимальную выгоду от конвейера и снятия отпечатков, вам нужно установить заголовки на будущее на вашем веб-сервере и включить сжатие gzip для файлов js и css. Sprockets записывает сжатые версии ресурсов, которые вы можете настроить на использование своего сервера, избавляя от необходимости делать это для каждого запроса.
Это позволяет клиенту получать активы как можно быстрее и с наименьшим возможным размером, ускоряя отображение страниц на стороне клиента и сокращая (с заголовком в далеком будущем) запросы.
Так что, если вы живете, это:
- Очень медленно
- Не хватает сжатия
- Будет влиять на время рендеринга страниц
Против
- Быстро настолько, насколько это возможно
- Сжатый
- Удалите сжатие, подслушанное с сервера (опционально).
- Минимизируйте время рендеринга страниц.
Изменить: (Ответ, чтобы прокомментировать комментарий)
Трубопровод мог быть изменен на прекомпиляцию по первому запросу, но для этого есть некоторые серьезные препятствия. Во-первых, должна быть таблица поиска для имен с отпечатками пальцев, или вспомогательные методы слишком медленные. В соответствии с senario по требованию компиляции должен быть какой-то способ добавления в таблицу поиска, когда каждый новый ресурс компилируется или запрашивается.
Кроме того, кто-то должен будет заплатить цену медленной доставки активов в течение неизвестного периода времени, пока все активы не будут собраны и введены в действие.
По умолчанию, когда цена компиляции всего платится за один раз в автономном режиме, не влияет на общедоступных посетителей и гарантирует, что все работает до того, как все заработает.
Преодоление заключается в том, что это добавляет много сложности производственным системам.
[Редактировать, июнь 2015 г.] Если вы читаете это, потому что ищете решение для медленного времени компиляции во время развертывания, то вы можете рассмотреть возможность предварительной компиляции ресурсов локально. Информация об этом находится в руководстве по конвейеру активов . Это позволяет вам прекомпилировать локально только при наличии изменений, зафиксировать их, а затем выполнить быстрое развертывание без стадии прекомпиляции.