Кто сталкивался с нарушением как принудительная перерисовка при выполнении JavaScript сценария в DOM?

Question

[Денис]

Есть таблица в стиле CSS grid со стилями. Которая имеет 12 колонок. Из них на экране только 11, а 12-я спрятана слева за пределами монитора в качестве дополнительного меню для строки (заявки). Всего 100vw (что видно сразу) плюс 100vw (меню) минус 1-я колонка (тип заявки). Т.е. всего, если говорит грубо, то 100% + 100% - 40px. Но экран показывает только 100%, а остальное умно спрятано с помощью overflow-x: hidden, так что ничего не вылезает.
По мнению автора, при десктопном разрешении должно эмулироваться что-то типа свайпа на мобильном, в тот момент когда пользователь тянет блок с типом заявки слева направо и, в случае закрытия, наоборот - справа налево.
При реализации возникла проблема в том, что появляется запись о нарушении:

[Violation] Forced reflow while executing JavaScript took ..ms

В динамике пользователь может добавлять сколько угодно строк (выбор и показ заявок). Чем больше строк, тем больше увеличивается время на принудительную перерисовку для DOM-элементов.

[Violation] 'mousemove' handler took 442ms
[Violation] Forced reflow while executing JavaScript took 439ms
[Violation] 'mousemove' handler took 1520ms

Пример:
CodePen

Помогите разобраться почему так происходит.

Comments

[Алексей Ярков]

принудительная перепрошивка при выполнении JavaScript

Принудительная КТО?

[Денис]

Алексей Ярков, Скрины экрана все сверху + цитировал же. Все описано.
Переформатирование, если Вам так будет угодно.

[Kovalsky]

Алексей Ярков, типа перерисовка

Answer 1

[Kovalsky]

Отвечая на вопрос "почему так происходит?": потому что у вас реализован достаточно сложный грид со сложными условиями, к элементам которого вы еще динамически применяете какие-то кастомные стили (конкретно речь о сдвиге), вынуждающие движок перерисовывать всё-всё-всё - как элементы после целевого, так и до. Решение - либо не юзать грид (не знаю насколько это адекватный выход), либо (что мне кажется более адекватным) реализовать сдвиг как-нибудь по-другому. Например сгруппировать ячейки в строки, и двигать уже эти строки, попутно не влияя на другие элементы; это полностью решит проблему тотальной перерисовки.

Еще можно попытаться оптимизировать уже имеющийся код, ибо в нем дофига лишнего, но по сути это проблемы не решит.

Comments

[Денис]

Спасибо за ответ, поразмышляю как оптимизировать производительность.

[Денис]

Все равно, не могу понять, он же не перерисовывает всё-всё-всё, как Вы написали, а только то, что ему указали, что видно в консоли во вкладке elements...
По логике, если это связано со смещением элементов в документе, у нас много строк на странице, мы изменяем пред/последнюю, то почему должно все перестроится, мы ведь верхние строки не затронули?
Время на задержку приблизительно будет одинаково при равной длине строк на страницу. И не важно откуда свайпать, сверху (1-я заявка) или снизу (последняя заявка). При 100 строк предупреждений нет, а при 1000 появляется!
Если даже в ф-цию-обработчик написать сверхлегкий код, например, скрытие элемента с типом заявки :

async function clickSub(e) {
  e.preventDefault();
    $(this).hide(50);
  }

то при меньших выводимых объемах (до 100 строк на странице) никаких нарушений-предупреждений не будет, но если количество строк увеличить на порядок (уже 1000 строк на странице), то в консоль посыпятся предупреждения о перерисовке. Т.е. чем больше строк, тем больше задержка?
И чем больше элементов я задействую, тем больше задержка? Например, не один элемент, а + еще 5-ть соседних буду скрывать?
Может это еще зависит от загружаемой памяти? Может где-то, что-то увеличить, если такое возможно?
Резюме. Сложилось мнение, что чем больше выводимых строк на странице, тем больше по времени задержки.
Но, блин, 1000 строк это разве много на странице?

[Kovalsky]

Денис, "мы изменяем пред/последнюю, то почему должно все перестроится, мы ведь верхние строки не затронули?" - потому что у вас грид состоит из кучи мелких элементов, которые кроме того что нужно организовать в строки вдобавок надо ещё им посчитать размеры. Я не могу полноценно ответить на этот вопрос просто потому что мне лень тратить время на поиск конкретных причин. Думаю на вашем уровне понимания происходящего достаточно принять как факт, что не стоит использовать грид так как это сделано у вас в примере. Я бы даже его переписал, просто по фану. Это не очень много времени займёт.

"Т.е. чем больше строк, тем больше задержка?" - ну да, это же логично. О том ведь и речь: у вас грид сделан так, что ему приходится пересчитывать всё всё всё.

"Но, блин, 1000 строк это разве много на странице?" - что вы хотите услышать в ответ? 1000 строк текста - нет; 1000 строк загрузки разнообразных скриптов - да. Как видите, по факту получается что у вас грид так херово работает, что 1000 это таки действительно много

[Денис]

В Grid-структуре ничего сложного нет.

/*  Переменные */
  --typeColumn: 40px; /* Колонка с типом заявки */
  --action1: calc(100vw - var(--typeColumn));  /*  Боковой блок слева для дальнейших действий по заявке*/

   .wrapper {
      display: grid;
      position: relative;
      left: calc(0px - var(--action1));
      grid-template-columns: var(--action1) var(--typeColumn) 60px 60px 200px 56px 90px repeat(4, minmax(1%, 35%)) 40px;
      grid-auto-rows:  unset;
      width: calc(100vw + var(--action1));
    }

Про какие мелкие элементы Вы упоминали? 12 блоков в строке и все! После идет еще 12 блоков (следующая строка) и т.д.
Т.е. при построении любой сетки grid, если пользователь будет анимировать (допустим, прятать) один из элементов (блок) в структуре, то вся сетка будет перерисована? Спорить не буду, не уверен, но что-то мне подсказывает, что это нонсенс...

[Kovalsky]

Денис, "В Grid-структуре ничего сложного нет." - ну да, ничего сложного кроме той части кода которую вы привели: куча расчётов, сложные шаблоны с обязательным разрешением переменных, относительные величины. Плюс к этому еще адаптив и сама по себе сложная структура. И анимация сверху чугунной наковальней падает на это всё.

"Про какие мелкие элементы Вы упоминали? 12 блоков в строке и все! После идет еще 12 блоков (следующая строка) и т.д." - у вас грид состоит из кучи мелких элементов. Я сделал пару тысяч блоков и всё - стало жутко тормозить,

"при построении любой сетки grid, если пользователь будет анимировать (допустим, прятать) один из элементов (блок) в структуре, то вся сетка будет перерисована?" - конечно нет. Это конкретно в вашем случае грид организован так хреново, что ему приходится всё перерисовывать. Я тоже спорить не буду, я просто показал на очевидные узкие места. Сгруппируйте строки, это решит проблему.

[Денис]

Kovalsky,
Хорошо, ниже ссылка на статику в тестовом домене:
Пример
1. html-код на 1000 строк в 11 рядов (убрал первый ряд, хрен с ним, ничего прятать не буду);
2. css-код:

@media screen {
  * {
    font-family: 'Podkova', serif;
    font-size: 14px;
    margin: 0;
    padding: 0;
  }
}

/* стили для настольных компьютеров и ноутбуков */
@media only screen  and (min-width: 1080px) {
    
    .wrapper {
      display: grid;
      grid-template-columns: repeat(11, 1fr);
      background-color: #fff;
      border-right: 1px solid #e8e9eb; /* Линия справа от текста */
      border-bottom: 1px dotted #e8e9eb; /* Линия снизу от текста */
      word-wrap: break-word; /* Перенос слов */ 
    }
    
    .box {
    padding: 4px;
    color: #425b71;
    border-right: 1px solid #e8e9eb; /* Линия справа от текста */
    border-bottom: 1px dotted #e8e9eb; /* Линия снизу от текста */
    word-wrap: break-word; /* Перенос слов */ 
  }

  .box:nth-child(-n+11) {
      background-color: #1cc58ebd;
      color: #fff;
      font-weight: bold;
      border-right: 1px solid #fff;
      position: sticky;
      top: 0;
    }
}

Думаю, что проще некуда, никаких нагромождений нет! Стили

3. JS-код (самый простой), при клике по типу скрываем соседний элемент:

$('body').on("click", ".j", function(e) {
		e.preventDefault();
		$(this).next().hide(50);
	});

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

Так о каких расчетах идет речь? Сложный шаблон с переменными? Сложная анимация? В каком конкретном случае? Как хреново?
На мой взгляд, проще уже некуда!
И....

[Violation] Forced reflow while executing JavaScript took ...ms

[Kovalsky]

Денис, ну да, теперь всё достаточно просто, минимум логики. Но суть не меняется - по клику вы скрываете ячейку грида, а так как от изменений в одной части грида может меняться что-то в другой части (независимо от того в каком месте грида происходит изменение), то пересчитывать грид приходится полностью.

В вашей ситуации грид вообще не нужен, это слишком сложный инструмент для решаемой вами задачи. В любом случае, независимо от того каким крутым инструментом вы пользуетесь, организовывать огромную таблицу из неадекватно длинной последовательности элементов - само по себе идея дурацкая. Попробуйте как-минимум сгруппировать ячейки в строки.

[Денис]

Kovalsky,
Если их сгруппировать в строки, то каждая строка будет оцениваться/выводиться независимо друг от друга. Столбец может быть не выровнен относительно столбца выше из-за разного объёма содержимого. Так оно и происходит. А если попробовать использовать конструкцию display: contents;
если преобразовать код и нативно прописать их как вложенные элементы? Тогда прямые дочерние элементы будут частью сетки или гибкого макета.
Статья по этому поводу.
Насколько мне извесно, пока не все браузеры поддерживаю конструкцию display: subgrid;
Пробую переписать код, возможно поможет.

[Денис]

Kovalsky, решил вопрос просто, без всяких display: contents.
Разбил на строки:

/* стили для настольных компьютеров и ноутбуков */
@media only screen  and (min-width: 1080px) {
    
  .wrapper > div {
    display: grid;
    grid-template-columns: 40px 100px repeat(8, 1fr) 40px;
    grid-template-rows: unset;
    border-bottom: 1px solid #e8e9eb; /* Линия снизу от текста */
    word-wrap: break-word; /* Перенос слов */
    column-gap: 10px;
  }

  .wrapper > div:first-child {
    background: #1cc58e;
    color: #fff;
    height: 30px;
    position: sticky;
    top:0px;
  } 
  
  .wrapper > div:not(:first-child):nth-child(odd) {
    background: #dedede;
  }

}

Сперва думал, что вертикального выравнивания по столбцам не будет, но оказалось, что все в порядке! Столбцы ровные.
Получается, что при любом изменении grid-сетки, вся структура перерисовывается! Чем больше сетка, тем, соответственно, хуже. Отсюда задержки при больших объемах. но если каждой строке (блоку) указывать свой grid, то проблема исчезает! Теперь хоть 1000 строк, хоть 20 000, все без задержек.