Я хочу предварить эту статью, сказав, что мне очень нравится Vue CLI. Волшебное решение всех самых болезненных аспектов разработки SPA — это блестяще, когда я работаю в срок. Меня, например, всегда удивляет сервис-воркер, который работает из коробки. Однако далее следует история о ловушках, которым мы подвержены, когда полагаемся на такой высокий уровень абстракции.
Предыстория этой статьи такова: я работал над SPA, который становился слишком тяжелым. Размер пакета превысил 500 КБ, а приложение все еще было довольно маленьким. Я начал задаваться вопросом, почему, и внимательно посмотрел на то, что мы отправляли клиенту.
Почти сразу стало очевидно, что мы отправляем много CSS. Почти все наши правила стилей находились внутри блоков стиля в наших шаблонах, а остальные находились в файлах SCSS, которые все были импортированы в основной файл и включены в App.vue. Однако объем встроенного CSS, который мы отправляли (примерно 100 КБ), не имел смысла.
Я более внимательно посмотрел, как используется наш основной файл SCSS. Как знают многие люди, знакомые с Vue, вы можете сделать SCSS глобально доступным (и избежать написания везде утомительных операторов импорта), добавив параметры в загрузчик CSS в vue.config.js.
Однако все, что вы поместите в этот файл, также будет доступно во всех блоках SCSS с заданной областью действия в ваших однофайловых компонентах Vue. Если вы поместите какие-либо правила внутрь, они будут ограничены областью действия каждого из этих компонентов, что приведет к огромному количеству дублирования и неиспользованному CSS. Любые файлы, импортированные сюда, должны состоять только из переменных или примесей, которые будут удалены, если они не используются. Поскольку у компилятора SASS → CSS нет возможности проверить, какие правила используются на самом деле (в отличие от объявлений переменных), они сохраняются.
Итак, следующее, что нужно сделать, это импортировать сюда только переменные и убедиться, что SCSS в нашем основном файле импортирован только там, где он будет использоваться (внутри основного файла .vue). Это было хорошей отправной точкой:
После проверки наших файлов SCSS и избавления от всех неиспользуемых правил, мы сократили неиспользуемый CSS примерно до 10%. Проект был создан с помощью Normalize.css, в котором были некоторые вещи, которые мы не использовали. Например, мы не поддерживали ни одну версию IE, а многие правила ориентированы на IE10. Итак, что мы сделали по этому поводу? Мы скопировали весь файл из node_modules и удалили все, что не использовали. Для этого проекта не было никаких мыслимых ситуаций, когда нам все равно нужно было бы отформатировать элемент kbd или pre. Опять же, используя вкладку покрытия Chrome DevTools в качестве руководства, мы удалили все, что нам не нужно.
Я не склонен писать много комментариев, так как они обычно становятся очень запутанными, если только все в команде не обращают на них внимание и не следят за тем, чтобы они не стали лишними. Однако подобные тонкие решения заслуживают документирования в коде. В итоге я назвал получившийся файл micronormalize.css и добавил к нему комментарий с подробным описанием того, откуда он взялся и почему, а также оставил первоначальные комментарии, объясняющие причины каждого правила.
Я понимаю первоначальное намерение импортировать все наши SCSS повсюду, предполагая, что это было намеренно — нам нужно было быстро проверить идеи, и самым важным фактором было передать продукт в руки некоторым бета-тестерам. Однако пришло время, когда наши бета-тестеры жаловались (небезосновательно) на производительность. К сожалению, как только первоначальная настройка проекта была «закончена», о ней быстро забыли. Точно по той же причине возникла аналогичная проблема с сервис-воркером, который предоставляет vue-cli-3. Конечно, это работает из коробки, но что происходит, когда вы перестраиваете и повторно развертываете свой проект? Сервисный работник обслуживал оболочку приложения со ссылками на хешированные имена файлов, которые были удалены, и это сломало все приложение. Наше празднование запуска было очень недолгим; мы почти сразу выложили исправление, а потом все сломали.
Это основная проблема с чрезвычайно высоким уровнем автоматизации и абстракции, которые обеспечивают такие инструменты, как Vue CLI. Дважды в течение месяца серьезные проблемы, возникшие в результате первоначальной настройки проекта, повлияли на доступность и производительность нашего приложения.
Итак, что здесь можно сделать, кроме нескольких советов по уменьшению раздувания CSS? Для разработчиков JavaScript доступно так много инструментов. Легко предположить, что инструментарий все оптимизирует за нас, но это не всегда так. Все в моей команде, включая меня, были виновны в том, что принимали инструменты, которые мы используем, как должное. Когда наши проекты форматируются, анализируются, сканируются на наличие запахов кода, оптимизируются, собираются и развертываются автоматически, легко перестать обращать внимание (именно поэтому эти инструменты были разработаны в первую очередь — людям становится скучно). Однако наша работа как разработчиков программного обеспечения или профессионалов любого рода заключается в том, чтобы знать ограничения наших инструментов, знать, как их следует использовать, и обращать внимание на конечный продукт. Первоначальная ошибка была очень незаметной, но ее последствия — нет.
Я не очень опытный разработчик, и у меня нет очевидных решений этой проблемы. В итоге наша команда подробно прочитала много документации, что почти сводит на нет цель такого инструментария. Если вы прочитали это и у вас есть идеи или вы знаете о лучших практиках, поделитесь ими в комментариях. Спасибо за чтение, я ценю это.
