API нестабильности макетов | web.dev

      
        

          Обнаружение неожиданных изменений макета в JavaScript.
        

      

      
         11 июня 2019

          
            

  

          
        

      
    

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

Или еще хуже: вы собираетесь нажать на ссылку или кнопку, но в мгновение ока
до того, как ваш палец приземлится — БУМ — связь перемещается, и вы в конечном итоге
щелкнув что-то еще!

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

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

Что делает эту проблему еще более проблематичной, так это то, как сайт функционирует в
развитие часто сильно отличается от того, как пользователи испытывают его в
производство: персонализированный или сторонний контент часто не ведет себя одинаково
в разработке, как и в производстве, тестовые изображения часто уже находятся в
Кэш браузера разработчика и локальные вызовы API часто бывают очень быстрыми
что задержка не заметна.

Первый шаг к правильному решению этой проблемы — дать разработчикам
инструменты, чтобы измерить это и понять, как часто это происходит для реальных пользователей.
API нестабильности макета, в настоящее время
инкубация в WICG, направлена ​​на
обратитесь к этому.

Как определяется нестабильность макета? #

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

Определен сдвиг макета #

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

Объединение видимых областей всех нестабильных элементов для предыдущего кадра.
и текущий кадр — как часть общей площади
область просмотра — это оценка сдвига макета для текущего кадра.

Вот несколько примеров того, как вычисляется оценка сдвига макета:

На изображении выше есть элемент, который занимает половину области просмотра в одном
Рамка. Затем в следующем кадре элемент смещается вниз на 25% от области просмотра
рост. Красный пунктирный прямоугольник указывает на объединение видимого элемента
площадь в обоих кадрах, которая в данном случае составляет 75% от общего окна просмотра, поэтому его
сдвиг макета составляет 0,75.

Следующий пример иллюстрирует, как добавление контента к существующему элементу влияет
сдвиг макета:

Здесь "Click Me!" Кнопка добавлена ​​в нижней части серого поля с
черный текст, который выдвигает зеленое поле с белым текстом вниз (и частично выходит
окна просмотра).

В этом примере серый блок меняет размер, но его начальная позиция не изменяется
изменить, чтобы это не нестабильный элемент. Начальная позиция зеленой рамки,
однако, меняется, но так как он был частично перемещен из области просмотра,
невидимая область не учитывается при расчете показателя сдвига макета.
Объединение видимых областей для зеленой рамки в обоих кадрах такое же, как
площадь зеленой рамки в первом кадре, которая составляет 50%, и ее расположение
поэтому сдвиг составляет 0,5 (как показано красным пунктирным прямоугольником).

Этот последний пример иллюстрирует несколько нестабильных элементов:

В первом кадре выше у нас есть начальные результаты запроса API для
животные, отсортированные в алфавитном порядке. Во втором кадре у нас есть еще
результаты, добавленные в отсортированный список.

Первый элемент в списке («Кошка») не меняет свою начальную позицию между
кадры, так что это стабильно. Точно так же новые элементы, добавленные в список, не были
ранее в DOM, поэтому их стартовые позиции также не меняются. Но
элементы с надписями «Собака», «Лошадь» и «Зебра» смещают свои начальные позиции, поэтому
они нестабильные элементы.

Опять же, красные пунктирные прямоугольники представляют объединение этих трех нестабильных
элементов до и после областей, что в данном случае составляет около 38%
площадь области просмотра (смещение макета 0,38).

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

Ожидаемые и неожиданные изменения макета #

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

Изменения в макете, инициированные пользователем #

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

Например, если взаимодействие с пользователем запускает сетевой запрос, который может занять
в то время как для завершения, лучше сразу создать место и показать загрузку
индикатор, чтобы избежать неприятного сдвига макета при завершении запроса. Если
пользователь не понимает, что что-то загружается, или не понимает, когда
ресурс будет готов, они могут попытаться нажать что-то еще, пока
ожидание — то, что может уйти из-под них.

Анимации и переходы #

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

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

Совокупная оценка сдвига макета #

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

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

Кумулятивный сдвиг макета (CLS) определяется путем вычисления суммы
все неожиданные оценки сдвига макета от загрузки страницы до жизненного цикла страницы
состояние
меняется на скрытый. В текущей реализации Chrome "неожиданный макет
сдвиги »- это те, которые не происходят в течение 500 миллисекунд дискретного пользователя
взаимодействие (то есть щелчок, касание и нажатие клавиши, но не прокрутка или мышь)
движется)

На странице, на которой нет неожиданных сдвигов макета, будет кумулятивный сдвиг макета
Оценка 0. Большинство типичных сайтов и веб-приложений должны стремиться к
оценка 0, чтобы обеспечить лучший опыт для своих пользователей.

Кроме того, кумулятивная оценка сдвига макета была добавлена ​​как
экспериментальная метрика в пользовательском интерфейсе Chrome
Отчет
(CrUX), набор данных, который показывает, как реальные пользователи Chrome испытывают популярность
направления в Интернете. С добавлением CLS в мае 2019 года,
разработчики могут лучше понять, как пользователи воспринимают макет
нестабильности на их сайтах, на сайтах их конкурентов и в Интернете как
целое.

Как использовать API нестабильности макетов #

API-интерфейс нестабильности макетов доступен в Chrome 74+ с экспериментальной сетью.
флаг функций платформы включен
( chrome: // flags / # enable-эксперимент-web-platform-features ) или через
Макет нестабильности Origin
Trial ,
который будет доступен до 3 сентября 2019 года.

Подобно другим API производительности, нестабильность компоновки можно наблюдать через
Интерфейс PerformanceObserver где вы можете подписаться на записи типа
layoutShift .

Следующий код регистрирует все записи смены макета, как они происходят:

    const  наблюдатель  =   новый   PerformanceObserver   (   список  )   =>   {  
   для   (  const  запись  из списка  .   getEntries   ( ]   ])   {  
  консоль .   журнал   ( запись ) )  ;   
  }   
  } } ]   
  
  наблюдатель .   [19459047наблюдают]  (  { entryTypes  :   [  'layoutShift'  ]  }  )  ;   ]  

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

   
   let  совокупныйLayoutShiftScore  =   0        
  
  
   const  наблюдатель  =   новый   Performance 1990904 1947  (  (  список  )   =>   {  
 
   для   (  const  запись  из списка . .   getEntries   (  )  )   {  
  cumulativeLayoutShiftScore  + =  запись . значение ;   
  }   
  [1 9459050]}  )  ;.   
  
  Наблюдатель    наблюдается   (  { entryTypes :   [  'layoutShift'  ]  ] ] )  ;.   
  
  
  
  документ    addEventListener   (  'visibilitychange'    ( )  >   {  
   if   ( документ .  visibilityState  ===  ]  «скрытый»  )   {  
   
  наблюдатель .   takeRecords   ( )  ;   
  
  
   
   sendToAnalytics   (  { совокупноеLayoutShiftScore [194590]] [194590]][194590][194590]  ;   
  }   
  }    ;    

Как избежать неожиданных изменений макета #

Для большинства веб-сайтов вы можете избежать неожиданных изменений макета, придерживаясь
несколько руководящих принципов:

•      Всегда включайте атрибуты размера на ваши изображения и видео элементы,
      или иным образом зарезервировать необходимое место с чем-то вроде
       Соотношение сторон CSS
      коробки .
  Этот подход гарантирует, что браузер может выделить правильное количество
      пространство в документе во время загрузки изображения. Обратите внимание, что вы также можете
      использовать
      
      политика функций unsized-media для принудительного использования этого поведения в браузерах, которые
      политика поддержки функций. И в будущем вы сможете использовать
      
      Атрибут intrinsicSize упрощает решение этой проблемы.
    

  

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

  

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

Требуется обратная связь #

API-интерфейс нестабильности макета инкубируется в WICG, и это время
обратная связь от сообщества разработчиков является наиболее полезной, особенно
Отзывы о том, насколько хорошо API работает на реальных сайтах и ​​с фактическими
методы разработки, используемые сегодня.

• Есть ли какие-либо ложные срабатывания (хороший опыт сообщается как неожиданный макет
  сдвиги)?
• Есть ли ложные негативы (явные примеры нестабильности компоновки
  сообщили)?
• Являются ли оценки значимыми, а данные — действенными?

Вы можете оставить отзыв, открыв вопрос о спецификациях нестабильности макета .
Репозиторий GitHub или путем
обсуждение уже происходит там.

Кроме того, если ваш сайт доступен в наборе данных CrUX, вы можете
запрос
чтобы увидеть, как реальные пользователи Chrome испытывают стабильность вашего сайта
макет, и вы можете сравнить эти результаты с результатами, которые вы видите, когда
тестирование вашего сайта локально. Если результаты, которые вы видите в CrUX, неожиданны, вы
может подписаться на Layout Instability Origin
Trial
и контролируйте работу своего пользователя через JavaScript API.

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