Автор этой статьи: Жэнь Цзяле
Исходное заявление: Эта статья подготовлена членами команды интерфейса чтения YFE, пожалуйста, уважайте оригинальность, пожалуйста, свяжитесь с общедоступной учетной записью (id: yuewen_YFE) для авторизации и укажите автора, источник и ссылку.
предисловие
Однажды я написал «длинный отчет» по оптимизации производительности и «эффект бабочки, вызванный украшением флажка». Я также посетовал, что CSS оказывает такое большое влияние на рендеринг. Может быть, цена углубления точек памяти состоит в том, чтобы дважды споткнуться об один и тот же камень? Да, второй "отчет" по оптимизации производительности уже здесь. Я надеюсь, что эта статья может дать вам некоторые идеи по оптимизации производительности страницы.
Аспект
Определенные свойства CSS или операции JS, кажущиеся простыми, но легко скрывающие подводные камни?
- видимость - показать или скрыть элемент в документе без изменения макета.
- clientHeight/clientWidth — Получить ширину и высоту внутри элемента.
Заточка ножей не идет вразрез с рубкой дров, и всегда необходим тесный контакт с рабочими инструментами.
- Как использовать инструмент производительности браузера Edge
- Как быстро найти и решить проблемы с производительностью?
Один и тот же браузер, производительность уровня рендеринга настолько отличается?
- Как стратегия рендеринга пограничного браузера отличается от Chrome Chrome?
производительность бомба
Проблема началась с «бомбы Красной производительности», нацеленной на страницу чтения веб-сайта Webnovel «Начальная точка зарубежья зарубежья», ключевые слова: ключевое браузер, CPU, RAM. Зарубежный пользователь Webnovel указывал на то, что под краевым браузером расход CPU расход чтения страниц очень большой, а его ноги даже чувствовали жжение ноутбука.
Страница чтения веб-новелл, чтобы приблизиться к идеальному чтению, мы сделали: предварительную загрузку следующей главы, поддержку клавиш вверх и вниз для переключения глав, пропуск глав без обновления и т. д. В процессе чтения вы даже не будете смотрите процесс загрузки контента. Однако перед лицом этого шока производительности эти оптимизации настолько незначительны под браузером Edge... И стоит ли делать эту оптимизацию производительности, ответ дает Google Analytics:
"Процентный список браузера веб-новелл"
Долю браузера Edge TOP4 (2,53%) нельзя игнорировать! Кажется, что с Edge суждено столкнуться око за око, и сразу же перейти в браузер Edge, чтобы выяснить это~
Анатомия проблемы
Прежде чем нацелиться на проблему, внутренний голос напомнил мне: это проблема со скриптом Google Ads! Потому что реклама Google была введена на странице чтения не так давно, и были сделаны некоторые логические корректировки для отображения и скрытия рекламы, с целью начать анализ с JS.
Ищете код проблемы в инструментах повышения производительности — Google Script продолжает получать значения clientHeight, clientWidth?
Я использовал инструмент производительности, который поставляется с браузером Edge для анализа.Поскольку Edge может работать только в системе win10, я использую iMac на работе, поэтому я почти не использую его, поэтому я могу только пойти домой и «выкинуть его». У него есть настольный компьютер, предназначенный для игр, и его версия браузера Edge: 42.17134.1.0.
Откройте инструменты для разработчиков по краю, а вход в инструменты производительности приходит в поле зрения.
«Пограничные инструменты разработчика»
Переходим к делу: «Посетите страницу чтения Webnovel — откройте вкладку «Производительность» — нажмите кнопку запуска». Чтобы восстановить сценарий использования пользователя, я также внимательно пролистал с десяток глав. Результат запуска:
«График результатов первого инструмента производительности»
Это полноэкранное прощение цвета, чтобы увидеть эту картину, пожалуйста, пообещай мне, что первое, что подтвердить, что «рендеринг» проблемы, хорошо? Пожалуйста, проверьте это немедленно комментировать CSS хорошо? Но я этого не делал.
«Вопросский фрагмент 1»
«Фрагмент кода проблемы 2»
По-видимому, скрипт Google osd.js устанавливает таймер и продолжает получать clientWidth и clientHeight узла HTML, так что это виновник?
Некоторые скрытые опасности clientHeight и clientWidth
Инженер Facebook Стоян упомянул в своем блоге, что браузеры умны. Чтобы экономить ресурсы и редко запускать Repaint и Reflow, он будет вносить изменения в пользовательский интерфейс, которые необходимо выполнять в серии сценариев. Поместите их в очередь и выполните их вместе, вместо того, чтобы выполнять каждое изменение по отдельности, вызывая бесчисленные перерисовки и перекомпоновки. НО! Есть некоторые операции, которые нарушат его первоначальный план и порядок:
- offsetWidth, offsetHeight, offsetTop, offsetLeft
- scrollTop, scrollLeft, scrollWidth, scrollHeight
- clientlTop, clientLeft, clientWidth, clientHeight
- getComputedStyle() или currentStyle в IE
Для этих операций браузер будет давать наиболее точные ответы в режиме реального времени «очень своевременно», поэтому он будет запускать Reflow, например, пересчет стилей, обновление слоев и т. д. Вы должны знать, что Reflow оказывает большее влияние на рендеринг и потребляет больше ресурсов, чем Repaint.
демонстрационное время. Вызывает ли получение clientWidth ненужный рендеринг?
Краткое описание функций:
- После загрузки страницы установите таймер, чтобы получать clientWidth узла HTML каждые 4 мс (минимальный временной интервал браузера по умолчанию).
- Нажмите кнопку «Щелкни меня», чтобы сдвинуть блок 1 по горизонтали в крайнее правое положение.
- Нажмите кнопку без таймера, чтобы сбросить таймер и переместить блок 1 по горизонтали в исходное положение.
«Демонстрационная анимация»
Обработать |
результат |
Этап 1: Перед «нажать меня» |
Перекомпоновка, такая как рендеринг, и не срабатывает |
Этап 2: после «нажми на меня» |
|
Результат демонстрации подтверждает, что в браузере Chrome получение clientWidth / clientHeight во время анимации действительно вызовет перекомпоновку браузера.По мере увеличения сложности анимации и увеличения количества элементов влияние будет только больше, что, в свою очередь, увеличивается ненужная стоимость рендеринга.
Первая попытка – удалить Google Ads
Поскольку CPU парят страницы чтения, скорее всего, поскольку OSD.js Google продолжает получать клиента / Clientheight of HTML-узла и случайно запускает несколько отражающих, первый шаг для решения проблемы состоит в том, чтобы удалить объявления Google. Я использовал Fiddler, чтобы прокси секрет JS к локальному и удалил код, связанный с рекламой.
Но результаты делают, и мое предположение совершенно другое, удалить рекламу не сделала страницу лучше эффективности, и не знаю ... Небольшая проблема действительно не в Google Реклама?
Повторите попытку – с объявлениями Google возникают аналогичные проблемы на других сайтах.
Продолжайте использовать инструмент производительности Edge для тестирования аналогичного веб-сайта, потому что этот веб-сайт также использует рекламу Google, и по сравнению со страницей чтения Webnovel, инициализирующей 1 объявление в первый раз, его домашняя страница загружает 4 объявления одновременно. Однако проблем с рендерингом нет (как показано на рисунке ниже), а в столбце загрузки ЦП веб-сайта нет даже следов зеленого цвета.
Переверните идею, переключите направление на CSS
Слишком сильно верите в предположения и отклоняетесь от верного пути? На начальном этапе я был слишком уверен, что проблема в рекламном скрипте Google, но поскольку 2 вышеуказанные попытки оказались не ошибкой рекламного скрипта Google, пришло время сменить направление.
«Эффект бабочки, вызванный украшением флажка», который я однажды написал, вдохновил меня: CSS оказывает более важное влияние на производительность рендеринга, чем JS. В сочетании с выводами из демонстрации, упомянутыми выше, нельзя не предположить, что, возможно, проблема с производительностью при чтении страниц связана с некоторыми свойствами CSS или анимацией, взаимодействующими с clientHeight и clientWidth в рекламном скрипте Google, что вызывает дополнительный рендеринг. В этот момент я попытался аннотировать все стили, и наконец зеленый цвет исчез, что означает, что это, скорее всего, горшки с CSS.
«Визуализация, которая исчезает при использовании ЦП»
Виновником является visibility: hidden?
Продолжаете искать более точный ответ от инструментов производительности и случайно обнаруживаете, что вкладка «Временная шкала» в инструментах производительности Edge может собирать много полезной информации и даже находить записи, связанные со стилем? Замечательно расширяться, чтобы найти DOM, который в данный момент вызывает рендеринг!
Это позиционирование проблемы была отличной помощью, потому что я ясно вижу проблему DOM, который мы написали загрузку компонентов.
«Обзор главы», всплывающее окно каталога
"загрузка между главами"
Целью скрытия загрузки является упрощение логики и «засады и скрыть», где им это нужно. Перед получением требуемых асинхронных данных нагрузка может отображаться пользователю в первый раз, и загрузка может быть скрыта после получения после получения Требуемые данные. Такая логика взаимодействия разумна, поэтому почему скрытая нагрузка влияет на рендеринг? Загрузка в окне всплывающего окна Webnovel чтения скрыта с видимостью: скрыто. Это неправильно?
видимость: у скрытого есть плюсы и минусы
Не видно следов загрузки, но может ли она так сильно влиять на рендеринг? Вы думаете, что правильно скрываете загрузку, но на самом деле загрузка существует в потоке документов, и каждая ее анимация будет влиять на другие узлы в потоке документов.
- видимость: скрыто // рендеринг DOM не игнорирует все его узлы
- display: none // рендеринг DOM игнорирует все его узлы
С этой точки зрения лучше отображать: нет, что не повлияет на другие элементы в документообороте. Но у каждого созданного свойства CSS должна быть причина для его создания.Если display: none является наиболее рекомендуемым способом, почему существует visibility: hidden? У всего есть две стороны, например, в следующем сценарии visibility: hidden помог великому богу решить проблемы с производительностью.
В своем блоге «Решение задач производительности рендеринга» инженер Google Джейк Арчибальд использует интересную SVG-анимацию, чтобы продемонстрировать важность макета для производительности веб-страницы. Благодаря постоянному изменению текста SVG в анимации частота кадров анимации, наконец, снижается с исходных оптимальных 60 кадров в секунду до менее чем 10 кадров в секунду. Инструмент «Производительность» Chrome показывает, что его основным фактором является большое потребление макета (так называемое переполнение макета или перекомпоновка).
В это время Джейк использовал visibility: hidden для решения проблемы чрезмерного использования Layout, упомянув, что элемент с visible: hidden занимает место в потоке документа, поэтому установка его в visible: visible не приведет к каким-либо изменениям в Layout. потребления, генерируется только лишняя краска.С этой идеей он заранее поместил все символы в SVG в дочерние узлы
«Текст SVG, скрытый в DOM»
Затем значение атрибута видимости
Таким образом, нельзя сделать вывод, что visible: hidden не так хорош или лучше, чем display: none в целом, можно лишь сказать, что у них есть свои преимущества в разных сценариях.
решение проблемы
Очевидно, что скрытие анимации загрузки с помощью visible: hidden требует больших дополнительных затрат на рендеринг. Есть много решений этой проблемы, например, вы можете изменить скрытый метод загрузки на отображаемый: нет или добавить загрузку в DOM в реальном времени при открытии всплывающего окна, чтобы избежать глобального воздействия. изменения CSS компонента всплывающего окна. , мы добавляем узел загрузки DOM при открытии всплывающего окна и удаляем его при закрытии всплывающего окна. Отзывы пользователей через неделю также подтвердили эффективность этой схемы (ниже).
«Отзывы пользователей»
Попробуйте новые программы
Рендеринг браузера Edge Chrome включен и в чем разница?
Хотя проблема Webnovel решена, прочитайте страницу, но мы, вероятно, зададимся вопросом, почему такие проблемы с производительностью не возникают в браузере Chrome или не очевидны? Здесь я прибегнул к «видимости: скрытые плюсы и минусы». Джейк упоминает анимацию SVG в волне тестирования. Инструмент производительности легко его обнаружил и обнаружил его производительность до того, как анимация не была оптимизирована и не могла выглядеть так же, как в Chrome:
«Результаты производительности пограничного браузера»
В инструменте Chrome Performance можно доказать, что стратегия оптимизации Джейка действительно значительно сократила потребление Layout, от исходного TOP3 до последнего:
"До оптимизации, после оптимизации"
"Оптимизированный"
Стоимость уровня рендеринга после оптимизации даже больше, чем стоимость до оптимизации (когда анимация работает примерно столько же):
«До и после оптимизации данных потока пользовательского интерфейса»
В исполнении этой демонстрации рендеринга края анимации SVG диаметрально противоположны Chrome's. Что более важно, хром «компромисс» в рендеринге производительности для макета (макета) и краской (перерезания), кажется, одинаково, как краевые. Не То же самое, уменьшение множества накладных макетов делает анимацию более гладкими в Chrome, но она не работает в крае или даже наоборот.
новые идеи для решения проблем
Разница в производительности SVG-анимации между браузерами Chrome и Edge натолкнула меня на некоторые новые идеи. Вернемся снова к странице чтения Webnovel, мы действительно используем много SVG на нашей странице. Я попытался изменить отображение: inline- After блок сменился на display: none, процессор быстро упал и производительность снизилась (как показано на рисунке ниже) Я был очень приятно удивлен.
«Перед аннотированием стилей SVG»
«После аннотирования стилей SVG»
Тем не менее, проблема производительности в настоящее время решена, и SVG используется на всех сайтах Webnovel. В настоящее время было бы немного грубо заменять SVG глобально. Кроме того, демонстрации Джейка недостаточно, чтобы объяснить, что слишком сильно SVG влияет производительность страницы, поэтому это решение не было реализовано, но это действительно может послужить еще одним прорывом для проблем с производительностью страницы чтения Webnovel, и потребуется больше времени, чтобы исследовать тайну в последующем.
Некоторые раздражающие тяги
Конечно, исправление проблемы всегда нужно подводить итог:
- видимость: спрятан палка о двух концах.
- Во время анимации не рекомендуется использовать такие операции, как clientWidth и clientHeight.
- Уровень рендеринга браузера EDGE немного отличается, что заслуживает внимания.
Ссылка на ссылку
- Developers.Google.com/Web/tools/From…«Документация Google для разработчиков — анализ производительности во время выполнения с помощью инструментов рендеринга»