Продуктивність MutationObserver для виявлення вузлів у всій DOM

Question 1

Я зацікавлений у використанні MutationObserverдля виявлення, чи додано певний елемент HTML де-небудь на сторінці HTML. Для прикладу, я скажу, що хочу виявити, чи <li>є де-небудь додані де-небудь у DOM.

Усі MutationObserverприклади, які я бачив досі, виявляють лише додавання вузла до певного контейнера. Наприклад:

трохи HTML

<body>

  ...

  <ul id='my-list'></ul>

  ...

</body>

MutationObserver визначення

var container = document.querySelector('ul#my-list');

var observer = new MutationObserver(function(mutations){
  // Do something here
});

observer.observe(container, {
  childList: true,
  attributes: true,
  characterData: true,
  subtree: true,
  attributeOldValue: true,
  characterDataOldValue: true
});

Отже, у цьому прикладі програма MutationObserverналаштована на перегляд певного контейнера ( ul#my-list), щоб побачити, чи <li>до нього додано якийсь .

Це проблема, якщо я хотів би бути менш конкретним , і стежити за <li>всіма телами HTML, як це:

var container = document.querySelector('body');

Я знаю, що це працює в основних прикладах, які я налаштував для себе ... Але чи не рекомендується це робити? Це призведе до поганої роботи? І якщо так, то як я можу виявити та виміряти цю проблему продуктивності?

Я зрозумів, що, можливо, була причина, що всі MutationObserverприклади настільки конкретні з цільовим контейнером ... але я не впевнений.

Question 2

Ця відповідь насамперед стосується великих та складних сторінок.

Якщо його приєднати перед завантаженням / візуалізацією сторінки, неоптимізований зворотний виклик MutationObserver може додати кілька секунд до часу завантаження сторінки (скажімо, від 5 секунд до 7 секунд), якщо сторінка велика і складна ( 1 , 2 ). Зворотний дзвінок виконується як мікрозадача, яка блокує подальшу обробку DOM і може запускатися сотні або тисячі разів на секунду на складній сторінці. Більшість прикладів та існуючих бібліотек не враховують подібні сценарії і пропонують гарний, простий у використанні, але потенційно повільний код JS.

Завжди використовуйте профайлер devtools і намагайтеся, щоб ваш виклик спостерігача споживав менше 1% від загального часу процесора, який витрачається під час завантаження сторінки.
Уникайте активації примусового синхронного макета , звертаючись до offsetTop та подібних властивостей
Уникайте використання складних DOM-фреймворків / бібліотек, таких як jQuery, віддайте перевагу власним DOM-матеріалам
Під час спостереження за атрибутами використовуйте attributeFilter: ['attr1', 'attr2']опцію в .observe().
По можливості спостерігайте за прямими батьками нерекурсивно ( subtree: false).
Наприклад, має сенс дочекатися батьківського елемента, спостерігаючи documentрекурсивно, від'єднати спостерігача від успіху, прикріпити новий нерекурсивний елемент до цього елемента-контейнера.
Чекаючи лише одного елемента з idатрибутом, використовуйте шалено швидко, getElementById замість того, щоб перераховувати mutationsмасив (він може мати тисячі записів): example .
Якщо бажаний елемент є відносно рідкісним на сторінці (наприклад, iframeабо object), використовуйте поточний HTMLCollection, повернутий getElementsByTagNameі, getElementsByClassNameі перевірте їх усі, замість того, щоб перераховувати, mutationsякщо він містить більше 100 елементів, наприклад.
Уникайте використання querySelectorта особливо надзвичайно повільних querySelectorAll.
Якщо querySelectorAllабсолютно неможливо уникнути зворотного виклику MutationObserver, спочатку виконайте querySelectorперевірку, а якщо вдало, продовжуйте querySelectorAll. У середньому така комбінація буде набагато швидшою.
Якщо ви націлюєтеся на Chrome / ium до 2018 року, не використовуйте вбудовані методи Array, такі як forEach, фільтр тощо, які вимагають зворотних викликів, оскільки у V8 Chrome ці функції завжди були дорогими у порівнянні з класичним for (var i=0 ....)циклом (10-100 в рази повільніше), а зворотний виклик MutationObserver може повідомляти про тисячі вузлів на складних сучасних сторінках.

Альтернативне перерахування функцій, підкріплене lodash або подібною швидкою бібліотекою, добре навіть у старих браузерах.
Починаючи з 2018 року Chrome / ium включає стандартні вбудовані методи масиву.

Якщо орієнтовані на браузери до 2019 року, не використовуйте повільні цикли ES2015, як for (let v of something)всередині зворотного виклику MutationObserver, якщо ви не зробите транпіляцію, щоб результуючий код працював так само швидко, як класичний forцикл.
Якщо мета полягає в тому, щоб змінити вигляд сторінки, і у вас є надійний і швидкий спосіб повідомити, що додані елементи знаходяться за межами видимої частини сторінки, відключіть спостерігача та заплануйте цілу сторінку для повторної перевірки та обробки за допомогою setTimeout(fn, 0): це буде виконано, коли початковий сплеск розбору / компонування завершено, і двигун може "дихати", що може зайняти навіть секунду. Тоді ви можете непомітно обробити сторінку фрагментами, наприклад, за допомогою requestAnimationFrame.
Якщо обробка є складною та / або займає багато часу, це може призвести до дуже довгих кадрів фарби, невідповідності / збитку, тому в цьому випадку ви можете використовувати дебанс або подібну техніку, наприклад, накопичувати мутації у зовнішньому масиві та планувати запуск через setTimeout / requestIdleCallback / requestAnimationFrame:
```
const queue = [];
const mo = new MutationObserver(mutations => {
  if (!queue.length) requestAnimationFrame(process);
  queue.push(mutations);
});
function process() {
  for (const mutations of queue) {
    // ..........
  }
  queue.length = 0;
}
```

Повернутися до питання:

стежте за певним контейнером, ul#my-listщоб побачити, чи <li>до нього додано який-небудь .

Оскільки liце прямий дочірній продукт, і ми шукаємо додані вузли, єдиним необхідним варіантом є childList: true(див. Пораду №2 вище).

new MutationObserver(function(mutations, observer) {
    // Do something here

    // Stop observing if needed:
    observer.disconnect();
}).observe(document.querySelector('ul#my-list'), {childList: true});