Comments 25
Если не ошибаюсь, то cra2 уже содержит стайл-лоадеры и там эта работа уже не нужна
На счет длинных названий и так ясно. Писать слишком длинные не стоит, но «e_f», «e_g»,«e_h» — это норм названия для классов? эм… Не уверен, что другой разработчик без 100 грамм разберется что к чему.
UFO just landed and posted this here
А ничего, что при передаче чего-либо по HTTPS компрессия считается уязвимостью и отключается (по крайней мере в TLS1.2)? Гэзипуй не гэзипуй… А автор, похоже, всего лишь занялся минификацией css, причем в виде кода, которым из dev-css делается детерминированный prod_css с сохранением имен стилей и файлов. И это здорово.
Уязвимость, насколько я помню, связана со сжатием на уровне TLS. К данным уровня приложения, которые бегают внутри TLS-соединения (т.е. к HTTP и его Content-Encoding:gzip) эта проблема отношения не имеет.
Насколько я помню, сжатие работало как фактор, позволяющий за счет того, что куки и запрос передаются в одном пакете, угадывать куки по частям по размеру запроса с использованием очень большого количества запросов с частью контролируемого контента. И на тот момент единственным средством заставить браузер передавать несжатый запрос (с куками) был отключить сжатие на TLS как класс.
UFO just landed and posted this here
"Если скотч не помогает, значит нужно больше скотча."
Вот еще немного и 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
Спасибо, вот это я понимаю — инженерный подход!
Sign up to leave a comment.
Готовим идеальный CSS