Недавно Школа кодов викингов начала работу над новой собственной структурой стилей. Когда-нибудь он станет основой всего стиля на сайте. Тем временем, однако, устаревшие стили останутся на многих страницах, поэтому мы должны иметь возможность жонглировать этими двумя конкурирующими наборами стилей. Чтобы избавить наших пользователей от загрузки CSS-файла двойного размера в их браузер при каждой загрузке страницы, мы переработали наш конвейер ресурсов, чтобы записывать только стили, относящиеся к странице, к которой осуществляется доступ. Излишне говорить, что для этого требуется отключение Turbolinks.
Первым шагом в этом процессе была реорганизация каталога app/assets для обработки нескольких наборов стилей. Мы решили организовать это примерно так:
> stylesheets
> legacy
v new_framework
main.scss
application.css
Возможно, наиболее важно то, что файл main.scss в каталоге new_framework включает в себя все содержимое новой структуры стилей. Кроме того, мы обновили файл application.css (который теперь предназначался для устаревшего CSS), чтобы он выглядел следующим образом:
/* *= require other_css_libraries *= require_self *= require_tree ./legacy */
Оттуда мы добавили новый макет, new_css_framework.html.erb, в app/views/layouts. В то время как устаревший макет application.html.erb останется прежним (на данный момент), этот макет будет включать новые таблицы стилей:
<!DOCTYPE html> <html> <head> ... <%= stylesheet_link_tag "new_framework/main" %> ... </head> ...
Макет был добавлен в контроллер для всех страниц, использующих новую структуру (также можно сделать для каждого действия контроллера):
class ...Controller < ApplicationController layout 'new_css_framework' ... end
В этот момент кто-то (я) решил, что это готово к производству, и отправил его на наш промежуточный сервер, чтобы проверить. И… не получилось. Я забыл о последнем важном шаге добавления нового файла CSS к предварительной компиляции ресурсов Rails.
# config/initializers/assets.rb ... Rails.application.config.assets.precompile << "new_framework/main.css"
С предварительно скомпилированным новым набором стилей все заработало.
Время загрузки новых страниц заметно уменьшилось. Поскольку это было так удивительно просто, мы также применили его к нашим стилям рассыльщика (мы используем Premailer) и нашим приложениям Angular (процесс такой же для JavaScript). Первый уменьшил размер наших электронных писем более чем на 90%, что, наконец, решило проблемы с обрезкой, которые у нас были с Gmail. Прирост производительности стоил затраченных усилий.
Post Scriptum: я решил написать это, потому что наш основатель ранее исследовал это, но не смог найти достаточно конкретной информации, чтобы принять обоснованное решение.
