Комментарии 25
Если не ошибаюсь, то cra2 уже содержит стайл-лоадеры и там эта работа уже не нужна
На счет длинных названий и так ясно. Писать слишком длинные не стоит, но «e_f», «e_g»,«e_h» — это норм названия для классов? эм… Не уверен, что другой разработчик без 100 грамм разберется что к чему.
НЛО прилетело и опубликовало эту надпись здесь
А ничего, что при передаче чего-либо по HTTPS компрессия считается уязвимостью и отключается (по крайней мере в TLS1.2)? Гэзипуй не гэзипуй… А автор, похоже, всего лишь занялся минификацией css, причем в виде кода, которым из dev-css делается детерминированный prod_css с сохранением имен стилей и файлов. И это здорово.
Уязвимость, насколько я помню, связана со сжатием на уровне TLS. К данным уровня приложения, которые бегают внутри TLS-соединения (т.е. к HTTP и его Content-Encoding:gzip) эта проблема отношения не имеет.
Насколько я помню, сжатие работало как фактор, позволяющий за счет того, что куки и запрос передаются в одном пакете, угадывать куки по частям по размеру запроса с использованием очень большого количества запросов с частью контролируемого контента. И на тот момент единственным средством заставить браузер передавать несжатый запрос (с куками) был отключить сжатие на TLS как класс.
НЛО прилетело и опубликовало эту надпись здесь
"Если скотч не помогает, значит нужно больше скотча."
Вот еще немного и html/js/css станут обычным исполняемым файлом ;)
В Single File Components Vue.js нет никакого смысла использовать БЭМ, есть же scoped режим у стилей
Такое сокращение ничего не меняет, кроме уменьшения читаемости.
После gzip будет одинаковый практически размер.
А передавать стили без gzip в 2018году это гон.
После gzip будет одинаковый практически размер.
А передавать стили без gzip в 2018году это гон.
обработка ~950 Кбайт stylus-файлов занимает у меня около 4 секунд.
Ваша проблема определённо не в длине селекторов. Что вы там понаписали аж на мегабайт CSS? Меньше копипастить/кодогенерировать/подключатьчтопопало не пробовали?
Можно вынести CSS в отдельный файл для раздельного кэширования JS и CSS
А зачем вобоще кешировать js и сss отдельно? Компонент это не js и не css, это все вместе. Разбиваем на чанки — кешируем чанки.
По причинам:
1. Когда CSS лежит как строка в JS, то тогда пайплайн использования стилей выглядит так:
— Строка стилей обрабатывается JS парсером
— С помощью дополнительных JS функций она обрабатывается и вставляется как style элемент
— Стиль обрабатывается CSS парсером
Если используется CSS файл, то первые 2 шага отпадают.
2. Если вдруг надо поправить что-то, кроме верстки, то кэши CSS останутся одинаковыми и юзеры не выкачают лишние данные.
1. Когда CSS лежит как строка в JS, то тогда пайплайн использования стилей выглядит так:
— Строка стилей обрабатывается JS парсером
— С помощью дополнительных JS функций она обрабатывается и вставляется как style элемент
— Стиль обрабатывается CSS парсером
Если используется CSS файл, то первые 2 шага отпадают.
2. Если вдруг надо поправить что-то, кроме верстки, то кэши CSS останутся одинаковыми и юзеры не выкачают лишние данные.
1. Мы выиграем мы немного процессорного времени… но зачем? Если в приложении есть страница где так много стилей что это начинает играть роль, то скорее всего проблема в самом коде. Если существующий код оправдан, то это уже очень специфичный кейс
2. Нет css, нет js. Есть компонент. Если правите что-то — то вы правите компонент. И его стоит загрузить заново.
Если у вас при правке компонента переобсирается css на 5МБ, то опять же это уже проблема организации кода.
2. Нет css, нет js. Есть компонент. Если правите что-то — то вы правите компонент. И его стоит загрузить заново.
Если у вас при правке компонента переобсирается css на 5МБ, то опять же это уже проблема организации кода.
Сокращать имена классов нет смысла github.com/webpack-contrib/css-loader/issues/406
Спасибо, вот это я понимаю — инженерный подход!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Готовим идеальный CSS