В современном веб-развитии скорость и отзывчивость сайта играют ключевую роль в успехе продукта. Особенно это актуально для платформ, ориентированных на образовательные услуги и с высокой долей SEO и SEM, таких как Preply. Один из важнейших показателей, оценивающих пользовательский опыт, — Interaction to Next Paint (INP), который измеряет задержку реакции страницы на взаимодействия пользователя. Preply взялся за сложный проект по улучшению INP на своём крупном приложении, построенном с использованием Next.js, но при этом без задействования React Server Components и нового App Router.
Результат оказался впечатляющим — снижение INP и экономия порядка 200 тысяч долларов в год. Рассмотрим, как компании удалось добиться таких успехов и какие уроки будут полезны для всего сообщества фронтенд-разработчиков. Preply — профиль компании и особенности приложения Preply — это международная платформа для поиска репетиторов, которая активно работает как с частными пользователями, так и внутри B2B-сегмента. На сайте множество проиндексированных страниц, с особым упором на главную страницу и страницу поиска репетиторов — два ключевых направления с точки зрения SEO и SEM. Архитектура Next.
js здесь используется с маршрутизатором Pages, то есть более классической мультистраничной моделью, при этом проект содержит значительный объем технического долга и сложностей, накопившихся за годы быстрого роста. Подход к INP и его значение INP — это метрика, которая измеряет наихудшую задержку между началом пользовательского взаимодействия и моментом, когда браузер способен отрисовать обновления на экране. В отличие от некоторых других Web Vitals, INP оценивает не только первый пользовательский опыт, но и всю сессию, выявляя реальные «узкие места» во взаимодействии. Для Preply показатель INP особенно важен, так как большая часть посещений происходит на мобильных устройствах, зачастую с низкой производительностью, что может значительно влиять на восприятие сайта. Продуманное улучшение INP напрямую влияет на результаты поискового продвижения и эффективность рекламных кампаний через повышение показателя качества и снижение стоимости клика.
Анализ данных и первичные гипотезы Процесс оптимизации начался с обширного сбора данных с помощью библиотеки web-vitals от Google, кастомных метрик Next.js, системы аналитики DataDog, а также инструментов профилирования, таких как React Developer Tools и Hotjar для анализа поведения пользователей. Основными предположениями были необходимость уменьшить время гидратации React-компонентов, чтобы страницу быстрее сделать интерактивной, и оптимизация самого JavaScript-кода, отвечающего за логику и взаимодействия на сайтах. Оказалось, что в среднем гидратация заняла около 120 миллисекунд — довольно быстрый показатель, что заставило отказаться от идеи о её сильном влиянии на INP. Вместо этого внимание переключилось на отдельные узкие места в коде и пользовательских сценариях.
Технические подходы к снижению INP Улучшения коснулись нескольких направлений. Ключевым положением стало виртуализация длинных списков, например, списка «Страны рождения» в поисковой странице с 300 элементами. Использование React Virtuoso позволило снизить нагрузку на DOM и уменьшить время реакции примерно на 40 миллисекунд, что неплохо для такой задачи. Другой важный шаг — дебаунсинг событий клавиатуры, что значительно улучшило отзывчивость полей ввода, где ранее задержка доходила до 600 миллисекунд, а после — снизилась до более комфортных 70 мс. Оптимизация повторных рендеров крупных статичных компонентов через мемоизацию сократила лишние вычисления и выигрыш составил примерно 30 мс.
Ещё одним сюрпризом стали проблемы с компонентом тултипа на базе Radix UI, где из-за неточного типа состояния в TypeScript происходил избыточный ререндер при кликах вне тултипа. Исправление инициализации состояния привело к снижению INP на 10 мс. Важная оптимизация пришла с обновлением третьей стороны — системы управления пользовательским согласием Usercentrics. Обновление до третьей версии и одновременное улучшение Google Tag Manager помогли снизить влияние лишнего JavaScript, что дало значительный эффект на простой главной странице и небольшой — на поисковой. Несколько параллельных гипотез и экспериментов казались многообещающими, однако не дали ощутимого результата.
Это включало использование React useDeferredValue для размытия обновлений состояния, большой рефакторинг и чистку кода, небольшой оптимизации чата и даже отключение RUM-метрик DataDog. Все они были полезны для общего качества кода, но непосредственно INP не уменьшили. Почему отказались от Partytown и React Server Components Попытки переводить сторонние скрипты, загружаемые через Google Tag Manager, в веб-воркеры с помощью Partytown оказались слишком рискованными и непредсказуемыми. Зависимости, добавленные десятилетиями, приводили к цепочкам скриптов, выполняющихся в основном потоке, сводя на нет эффект от изоляции. Это заставило отказаться от этой идеи и сосредоточиться на своих внутренних оптимизациях.
Миграция на новейшие возможности Next.js, такие как App Router и React Server Components (RSC), была реализована частично для главной страницы с учебной целью. Реальный прирост INP оказался минимальным (около 10 мс), гораздо меньше ожидаемого. Проблема заключалась в том, что проект не выполнял полную переработку страниц с учетом апдейтов архитектуры, от чего потенциал новых функций оставался несостоятельным. Дополнительные наблюдения и рекомендации Важным результатом стала роль тщательного анализа и ориентированного сбора реальных данных с пользователей.
Исключительно благодаря данным удалось выявить причины тормозов, а не делать слепые предположения, что очень часто встречается в индустрии. Работы над улучшением длились более месяца — первые результаты не появились мгновенно, много времени ушло на проверку, измерения и калибровку влияния каждого изменения. Это подчёркивает, что производительность — это долговременный процесс, требующий терпения и системного подхода. Значимым выводом стал отказ от «заплаток» и обходных путей типа await-interaction-response, позволяющих лишь скрыть проблему без её реального решения. Preply предпочел сосредоточиться на исправлении первопричин, чтобы не создавать технический долг и постепенно улучшать качество продукта.
Повышение UX и влияние на бизнес Понижение INP улучшило восприятие сайта конечными пользователями, особенно на мобильных устройствах с низкой производительностью. Это положительно сказалось не только на метриках Core Web Vitals, но и на бизнес-показателях — команда Preply оценила потенциальную экономию в 200 тысяч долларов в год благодаря более высокому Quality Score в системах рекламы и лучших показателях конверсии. Долгосрочные планы включают постоянный мониторинг Web Vitals с помощью аналитики, обучение команд фронтенд-разработчиков и интеграцию производительности в жизненный цикл продукта. Итоги кейса Preply Пример Preply ярко демонстрирует, что не всегда самые модные технологии дают максимальный эффект по оптимизации производительности. Глубокое понимание пользовательских сценариев, продуманное использование данных и последовательная работа с «узкими местами» кода оказываются самым надежным путем к успеху.
Их опыт показывает, что даже без внедрения Server Components можно значительно улучшить взаимодействие пользователей и сэкономить серьезные средства. Это важный урок для всех разработчиков больших проектов на React и Next.js — ставить на первое место анализ и качество кода, а не только погоню за новыми фреймворками и фишками. В итоге, Preply не только повысил INP, но и получил более отзывчивый продукт, облегчивший жизнь как клиентам, так и самой команде разработчиков.
