Дорого ли читать свойства из оконного объекта?

Question

Например, допустим, у нас есть две версии lazyload (см. Код ниже).С точки зрения производительности, лучше ли версия II, чем версия I?

const imgs = document.querySelectorAll('img'); 
window.addEventListener('scroll' , lazyload);

// version I 
function lazyload() { 
  imgs.forEach((img) => { 
    if (img.offsetTop < window.innerHeight + window.pageYOffset) { 
      img.src = img.dataset.src; 
    }
  }
}

// version II
function lazyload() { 
  const innerHeight = window.innerHeight; 
  const pageYOffset = window.pageYOffset; 
  imgs.forEach((img) => { 
    if (img.offsetTop < innerHeight + pageYOffset) { 
    img.src = img.dataset.src; 
  }
}

Answer 1

Ваш конкретный вопрос:

Я перефразирую ваш конкретный вопрос, подобный этому:

Дорого ли обходить window.innerHeight и / или window.pageYOffset?

Это может быть. По словам Пола Ирриша из команды разработчиков инструментов Google Chrome :

Все перечисленные ниже свойства или методы, когда их запрашивают / вызывают в JavaScript, заставят браузер синхронно вычислять стиль и макет *. Это также называется перекомпоновкой или разбиванием макета , а является общим узким местом производительности .

...

окно

window
window.scrollX, window.scrollY
window.innerHeight, window.innerWidth
window.getMatchedCSSRules() only forces style

- Что заставляет макет / оплавление (акцент мой)

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

• Перекомпоновка имеет стоимость, только если документ изменился и аннулировал стиль или макет. Как правило, это происходит потому, что DOM был изменен (классы изменены, узлы добавлены / удалены, даже добавлен псевдо-класс, такой как: focus).
• Если макет принудительный, стиль должен быть сначала пересчитан. Поэтому принудительное размещение запускает обе операции. Их стоимость очень зависит от содержания / ситуации , но обычно обе операции схожи по стоимости.
• Что вы должны делать со всем этим? Что ж, в разделе «Подробнее о принудительной компоновке» ниже все подробно описано, но
  короткая версия:
  1. for петли, которые вынуждают макет и изменять DOM, являются худшими , избегайте их.
  2. Используйте временную шкалу DevTools, чтобы увидеть, где это происходит . Вы можете быть удивлены, увидев, как часто ваш код приложения и код библиотеки попадают в это.
  3. Пакетная запись и чтение в DOM (через FastDOM или виртуальную реализацию DOM). Считайте ваши метрики в начале кадра (в самом начале rAF, обработчика прокрутки и т. Д.), Когда числа все еще идентичны предыдущему разметке.

Изменение атрибута src, вероятно, достаточно для «аннулирования стиля или макета». (Хотя я подозреваю, что использование чего-то вроде заполнителей SVG с правильно заданными размерами для лениво загруженных изображений уменьшит или исключит затраты на повторное использование.)

Короче говоря, ваша реализация "версии I" предпочтительна и, насколько я могу судить, не имеет реальных недостатков.

Ваш общий вопрос

Как показано выше, чтение свойств из объекта окна может быть дорогим. Но другие правы указать на пару вещей:

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

Answer 2

Этот кажется лучше

// version III
function lazyload(){
  const dimension = window.innerHeight + window.pageYOffset;
  img.array.forEach(img => {
    if (img.offsetTop < dimension) {
      img.src = img.dataset.src;
    }
  });
}