Опубликовано: 14 октября 2025 г.
Взаимодействие с последующей отрисовкой (INP) — важнейшая метрика Core Web Vital для оценки отзывчивости. В Fotocasa Google Search Console выявил значительное количество страниц, которые перешли в статус «Требуется улучшение» и «Плохо» после замены задержки первого ввода (FID) на INP в 2024 году. В этом исследовании описываются инструменты и стратегии, используемые для диагностики и решения этих проблем, что в конечном итоге значительно улучшило INP.
С чего начиналась команда Fotocasa
До перехода с FID на INP практически все страницы как на десктопах, так и на мобильных устройствах находились в пределах порога «Хорошо», что означало, что все основные показатели веб-показателей (LCP, CLS и FID) на тот момент работали хорошо. Однако после перехода на INP почти все страницы перешли в категорию «Требуется улучшение», а некоторые даже в категорию «Плохо», поскольку значения INP постоянно превышали 200 миллисекунд для большинства взаимодействий пользователей.
Это изменение заставило команду Fotocasa осознать, что они упускают из виду важный аспект пользовательского опыта. В то время как FID измерял задержку только при самом первом взаимодействии, INP оценивает скорость отклика при всех взаимодействиях, учитывая задержки обработки ввода и отображения. Этот более широкий показатель гораздо лучше отражает реальную интерактивность (как заявляет Google) и выявляет упущенные возможности.
Несмотря на то, что Google Search Console предоставляет данные об эффективности работы на местах, она не предоставляет аналитику в режиме реального времени. Данные обрабатываются за 28-дневный период, что затрудняет определение конкретных взаимодействий, вызывающих проблемы в данный момент.
Требовался способ отслеживания INP в режиме реального времени, чтобы выявить наиболее медленные и часто используемые пользователями взаимодействия и надёжно воспроизвести их в средах разработки команды. Не менее важно было понять влияние внесённых изменений: не только то, какие исправления помогли, но и то, какие изменения непреднамеренно ухудшили ситуацию.
По этим причинам для диагностики и решения проблем был использован набор инструментов. Наиболее важными из них были:
- Google Chrome DevTools, а именно вкладка «Производительность».
- Специальная система RUM ( мониторинг реальных пользователей ), созданная командой Fotocasa в Datadog с использованием библиотеки web-vitals.
- Инструменты разработчика React.
Инструменты для диагностики проблемы
Для диагностики и устранения проблем производительности INP использовались следующие инструменты.
Инструменты разработчика Google Chrome
Отличный способ обнаружить и воспроизвести проблемы, связанные с основными веб-показателями (Core Web Vitals) в веб-приложении, — использовать вкладку «Производительность» в инструментах разработчика Google Chrome. Вкладка «Производительность» автоматически измеряет показатели основных веб-показателей (Core Web Vitals), предоставляя мгновенную обратную связь по показателям загрузки, интерактивности и изменениям макета. В целом, это соответствует тому, как эти показатели предоставляются в других инструментах Google.
Для выявления и устранения проблем с INP команда Fotocasa обычно начинала с ограничения производительности процессора, имитируя производительность устройств начального и среднего уровня. Это позволяло команде Fotocasa наблюдать за поведением страницы в более жестких условиях. Затем сеанс записывался с помощью профилировщика, и полученные данные тщательно анализировались с упором на взаимодействие пользователя для выявления проблем с производительностью.
При выявлении узких мест особенно полезно изучить подчасти INP и задачи, выполняемые браузером в каждой из них. Например, на следующем изображении видно, что INP довольно высок из-за двух перерасчётов стилей, вызванных изменениями стилей в тексте документа.
Fotocasa внедрила систему отслеживания INP и других показателей Core Web Vital, гарантируя быстрое выявление и решение любых проблем с производительностью. Когда показатель превышает определённый порог (в соответствии с диапазонами, установленными Google), атрибуция регистрируется, что позволяет проанализировать проблему и решить её.
Для этой системы библиотека web-vitals использовалась для сбора этих показателей от реальных пользователей способом, который точно соответствует тому, как они измеряются Chrome и передаются в другие инструменты Google (такие как Chrome User Experience Report, Page Speed Insights, Search Console's Speed Report и другие).
Для комплексного анализа и централизованного отслеживания Fotocasa использовала Datadog для сбора и визуализации данных, что позволило команде принимать обоснованные решения на основе данных. Пользовательские метрики обеспечивают экономическую эффективность и позволяют лучше отслеживать практически всех пользователей на сайте Fotocasa.
Эта система позволяет команде Fotocase оперативно отслеживать, влияют ли внесенные изменения на метрики или возникают непредвиденные изменения, потенциально ставящие их под угрозу. Метрику INP можно затем разбить на такие составляющие, как задержка ввода, длительность обработки и задержка представления, чтобы точно определить, какая часть взаимодействия в первую очередь отвечает за длительное время взаимодействия.
При обнаружении аномалий, подобных показанным на рисунках 7 и 8, Fotocasa оперативно отреагировала и использовала OpenSearch — ещё один инструмент, который помог определить место возможного изменения. Данные, предоставленные библиотекой web-vitals, помогли определить цель (элемент DOM, потенциально ответственный за повышенное значение метрики) и позволили команде более целенаправленно сосредоточиться на устранении проблемы.
Кроме того, можно определить различные фильтры, такие как тип страницы, устройство или состояние загрузки, чтобы оптимизировать сценарии и получить более точное представление о том, как влияет на INP.
Инструменты разработчика React
Для расширения возможностей отладки Fotocasa использовались инструменты разработчика React , которые предоставляют мощную функцию, позволяющую визуально выделять компоненты, которые были перерисованы.
Эту функцию можно включить на вкладке «Профилировщик» . Щёлкните по значку шестерёнки в правой части верхней панели, перейдите на вкладку «Общие» и установите флажок «Выделять обновления при отрисовке компонентов» . Если этот флажок активирован, компоненты подсвечиваются при повторной отрисовке, обеспечивая динамическое визуальное представление.
Выяснение причины повторной визуализации
После того, как компонент, который был перерисован, идентифицирован, возникает следующий вопрос: «Почему это произошло?» React DevTools отвечает на этот вопрос с помощью полезной подсказки в представлении FlameGraph.
Чтобы получить доступ к этой информации, запишите сеанс профилирования. Анализируя выходные данные профилирования, вы найдете полезную информацию:
- В правом верхнем углу отображается количество коммитов React.
- Диаграмма пламени визуально отображает дерево компонентов, где серый цвет обозначает компоненты, которые не были перерисованы. Каждый столбец отображает момент изменения дерева компонентов React и момент фиксации соответствующего изменения в DOM.
- При наведении курсора на каждый компонент на графике пламени под подзаголовком «Почему это было отображено? » отображается причина его повторной отрисовки.
Причины повторной перерисовки компонента могут включать в себя:
- Это первый раз, когда компонент был отрисован.
- Контекст изменился
- Крючки изменены
- Реквизит изменен
- Состояние изменилось
- Родительский компонент отображается
Определение времени рендеринга
Цвета на графике пламени несут важную информацию. Такие цвета, как различные оттенки синего, указывают на то, что компоненту потребовалось относительно короткое время рендеринга по сравнению с другими компонентами. И наоборот, такие цвета, как оранжевый и красный, указывают на то, что компоненту потребовалось больше времени рендеринга.
Как команда Fotocasa решила проблему
Удалить ненужные повторные рендеры
Повторные рендеры происходят всякий раз, когда React требуется обновить пользовательский интерфейс новыми данными. Обычно это происходит из-за действия пользователя, ответа API или других важных событий, требующих обновления пользовательского интерфейса. Поскольку каждый повторный рендеринг запускает JavaScript, слишком большое количество повторных рендеров одновременно, особенно в большом дереве компонентов, может заблокировать основной поток и вызвать проблемы с производительностью.
Существует два вида повторной обработки:
- Необходимые повторные рендеры: когда компонент действительно нуждается в обновлении, поскольку он владеет или использует новые данные.
- Ненужные повторные рендеринги: когда компонент обновляется без каких-либо значимых изменений, часто из-за неэффективного управления состоянием или неправильной обработки свойств.
Несколько ненужных перерисовок обычно не представляют большой проблемы, поскольку React достаточно быстр, и пользователи обычно их не замечают. Однако, если они происходят слишком часто или в сложном дереве компонентов, они могут ухудшить пользовательский опыт и негативно повлиять на INP страницы.
Именно это и произошло с командой Fotocasa. Они обнаружили, что на сайте было много ненужных повторных рендеров. Это происходило в двух основных случаях:
- Во время загрузки страницы: увеличение количества длительных задач в основном потоке и задержка первого взаимодействия, что отрицательно влияет на INP страницы.
- Во время взаимодействия с пользователем: увеличение времени обработки большинства взаимодействий, что также наносит ущерб INP.
На сайте Fotocasa было оптимизировано множество ненужных повторных рендеров. Одна из самых значительных оптимизаций была реализована на странице поиска. При загрузке страницы было выполнено три ненужных повторных рендера. После их удаления были получены следующие результаты:
- Меньше количества длительных задач (см. следующий рисунок)
- Меньше общего времени блокировки (сравните рисунки 14 и 15)
Государственное размещение
Неправильное размещение состояния React может замедлить работу приложения и сделать пользовательский интерфейс неотзывчивым. При изменении состояния компонента его дочерние компоненты по умолчанию перерисовываются, если не используется аварийный выход (например, memo).
Как объяснялось в предыдущем разделе, повторная визуализация сама по себе не плоха, но повторная визуализация всей страницы из-за обновления определенного состояния может привести к более медленному взаимодействию, поскольку обновления DOM происходят после визуализации.
Например, на странице поиска есть диалоговое окно, которое показывает все фильтры при нажатии кнопки.
Состояние, управляющее открытым диалоговым окном в данном случае, было помещено на страницу поиска. При изменении этого состояния вся страница перерисовывалась, что приводило к некорректному INP, особенно на медленных устройствах, что наблюдалось при использовании ограничения загрузки процессора в DevTools:
Изменение состояния как можно ближе к компоненту, вызывающему изменение, решает эту проблему. В данном случае состояние можно поместить в компонент «кнопка» фильтров, чтобы при изменении состояния обновлялась только кнопка.
Удалить ненужные состояния
Состояния не должны содержать избыточную или дублированную информацию. В противном случае это может привести к ненужным повторным отрисовкам и вызвать проблемы.
Например, на панели фильтров Fotocasa есть текст, отображающий количество фильтров, примененных для данного поиска:
Количество примененных фильтров рассчитывается на основе состояния приложения. Однако это приводило не только к ненужной перерисовке всего компонента, но и в некоторых случаях к смещению макета, поскольку этот компонент рендерится на стороне сервера:
const [filtersCount, setFiltersCount] = useState(DEFAULT_COUNTER)
useEffect(() => {
const counter = filters
? Object.keys(filters)
?.reduce(reducerCounter, [])
?.filter((param) => searchParams?.[param]).length
: DEFAULT_COUNTER
setFiltersCount(counter)
}, [searchParams]);
Чтобы решить эту проблему, значение было получено из объекта фильтров с использованием переменной вместо использования состояния:
const counter = filters
? Object.keys(filters)
?.reduce(reducerCounter, [])
?.filter((param) => searchParams?.[param]).length
: DEFAULT_COUNTER;
Уменьшите дорогостоящие рендеры
Взаимодействие в React-приложении обычно приводит к изменению состояния. Как объяснялось ранее, при изменении состояния компонента он будет перерисован вместе со всеми своими дочерними элементами.
Если один из этих компонентов отображает функции медленно, это отрицательно скажется на INP страницы, поскольку, скорее всего, будет сгенерирована длительная задача, а обновление DOM займет больше времени.
Команда Fotocasa постаралась максимально минимизировать времязатратные вычисления в функции рендеринга компонентов. Инструменты разработчика Chrome и React Developer Tools оказались весьма полезны для обнаружения медленных операций рендеринга.
Задержка выполнения кода
Помимо оптимизации функции рендеринга компонентов, были оптимизированы и другие функции для максимального сокращения длительных задач. Однако некоторые задачи не удалось оптимизировать, поскольку они зависели от стороннего кода.
Одним из примеров была аналитика. В данном случае было решено отложить выполнение аналитического кода и отдать приоритет обновлениям DOM при взаимодействии пользователя. Для этого команда Fotocasa использовала библиотеку idlefy, которая также гарантировала, что аналитический код продолжит работать даже после немедленного закрытия браузера.
Культура производительности
Performance work is not a one-time effort, it's something that must be considered with every feature released to production. Everyone on the team needs to be aligned, otherwise regressions in Core Web Vitals are almost inevitable.
Чтобы оставаться в курсе событий, команда Fotocasa активно делилась знаниями внутри команды и разработала чёткую структуру для выявления проблем производительности на основе данных RUM от Fotocasa Datadog, включая способы их воспроизведения. Оповещения по основным веб-показателям, особенно INP, были настроены в системе RUM и отправлялись непосредственно команде Fotocasa в Slack. Такой подход позволял уделять первостепенное внимание производительности и помог выявлять проблемы до того, как они перерастали в регрессии.
Результаты
Улучшение INP в Fotocasa потребовало сочетания технической оптимизации и изменений в культуре. Устранив ненужные повторные рендеры, оптимизировав размещение состояний, сократив количество дорогостоящих рендеров и отложив некритический код, команда Fotocasa успешно перевела все десктопные страницы из категории «требует доработки» в категорию «хорошо» и значительно улучшила мобильные страницы, обновив почти все страницы из категории «плохо» и «требует доработки» в категорию «хорошо».
Эти изменения улучшили общее впечатление пользователей от Fotocasa и, в сочетании с другими инициативами, привели к увеличению количества рекламных объявлений с контактами и телефонными звонками на 27% , что напрямую улучшило ключевые бизнес-показатели компании.
Мониторинг в режиме реального времени с помощью Datadog позволил команде Fotocasa проверить улучшения INP, быстро обнаружить аномалии и предотвратить регрессии. Помимо этих достижений, Fotocasa также удалось внедрить веб-производительность в свою культуру разработки, гарантируя, что INP и Core Web Vitals остаются приоритетными в каждом выпуске.