Привет Хабр!

Не так давно я понял, что работа с CSS во всех моих приложениях — это боль для разработчика и пользователя.

Под катом лежат мои проблемы, куча странного кода и подводные камни на пути к правильной работе со стилями.


Проблемный CSS


В проектах на React и Vue, которые я делал, подход к стилям был примерно одинаковым. Проект собирается webpack'ом, из главной точки входа импортируется один CSS файл. Этот файл импортирует внутри себя остальные CSS файлы, которые используют БЭМ для наименования классов.

styles/
  indes.css
  blocks/
    apps-banner.css
    smart-list.css
    ...

Знакомо? Такую реализацию я использовал почти везде. И все было хорошо, пока один из сайтов не разросся до такого состояния, что проблемы со стилями начали сильно мозолить мне глаза.

1. Проблема hot-reload’а
Импортирование стилей друг из друга происходило через плагин postcss или stylus-loader.
Загвоздка вот в чем:

Когда мы решаем импорты через плагин postcss или stylus-loader, на выходе получается один большой CSS файл. Теперь даже при незначительном изменении одного из файлов стилей все CSS файлы будут обработаны заново.

Это здорово убивает скорость hot-reload’a: обработка ~950 Кбайт stylus-файлов занимает у меня около 4 секунд.

Заметка про css-loader
Если бы импорт CSS файлов решался через css-loader, такой проблемы бы не возникло:
css-loader превращает CSS в JavaScript. Он заменит все импорты стилей на require. Тогда изменение одного CSS файла не будет затрагивать другие файлы и hot-reload произойдет быстро.

До css-loader’a

/* main.css */

@import './test.css';

html, body {
  margin: 0;
  padding: 0;
  width: 100%;
  height: 100%;
}

body {
  /* background-color: #a1616e; */
  background-color: red;
}

После

/* main.css */

// imports
exports.i(require("-!../node_modules/css-loader/index.js!./test.css"), "");

// module
exports.push([module.id, "html, body {\n  margin: 0;\n  padding: 0;\n  width: 100%;\n  height: 100%;\n}\n\nbody {\n  /* background-color: #a1616e; */\n  background-color: red;\n}\n", ""]);

// exports


2. Проблема code-splitting’а

Когда стили подгружаются из отдельной папки, мы не знаем контекст использования каждого из них. С таким подходом никак не получится разбить CSS на несколько частей и подгружать их по мере необходимости.

3. Большие названия CSS классов

Каждое имя БЭМ класса выглядит вот так: block-name__element-name. Такое длинное имя сильно влияет на финальный размер CSS файла: на сайте Хабра, например, названия CSS классов занимают 36% от размера файла стилей.

Google знает об этой проблеме и во всех своих проектах давно использует минификацию имен:

Кусочек сайта google.com

Кусочек сайта google.com

Меня порядком достали все эти проблемы, я наконец решил покончить с ними и добиться идеального результата.

Выбор решения


Для избавления от всех вышеперечисленных проблем я нашел два варианта решения: CSS In JS (styled-components) и CSS modules.

Критичных недостатков у этих решений я не увидел, но в конце концов мой выбор пал на CSS Modules из-за нескольких причин:

  • Можно вынести CSS в отдельный файл для раздельного кэширования JS и CSS.
  • Больше возможностей для линтеринга стилей.
  • Более привычно работать с CSS файлами.

Выбор сделан, пора начинать готовить!

Базовая настройка


Немного настроим конфигурацию webpack'а. Добавим css-loader и включим у него CSS Modules:

/* webpack.config.js */

module.exports = {
  /* … */
  module: {
    rules: [
      /* … */
      {
        test: /\.css$/,
        use: [
          'style-loader',
          {
            loader: 'css-loader',
            options: {
              modules: true,
            }
          },
        ],
      },
    ],
  },
};

Теперь раскидаем CSS файлы по папкам с компонентами. Внутри каждого компонента импортируем нужные стили.

project/
  components/
    CoolComponent/
      index.js
      index.css

/* components/CoolComponent/index.css */

.contentWrapper {
  padding: 8px 16px;
  background-color: rgba(45, 45, 45, .3);
}

.title {
  font-size: 14px;
  font-weight: bold;
}

.text {
  font-size: 12px;
}

/* components/CoolComponent/index.js */

import React from 'react';
import styles from './index.css';

export default ({ text }) => (
  <div className={styles.contentWrapper}>
    <div className={styles.title}>
      Weird title
    </div>
    <div className={styles.text}>
      {text}
    </div>
  </div>
);

Теперь, когда мы разбили CSS файлы, hot-reload будет обрабатывать изменения только одного файла. Проблема №1 решена, ура!

Разбиваем CSS по чанкам


Когда в проекте много страниц, а клиенту нужна только одна из них, выкачивать все данные не имеет смысла. Для этого в React'е есть прекрасная библиотека react-loadable. Она позволяет создать компонент, который динамически выкачает нужный нам файл при необходимости.

/* AsyncCoolComponent.js */

import Loadable from 'react-loadable';
import Loading from 'path/to/Loading';

export default Loadable({
  loader: () => import(/* webpackChunkName: 'CoolComponent' */'path/to/CoolComponent'),
  loading: Loading,
});

Webpack превратит компонент CoolComponent в отдельный JS файл (чанк), который скачается, когда будет отрендерен AsyncCoolComponent.

При этом, CoolComponent содержит свои собственные стили. CSS лежит пока в нем как JS строка и вставляется как стиль с помощью style-loader'a.? Но почему бы нам не вырезать стили в отдельный файл?

Сделаем так, чтобы и для главного файла, и для каждого из чанков создался свой собственный CSS файл.

Устанавливаем mini-css-extract-plugin и колдуем с конфигурацией webpack'а:

/* webpack.config.js */

const MiniCssExtractPlugin = require('mini-css-extract-plugin');

const isDev = process.env.NODE_ENV === 'development';

module.exports = {
  /* ... */
  module: {
    rules: [
      {
        /* ... */
        test: /\.css$/,
        use: [
          (isDev ? 'style-loader' : MiniCssExtractPlugin.loader),
          {
            loader: 'css-loader',
            options: {
              modules: true,
            },
          },
        ],
      },
    ],
  },
  plugins: [
    /* ... */
    ...(isDev ? [] : [
      new MiniCssExtractPlugin({
        filename: '[name].[contenthash].css',
        chunkFilename: '[name].[contenthash].css',
      }),
    ]),
  ],
};

Вот и все! Соберем проект в production режиме, откроем браузер и посмотрим вкладку network:

// Выкачались главные файлы
GET /main.aff4f72df3711744eabe.css
GET /main.43ed5fc03ceb844eab53.js

// Когда CoolComponent понадобился, подгрузился необходимый JS и CSS
GET /CoolComponent.3eaa4773dca4fffe0956.css
GET /CoolComponent.2462bbdbafd820781fae.js

С проблемой №2 покончено.

Минифицируем CSS классы


Css-loader изменяет внутри себя названия классов и возвращает переменную с отображением локальных имен классов в глобальные.

После нашей базовой настройки, css-loader генерирует длинный хеш на основе имени и местоположения файла.

В браузере наш CoolComponent выглядит сейчас так:

<div class="rs2inRqijrGnbl0txTQ8v">
  <div class="_2AU-QBWt5K2v7J1vRT0hgn">
    Weird title
  </div>
  <div class="_1DaTAH8Hgn0BQ4H13yRwQ0">
    Lorem ipsum dolor sit amet consectetur.
  </div>
</div>

Конечно, нам этого мало.

Необходимо, чтобы во время разработки были имена, по которым можно найти оригинальный стиль. А в production режиме должны минифицироваться имена классов.

Css-loader дает возможность кастомизировать изменение названий классов через опции localIdentName и getLocalIdent. В режиме разработки зададим описательный localIdentName — '[path]_[name]_[local]', а для production режима сделаем функцию, которая будет минифицировать названия классов:

/* webpack.config.js */

const getScopedName = require('path/to/getScopedName');
const isDev = process.env.NODE_ENV === 'development';

/* ... */

module.exports = {
  /* ... */
  module: {
    rules: [
      /* ... */
      {
        test: /\.css$/,
        use: [
          (isDev ? 'style-loader' : MiniCssExtractPlugin.loader),
          {
            loader: 'css-loader',
            options: {
              modules: true,
              ...(isDev ? {
                localIdentName: '[path]_[name]_[local]',
              } : {
                getLocalIdent: (context, localIdentName, localName) => (
                  getScopedName(localName, context.resourcePath)
                ),
              }),
            },
          },
        ],
      },
    ],
  },
};

/* getScopedName.js */
/* 
  Здесь лежит функция, 
  которая по имени класса и пути до CSS файла 
  вернет минифицированное название класса  
*/

// Модуль для генерации уникальных названий
const incstr = require('incstr');

const createUniqueIdGenerator = () => {
  const uniqIds = {};

  const generateNextId = incstr.idGenerator({
    // Буквы d нету, чтобы убрать сочетание ad,
    // так как его может заблокировать Adblock
    alphabet: 'abcefghijklmnopqrstuvwxyzABCEFGHJKLMNOPQRSTUVWXYZ',
  });

  // Для имени возвращаем его минифицированную версию
  return (name) => {
    if (!uniqIds[name]) {
      uniqIds[name] = generateNextId();
    }

    return uniqIds[name];
  };
};

const localNameIdGenerator = createUniqueIdGenerator();
const componentNameIdGenerator = createUniqueIdGenerator();

module.exports = (localName, resourcePath) => {
  // Получим название папки, в которой лежит наш index.css
  const componentName = resourcePath
    .split('/')
    .slice(-2, -1)[0];

  const localId = localNameIdGenerator(localName);
  const componentId = componentNameIdGenerator(componentName);

  return `${componentId}_${localId}`;
};

И вот у нас при разработке красивые наглядные имена:

<div class="src-components-ErrorNotification-_index_content-wrapper">
  <div class="src-components-ErrorNotification-_index_title">
    Weird title
  </div>
  <div class="src-components-ErrorNotification-_index_text">
    Lorem ipsum dolor sit amet consectetur.
  </div>
</div>

А в production минифицированные классы:

<div class="e_f">
  <div class="e_g">
    Weird title
  </div>
  <div class="e_h">
    Lorem ipsum dolor sit amet consectetur.
  </div>
</div>

Третья проблема преодолена.

Убираем ненужную инвалидацию кэшей


Используя технику минификации классов, описанную выше, попробуйте собрать проект несколько раз. Обратите внимание на кэши файлов:

/* Первая сборка */
app.bf70bcf8d769b1a17df1.js
app.db3d0bd894d38d036117.css

/* Вторая сборка */
app.1f296b75295ada5a7223.js
app.eb2519491a5121158bd2.css

Похоже, после каждой новой сборки у нас инвалидируются кэши. Как же так?

Проблема в том, что webpack не гарантирует порядок обработки файлов. То есть CSS файлы будут обработаны в непредсказуемом порядке, для одного и того же имени класса при разных сборках будут сгенерированы разные минифицированные имена.

Чтобы победить эту проблему, давайте сохранять данные о сгенерированных именах классов между сборками. Чуть-чуть обновим файл getScopedName.js:

/* getScopedName.js */

const incstr = require('incstr');

// Импортируем две новых функции
const {
  getGeneratorData,
  saveGeneratorData,
} = require('./generatorHelpers');


const createUniqueIdGenerator = (generatorIdentifier) => {
  // Восстанавливаем сохраненные данные
  const uniqIds = getGeneratorData(generatorIdentifier);

  const generateNextId = incstr.idGenerator({
    alphabet: 'abcefghijklmnopqrstuvwxyzABCEFGHJKLMNOPQRSTUVWXYZ',
  });

  return (name) => {
    if (!uniqIds[name]) {
      uniqIds[name] = generateNextId();

      // Сохраняем данные каждый раз,
      // когда обработали новое имя класса
      // (можно заменить на debounce для оптимизации)
      saveGeneratorData(generatorIdentifier, uniqIds);
    }

    return uniqIds[name];
  };
};

// Создаем генераторы с уникальными идентификаторами,
// чтобы для каждого из них можно было сохранить данные
const localNameIdGenerator = createUniqueIdGenerator('localName');
const componentNameIdGenerator = createUniqueIdGenerator('componentName');

module.exports = (localName, resourcePath) => {
  const componentName = resourcePath
    .split('/')
    .slice(-2, -1)[0];

  const localId = localNameIdGenerator(localName);
  const componentId = componentNameIdGenerator(componentName);

  return `${componentId}_${localId}`;
};


Реализация файла generatorHelpers.js не имеет большого значения, но если интересно, вот моя:

generatorHelpers.js
const fs = require('fs');
const path = require('path');

const getGeneratorDataPath = generatorIdentifier => (
  path.resolve(__dirname, `meta/${generatorIdentifier}.json`)
);

const getGeneratorData = (generatorIdentifier) => {
  const path = getGeneratorDataPath(generatorIdentifier);

  if (fs.existsSync(path)) {
    return require(path);
  }

  return {};
};

const saveGeneratorData = (generatorIdentifier, uniqIds) => {
  const path = getGeneratorDataPath(generatorIdentifier);
  const data = JSON.stringify(uniqIds, null, 2);

  fs.writeFileSync(path, data, 'utf-8');
};

module.exports = {
  getGeneratorData,
  saveGeneratorData,
};


Кэши стали одинаковыми между сборками, все прекрасно. Еще одно очко в нашу пользу!

Убираем переменную рантайма


Раз уж я решил сделать лучшее решение, было бы неплохо убрать эту переменную с отображением классов, у нас ведь есть все необходимые данные на этапе компиляции.

С этим нам поможет babel-plugin-react-css-modules. Во время компиляции он:

  1. Найдет в файле импортирование CSS.
  2. Откроет этот CSS файл и изменит имена CSS классов также, как это делает css-loader.
  3. Найдет JSX узлы с аттрибутом styleName.
  4. Заменит локальные имена классов из styleName на глобальные.

Настроим этот плагин. Поиграемся с babel-конфигурацией:

/* .babelrc.js */

// Функция минификации имен, которую мы написали выше
const getScopedName = require('path/to/getScopedName');

const isDev = process.env.NODE_ENV === 'development';

module.exports = {
  /* ... */
  plugins: [
    /* ... */ 
    ['react-css-modules', {
      generateScopedName: isDev ? '[path]_[name]_[local]' : getScopedName,
    }],
  ],
};

Обновим наши JSX файлы:

/* CoolComponent/index.js */

import React from 'react';
import './index.css';

export default ({ text }) => (
  <div styleName="content-wrapper">
    <div styleName="title">
      Weird title
    </div>
    <div styleName="text">
      {text}
    </div>
  </div>
);

И вот мы перестали использовать переменную с отображением названий стилей, теперь ее у нас нет!

… Или есть?

Соберем проект и изучим исходники:
/* main.24436cbf94546057cae3.js */

/* … */
function(e, t, n) {
  e.exports = {
    "content-wrapper": "e_f",
    title: "e_g",
    text: "e_h"
  }
}
/* … */

Похоже, переменная все еще осталась, хотя она нигде не используется. Почему так произошло?

В webpack'е поддерживается несколько видов модульной структуры, самые популярные — это ES2015 (import) и commonJS (require).

Модули ES2015, в отличие от commonJS, поддерживают tree-shaking за счет своей статичной структуры.

Но и css-loader, и лоадер mini-css-extract-plugin используют синтаксис commonJS для экспортирования названий классов, поэтому экспортируемые данные не удаляются из билда.

Напишем свой маленький лоадер и удалим лишние данные в production режиме:

/* webpack.config.js */

const path = require('path');
const resolve = relativePath => path.resolve(__dirname, relativePath);

const isDev = process.env.NODE_ENV === 'development';

module.exports = {
  /* ... */
  module: {
    rules: [
      /* ... */
      {
        test: /\.css$/,
        use: [
          ...(isDev ? ['style-loader'] : [
            resolve('path/to/webpack-loaders/nullLoader'),
            MiniCssExtractPlugin.loader,
          ]),
          {
            loader: 'css-loader',
            /* ... */
          },
        ],
      },
    ],
  },
};

/* nullLoader.js */

// Превращаем любой файл в файл, содержащий комментарий
module.exports = () => '// empty';

Проверяем собранный файл еще раз:

/* main.35f6b05f0496bff2048a.js */

/* … */
function(e, t, n) {}
/* … */

Можно выдохнуть с облегчением, все сработало.

Неудачная попытка удалить переменную с отображением классов
Вначале наиболее очевидным мне показалось использовать уже существующий пакет null-loader.

Но все оказалось не так просто:

/* Исходники null-loader */

export default function() {
  return '// empty (null-loader)';
}

export function pitch() {
  return '// empty (null-loader)';
}

Как видно, помимо основной функции, null-loader экспортирует еще и функцию pitch. Из документации я узнал, что pitch методы вызываются раньше остальных и могут отменить все последующие лоадеры, если вернут из этого метода какие-то данные.

С null-loader'ом последовательность production процессинга CSS начинает выглядеть так:

  • Вызывается метод pitch у null-loader'a, который возвращает пустую строку.
  • Из-за того, что pitch метод вернул значение, все последующие лоадеры не вызываются.

Решений я больше не увидел и решил сделать свой лоадер.

Использование со Vue.js
Если у вас под рукой есть только один Vue.js, но очень хочется сжать названия классов и убрать переменную рантайма, то у меня есть отличный хак!

Все, что нам понадобится — это два плагина: babel-plugin-transform-vue-jsx и babel-plugin-react-css-modules. Первый нам понадобится для того, чтобы писать JSX в рендер функциях, а второй, как вам уже известно — для генерации имен на этапе компиляции.

/* .babelrc.js */

module.exports = {
  plugins: [
    'transform-vue-jsx',
    ['react-css-modules', {
      // Кастомизируем отображение аттрибутов
      attributeNames: {
        styleName: 'class',
      },
    }],
  ],
};

/* Пример компонента */

import './index.css';

const TextComponent = {
  render(h) {
    return(
      <div styleName="text">
        Lorem ipsum dolor.
      </div>
    );
  },

  mounted() {
    console.log('I\'m mounted!');
  },
};

export default TextComponent;



Сжимаем CSS по полной


Представьте, в проекте появился такой CSS:
/* Стили первого компонента */
.component1__title {
    color: red;
}

/* Стили второго компонента */
.component2__title {
    color: green;
}

.component2__title_red {
    color: red;
}

Вы — CSS минификатор. Как бы вы его сжали?

Я думаю, ваш ответ примерно такой:

.component2__title{color:green}
.component2__title_red, .component1__title{color:red}

Теперь проверим, что сделают обычные минификаторы. Засунем наш кусок кода в какой-нибудь online минификатор:

.component1__title{color:red}
.component2__title{color:green}
.component2__title_red{color:red}

Почему он не смог?

Минификатор боится, что из-за смены порядка объявления стилей у вас что-то поломается. Например, если в проекте будет такой код:

<div class="component1__title component2__title">Some weird title</div>

Из-за вас заголовок станет красным, а онлайн минификатор оставит правильный порядок объявления стилей и у него он будет зеленым. Конечно, вы знаете, что пересечения component1__title и component2__title никогда не будет, они ведь находятся в разных компонентах. Но как сказать об это минификатору?

Порыскав по документациям, возможность указания контекста использования классов я нашел только у csso. Да и у того нет удобного решения для webpack'а из коробки. Чтобы ехать дальше, нам понадобится небольшой велосипед.

Нужно объединить имена классов каждого компонента в отдельные массивы и отдать внутрь csso. Чуть ранее мы генерировали минифицированные названия классов по такому паттерну: '[componentId]_[classNameId]'. А значит, имена классов можно объединить просто по первой части имени!

Пристегиваем ремни и пишем свой плагин:

/* webpack.config.js */

const cssoLoader = require('path/to/cssoLoader');
/* ... */

module.exports = {
  /* ... */
  plugins: [
    /* ... */
    new cssoLoader(),
  ],
};

/* cssoLoader.js */

const csso = require('csso');
const RawSource = require('webpack-sources/lib/RawSource');
const getScopes = require('./helpers/getScopes');

const isCssFilename = filename => /\.css$/.test(filename);

module.exports = class cssoPlugin {
  apply(compiler) {
    compiler.hooks.compilation.tap('csso-plugin', (compilation) => {
      compilation.hooks.optimizeChunkAssets.tapAsync('csso-plugin', (chunks, callback) => {
        chunks.forEach((chunk) => {
          // Пробегаемся по всем CSS файлам
          chunk.files.forEach((filename) => {
            if (!isCssFilename(filename)) {
              return;
            }

            const asset = compilation.assets[filename];
            const source = asset.source();

            // Создаем ast из CSS файла
            const ast = csso.syntax.parse(source);

            // Получаем массив массивов с объединенными именами классов
            const scopes = getScopes(ast);

            // Сжимаем ast
            const { ast: compressedAst } = csso.compress(ast, {
              usage: {
                scopes,
              },
            });
            const minifiedCss = csso.syntax.generate(compressedAst);

            compilation.assets[filename] = new RawSource(minifiedCss);
          });
        });

        callback();
      });
    });
  }
}

/* Если хочется поддержки sourceMap, асинхронную минификацию и прочие приятности, то их реализацию можно подсмотреть тут https://github.com/zoobestik/csso-webpack-plugin"  */

/* getScopes.js */
/*
  Тут лежит функция,
  которая объединяет названия классов в массивы
  в зависимости от компонента, к которому класс принадлежит
*/

const csso = require('csso');

const getComponentId = (className) => {
  const tokens = className.split('_');

  // Для всех классов, названия которых
  // отличаются от [componentId]_[classNameId],
  // возвращаем одинаковый идентификатор компонента
  if (tokens.length !== 2) {
    return 'default';
  }

  return tokens[0];
};

module.exports = (ast) => {
  const scopes = {};

  // Пробегаемся по всем селекторам классов
  csso.syntax.walk(ast, (node) => {
    if (node.type !== 'ClassSelector') {
      return;
    }

    const componentId = getComponentId(node.name);

    if (!scopes[componentId]) {
      scopes[componentId] = [];
    }

    if (!scopes[componentId].includes(node.name)) {
      scopes[componentId].push(node.name);
    }
  });

  return Object.values(scopes);
};

А это было не так уж и сложно, правда? Обычно, такая минификация дополнительно сжимает CSS на 3-6%.

Стоило ли оно того?


Конечно.

В моих приложениях наконец появился быстрый hot-reload, а CSS стал разбиваться по чанкам и весить в среднем на 40% меньше.

Это ускорит загрузку сайта и уменьшит время парсинга стилей, что окажет влияние не только на пользователей, но и на СЕО.

Статья сильно разрослась, но я рад, что кто-то смог доскроллить ее до конца. Спасибо, что уделили время!


Использованные материалы


Комментарии (24)


  1. sinneren
    23.11.2018 10:58

    Если не ошибаюсь, то cra2 уже содержит стайл-лоадеры и там эта работа уже не нужна


  1. Madeas
    23.11.2018 10:59
    -1

    На счет длинных названий и так ясно. Писать слишком длинные не стоит, но «e_f», «e_g»,«e_h» — это норм названия для классов? эм… Не уверен, что другой разработчик без 100 грамм разберется что к чему.


    1. AndreasCag Автор
      23.11.2018 11:11

      Это только в проде, дев режим имеет понятные названия.
      Не думаю, что разработчику придется часто смотреть на такие классы.


    1. peresada
      23.11.2018 11:43
      +1

      прочитайте про «обфускацию»


  1. ArsenAbakarov
    23.11.2018 11:00

    Сделайте gzip своих css, тогда и сравнивайте размер.
    В рамках БЭМ проблем с импортированием стилей быть не должно, блок — модульная сущность.
    В вебпаке в каждом компоненте подгружаете нужные стили для него, если нужно из клиента асинхронно тянуть, тяните асинхронно весь компонент.
    Ну про нейминг вообще даже не знаю что сказать, искорявить имена можно и в изначальном решении.
    Лично я бы не стал с этим заморачиваться, ну разве сократить время сборки…


    1. vesper-bot
      23.11.2018 11:52
      -1

      А ничего, что при передаче чего-либо по HTTPS компрессия считается уязвимостью и отключается (по крайней мере в TLS1.2)? Гэзипуй не гэзипуй… А автор, похоже, всего лишь занялся минификацией css, причем в виде кода, которым из dev-css делается детерминированный prod_css с сохранением имен стилей и файлов. И это здорово.


      1. powerman
        23.11.2018 12:14
        +4

        Уязвимость, насколько я помню, связана со сжатием на уровне TLS. К данным уровня приложения, которые бегают внутри TLS-соединения (т.е. к HTTP и его Content-Encoding:gzip) эта проблема отношения не имеет.


        1. vesper-bot
          26.11.2018 11:11

          Насколько я помню, сжатие работало как фактор, позволяющий за счет того, что куки и запрос передаются в одном пакете, угадывать куки по частям по размеру запроса с использованием очень большого количества запросов с частью контролируемого контента. И на тот момент единственным средством заставить браузер передавать несжатый запрос (с куками) был отключить сжатие на TLS как класс.


      1. ArsenAbakarov
        23.11.2018 12:33
        +2

        «Гэзипуй не гэзипуй…» оО, да ладно, пруфы хочу!


  1. powerman
    23.11.2018 12:15

    "Если скотч не помогает, значит нужно больше скотча."


  1. savostin
    23.11.2018 12:24

    Вот еще немного и html/js/css станут обычным исполняемым файлом ;)


  1. agentx001
    23.11.2018 13:25
    +3

    В Single File Components Vue.js нет никакого смысла использовать БЭМ, есть же scoped режим у стилей


    1. ArsenAbakarov
      24.11.2018 21:27
      +1

      мне у БЭМ нравится модель уровней переопределения


  1. arheops
    23.11.2018 13:25

    Такое сокращение ничего не меняет, кроме уменьшения читаемости.
    После gzip будет одинаковый практически размер.
    А передавать стили без gzip в 2018году это гон.


  1. vintage
    23.11.2018 15:10

    обработка ~950 Кбайт stylus-файлов занимает у меня около 4 секунд.

    Ваша проблема определённо не в длине селекторов. Что вы там понаписали аж на мегабайт CSS? Меньше копипастить/кодогенерировать/подключатьчтопопало не пробовали?


    1. AndreasCag Автор
      23.11.2018 15:47

      После минификации ~300 Кбайт, обычный размер для старого сайта с кучей страниц (примерно столько сейчас на сайте хабра).
      Без копипасты/кодогенерации/подключениячтопопало.


      1. vintage
        23.11.2018 16:51
        +1

        Даже на Хабре 270кб без минификации. И то, Хабр — так себе пример для подражания.


        1. AndreasCag Автор
          23.11.2018 16:56
          -1

          Советую посмотреть, чем отличается минификация от сжатия данных.


          1. vintage
            23.11.2018 19:26

            И 44кб со сжатием. Вы девтулзами пользоваться умеете?


  1. ElianL
    24.11.2018 13:54

    Можно вынести CSS в отдельный файл для раздельного кэширования JS и CSS


    А зачем вобоще кешировать js и сss отдельно? Компонент это не js и не css, это все вместе. Разбиваем на чанки — кешируем чанки.


    1. AndreasCag Автор
      24.11.2018 19:34

      По причинам:
      1. Когда CSS лежит как строка в JS, то тогда пайплайн использования стилей выглядит так:
      — Строка стилей обрабатывается JS парсером
      — С помощью дополнительных JS функций она обрабатывается и вставляется как style элемент
      — Стиль обрабатывается CSS парсером

      Если используется CSS файл, то первые 2 шага отпадают.

      2. Если вдруг надо поправить что-то, кроме верстки, то кэши CSS останутся одинаковыми и юзеры не выкачают лишние данные.


      1. ElianL
        25.11.2018 19:03

        1. Мы выиграем мы немного процессорного времени… но зачем? Если в приложении есть страница где так много стилей что это начинает играть роль, то скорее всего проблема в самом коде. Если существующий код оправдан, то это уже очень специфичный кейс

        2. Нет css, нет js. Есть компонент. Если правите что-то — то вы правите компонент. И его стоит загрузить заново.
        Если у вас при правке компонента переобсирается css на 5МБ, то опять же это уже проблема организации кода.


  1. alexesDev
    26.11.2018 13:32

    Сокращать имена классов нет смысла github.com/webpack-contrib/css-loader/issues/406


  1. Tankerxyz
    26.11.2018 15:15
    +1

    Спасибо, вот это я понимаю — инженерный подход!