Polymer SVG Iconset и производительность с несколькими одинаковыми значками - PullRequest
0 голосов
/ 09 ноября 2018

Я использую полимерный набор иконок svg и элемент iron-icon на своей странице. Допустим, у меня есть большое количество строк в таблице, и в каждой строке есть несколько значков (используется iron-icon). Эти значки повторяются в каждом ряду. Когда я проверяю DOM, я вижу, что каждый железный значок в каждой строке имеет тот же значок svg, что и часть DOM (внутри теневого корня icon-icon). Разве это не узкое место в производительности? IE11 медленно разбирает DOM, и это может вызвать дальнейшую медлительность. Будет ли здесь оптимизирован набор значков шрифтов? Правильный ли подход Polymer по использованию набора иконок SVG?

1 Ответ

0 голосов
/ 09 ноября 2018

По моему опыту, проблема не в размере самого DOM, а в JS API взаимодействии с ним.Способ, которым Polymer реализует значки, он действует как полизаполнение для пользовательских элементов веб-компонентов.Что на самом деле происходит в старых браузерах, которые не понимают их декларации, так это то, что если вы пишете

<iron-icon icon="search"></iron-icon>

, сценарии, циклически проходящие через DOM, заменяют то, что считается неизвестными элементами, на элементы DOM, которые понимает браузер (заглянуть в инспектор DOM, чтобы увидеть, что на самом деле используется в определенном браузере).

Более прямым подходом может быть использование чего-то, что IE изначально понимает, например шаблон SVG-спрайта.Включите невидимый <svg> элемент, содержащий символы

 <svg display="none">
     <symbol id="search" viewBox="..."><path d="..." /></symbol>
     ...
 </svg>

и ссылки на них

<svg class="icon"><use xlink:href="#search"/></svg>

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

Даже если ваши ячейки таблицы построены на стороне клиента, добавление этих элементов непосредственно в DOM может все же быть быстрее, чем первое добавление чего-то, что скрипт должен заменить позже.во второй раз.(Но это только мое предположение без опыта, чтобы подтвердить это.)

...