چگونه بهبود INP Fotocasa به رشد 27٪ در معیارهای کلیدی کمک کرد

Andrés Alvarez

Oriol Hilari

Nacho Rodriguez

Joan León

تاریخ انتشار: 14 اکتبر 2025

Interaction to Next Paint (INP) یک معیار حیاتی Core Web Vital برای سنجش پاسخگویی است. در Fotocasa، کنسول جستجوی Google تعداد قابل توجهی از صفحات را مشخص کرد که برای زمانی که INP جایگزین تاخیر ورودی اولیه (FID) در سال 2024 شد، به "نیاز به بهبود" و "ضعیف" تغییر یافتند. این مطالعه موردی ابزارها و استراتژی‌های به کار رفته برای تشخیص و حل این مشکلات را مشخص می‌کند و در نهایت INP را با حاشیه بهبود می‌بخشد.

جایی که تیم Fotocasa شروع کرد

قبل از تغییر از FID به INP، تقریباً هر صفحه در دسکتاپ و موبایل در آستانه "خوب" بود، به این معنی که تمام Core Web Vitals در آن زمان (LCP، CLS و FID) عملکرد خوبی داشتند. با این حال، پس از تغییر به INP، تقریباً همه صفحات به «نیاز به بهبود» و برخی حتی به «ضعیف» تغییر کردند، زیرا مقادیر INP به طور مداوم برای بیشتر تعاملات کاربر از 200 میلی ثانیه فراتر رفت.

این تغییر باعث شد تیم Fotocasa متوجه شود که جنبه مهمی از تجربه کاربر را نادیده گرفته است. در حالی که FID فقط تأخیر اولین تعامل را اندازه‌گیری می‌کند، INP پاسخگویی همه تعامل‌ها را ارزیابی می‌کند، پردازش ورودی و تأخیر ارائه را محاسبه می‌کند. این اندازه گیری گسترده تر، پروکسی بسیار بهتری برای تعامل واقعی (همانطور که توسط گوگل بیان شده است ) است و فرصت های از دست رفته را برجسته می کند.

حتی اگر کنسول جستجوی گوگل داده‌های عملکرد میدانی را ارائه می‌دهد، اطلاعات بینش در زمان واقعی را ارائه نمی‌کند. داده‌های آن در یک پنجره ۲۸ روزه جمع‌آوری می‌شوند، که تعیین دقیق اینکه کدام تعاملات در حال حاضر باعث ایجاد مشکل شده‌اند را دشوار می‌کند.

راهی برای ردیابی INP در زمان واقعی به منظور شناسایی تعاملاتی که هم کندترین و هم بیشترین استفاده را توسط کاربران داشتند و بازتولید آنها به طور قابل اعتماد در محیط های توسعه تیم مورد نیاز بود. به همان اندازه مهم درک تأثیر تغییرات ایجاد شده بود، نه تنها این که کدام اصلاحات کمک کرد، بلکه همچنین اینکه کدام ترفندها به طور ناخواسته اوضاع را بدتر کردند.

به این دلایل، مجموعه ای از ابزارها برای کمک به تشخیص و حل مشکلات استفاده شد. مهمترین آنها عبارت بودند از:

• Google Chrome DevTools، مخصوصاً تب Performance.
• یک سیستم RUM سفارشی ( نظارت بر کاربر واقعی ) که توسط تیم Fotocasa در Datadog با استفاده از کتابخانه web-vitals ساخته شده است.
• React Developer Tools.

ابزارهایی برای تشخیص مشکل

برای تشخیص و رفع اشکال مشکلات عملکرد INP، از ابزارهای زیر استفاده شد.

Google Chrome DevTools

یک راه عالی برای شناسایی و بازتولید مسائل مربوط به Core Web Vitals در یک برنامه وب، استفاده از برگه Performance در Google Chrome DevTools است. برگه Performance معیارهای Core Web Vitals را به صورت خودکار اندازه گیری می کند و بازخورد فوری در مورد بارگیری، تعامل و معیارهای تغییر طرح ارائه می دهد. به طور کلی با نحوه گزارش این معیارها به سایر ابزارهای Google مطابقت دارد.

برای شناسایی و حل مشکلات INP، تیم Fotocasa معمولاً با مهار کردن CPU برای شبیه‌سازی عملکرد دستگاه‌های رده پایین و متوسط ​​شروع کردند. این به تیم Fotocasa اجازه داد تا نحوه رفتار صفحه را در شرایط محدودتر مشاهده کنند. سپس جلسه با استفاده از پروفایلر ضبط شد و ردیابی ها با تمرکز بر تعامل کاربر برای مشخص کردن مشکلات عملکرد به دقت تجزیه و تحلیل شدند.

هنگام شناسایی تنگناها، بررسی بخش‌های فرعی INP و وظایفی که مرورگر در هر یک از آنها انجام می‌دهد بسیار مفید است. به عنوان مثال، در تصویر زیر مشاهده می شود که INP به دلیل دو محاسبه مجدد سبک ناشی از تغییر سبک در بدنه سند، بسیار بالا است.

Fotocasa سیستمی را برای ردیابی INP و سایر معیارهای Core Web Vital راه‌اندازی کرد و اطمینان حاصل کرد که هر گونه مشکل عملکرد به سرعت شناسایی و برطرف می‌شود. هنگامی که یک متریک از یک آستانه خاص فراتر می رود (بر اساس محدوده های تعریف شده گوگل)، انتساب ثبت می شود تا مشکل قابل تجزیه و تحلیل و حل شود.

برای آن سیستم، از کتابخانه web-vitals استفاده شد تا این معیارها را از کاربران واقعی به‌گونه‌ای جمع‌آوری کند که دقیقاً با نحوه اندازه‌گیری آن‌ها توسط Chrome و گزارش آن‌ها به سایر ابزارهای Google (مانند گزارش تجربه کاربر Chrome، اطلاعات سرعت صفحه، گزارش سرعت کنسول جستجو و موارد دیگر) مطابقت داشته باشد.

برای یک نمای جامع و ردیابی متمرکز، Fotocasa از Datadog برای جمع‌آوری و تجسم داده‌ها استفاده کرد و تیم را قادر می‌سازد تا تصمیمات آگاهانه و مبتنی بر داده را بگیرد. معیارهای سفارشی آن را مقرون به صرفه نگه می دارد و تقریباً همه کاربران را در وب سایت Fotocasa بهتر می تواند ردیابی کند.

این سیستم به تیم Fotocase این امکان را می دهد که به سرعت بررسی کنند که آیا تغییرات آنها بر معیارها تأثیر می گذارد یا اگر تغییرات پیش بینی نشده ای رخ دهد که به طور بالقوه آنها را به خطر می اندازد. سپس متریک INP می تواند به بخش هایی مانند تاخیر ورودی، مدت زمان پردازش و تاخیر ارائه تقسیم شود تا دقیقا مشخص شود که کدام بخش از تعامل عمدتاً مسئول زمان های تعامل طولانی است.

پس از شناسایی ناهنجاری‌ها، مانند آنچه در شکل‌های 7 و 8 نشان داده شده است، Fotocasa به سرعت پاسخ داد و از OpenSearch استفاده کرد، ابزار دیگری که به تعیین دقیق محل وقوع تغییر کمک کرد. داده های ارائه شده توسط کتابخانه web-vitals به شناسایی هدف کمک می کند (عنصر DOM به طور بالقوه مسئول یک مقدار متریک بالا است) و به تیم کمک می کند تا با جدیت بیشتری روی رفع مشکل تمرکز کند.

علاوه بر این، فیلترهای مختلفی را می توان تعریف کرد، مانند نوع صفحه، دستگاه یا وضعیت بارگذاری برای ساده کردن سناریوها و به دست آوردن درک دقیق تری از نحوه تأثیرگذاری INP.

React Developer Tools

React Developer Tools برای افزایش قابلیت‌های اشکال‌زدایی Fotocasa استفاده شد، که ویژگی قدرتمندی را ارائه می‌دهد که به شما امکان می‌دهد مولفه‌هایی را که به‌صورت بصری دوباره رندر شده‌اند برجسته کنید.

این ویژگی را می توان با رفتن به تب Profiler فعال کرد. از آنجا، روی چرخ دنده در سمت راست نوار بالا کلیک کنید، به برگه عمومی بروید و چک باکس Highlight updates when components render را علامت بزنید. با فعال شدن این، مؤلفه‌ها هنگام بازپرداخت برجسته می‌شوند و یک نمایش بصری پویا ارائه می‌دهند.

پیدا کردن علت بازپرداخت

هنگامی که کامپوننتی که دوباره رندر شده است شناسایی شد، سوال بعدی این است که "چرا این اتفاق افتاد؟" React DevTools با یک راهنمای ابزار مفید در نمای نمودار شعله پاسخ می دهد.

برای دسترسی به این اطلاعات، یک جلسه نمایه ساز را ضبط کنید. با تجزیه و تحلیل خروجی پروفایلر، اطلاعات مفیدی خواهید یافت:

• در گوشه سمت راست بالا، تعداد React commit ها نمایش داده می شود.
• نمودار شعله به صورت بصری درخت مؤلفه را نشان می‌دهد، با خاکستری نشان‌دهنده مؤلفه‌هایی است که دوباره رندر نشده‌اند. هر نوار نشان دهنده لحظه ای است که درخت مؤلفه React تغییر می کند، و زمانی که تغییر مربوطه به DOM انجام می شود.
• با نگه داشتن ماوس روی هر جزء در نمودار شعله، دلیل رندر مجدد آن در قسمت Why did this نشان می دهد؟ "عنوان فرعی.

دلایل رندر مجدد کامپوننت ممکن است شامل موارد زیر باشد:

• این اولین بار است که کامپوننت ارائه می شود
• متن تغییر کرد
• قلاب ها عوض شد
• لوازم جانبی تغییر کرد
• حالت تغییر کرد
• مؤلفه والد ارائه شده است

پیدا کردن زمان رندر

رنگ ها در نمودار شعله اطلاعات معنی داری را منتقل می کنند. رنگ‌هایی مانند سایه‌های مختلف آبی نشان می‌دهند که یک جزء به زمان رندر نسبتاً کوتاهی در مقایسه با سایر اجزا نیاز دارد. برعکس، رنگ‌هایی مانند نارنجی و قرمز نشان می‌دهند که یک جزء زمان رندر بیشتری را متحمل شده است.

چگونه تیم Fotocasa مشکل را برطرف کرد

رندرهای غیر ضروری را حذف کنید

هر زمان که React نیاز به به روز رسانی رابط کاربری با داده های جدید داشته باشد، رندرها انجام می شود. این معمولاً از یک اقدام کاربر، یک پاسخ API یا سایر رویدادهای مهمی که نیاز به به روز رسانی رابط کاربری دارند ناشی می شود. از آنجایی که هر رندر جاوا اسکریپت را اجرا می کند، تعداد زیادی از آنها به طور همزمان - به خصوص در یک درخت کامپوننت بزرگ - می توانند رشته اصلی را مسدود کرده و باعث مشکلات عملکرد شوند.

دو نوع رندر وجود دارد:

• بازپرداخت های ضروری: زمانی که یک مؤلفه واقعاً نیاز به به روز رسانی دارد زیرا دارای داده های تازه است یا از آن استفاده می کند.
• رندرهای غیرضروری: زمانی که یک جزء بدون هیچ تغییر معنی‌داری به‌روزرسانی می‌شود، اغلب به دلیل مدیریت ناکارآمد وضعیت یا مدیریت نامناسب پایه.

چند رندر غیر ضروری معمولاً چیز مهمی نیستند، زیرا React به اندازه‌ای سریع است که کاربران معمولاً متوجه آن نمی‌شوند. با این حال، اگر آنها خیلی اوقات یا در یک درخت جزء سنگین اتفاق بیفتند، می توانند به تجربه کاربر آسیب بزنند و بر INP صفحه تأثیر منفی بگذارند.

این مورد برای تیم Fotocasa بود. آنها متوجه شدند که وب سایت دارای بسیاری از بازپرداخت های غیر ضروری است. اینها در دو سناریو اصلی اتفاق افتاد:

• در حین بارگذاری صفحه: افزایش تعداد کارهای طولانی در موضوع اصلی و به تاخیر انداختن اولین تعامل که بر INP صفحه تأثیر منفی گذاشت.
• در طول تعاملات کاربر: افزایش زمان پردازش بیشتر تعاملات که به INP نیز آسیب می رساند.

بسیاری از رندرهای غیر ضروری در وب سایت Fotocasa بهینه شدند. یکی از بزرگترین بهینه سازی های انجام شده در صفحه جستجو بود. سه رندر غیر ضروری در بارگذاری صفحه وجود داشت. پس از حذف این موارد، نتایج زیر مشاهده شد:

• تعداد کارهای طولانی کمتر (شکل زیر را ببینید)
• زمان انسداد کل کمتر (شکل های 14 و 15 را مقایسه کنید)

محل سکونت ایالتی

قرار دادن نامناسب وضعیت React می تواند سرعت برنامه را کاهش دهد و باعث شود رابط کاربری پاسخگو نباشد. هنگامی که وضعیت یک مؤلفه تغییر می کند، مؤلفه های فرزند آن به طور پیش فرض دوباره رندر می شوند مگر اینکه از دریچه فرار استفاده شود (مثلاً یادداشت).

همانطور که در بخش قبل توضیح داده شد، رندرها ذاتا بد نیستند، اما رندر مجدد کل صفحه به دلیل یک به‌روزرسانی وضعیت خاص می‌تواند منجر به تعامل کندتر شود، زیرا به‌روزرسانی‌های DOM پس از رندر انجام می‌شوند.

به عنوان مثال، در صفحه جستجو یک گفتگو وجود دارد که با کلیک روی یک دکمه، تمام فیلترها را نشان می دهد.

حالتی که حالت باز گفتگو را در این مورد کنترل می کند در صفحه جستجو قرار داده شد. هنگامی که این حالت تغییر کرد، کل صفحه دوباره رندر می‌شد و باعث ایجاد INP بد می‌شد، به‌ویژه در دستگاه‌های کندتر، همانطور که در هنگام استفاده از throttling CPU در 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]);

برای حل این مشکل، مقدار از شی filters با استفاده از یک متغیر به جای استفاده از حالت استخراج شد:

const counter = filters
    ? Object.keys(filters)
        ?.reduce(reducerCounter, [])
        ?.filter((param) => searchParams?.[param]).length
    : DEFAULT_COUNTER;

کاهش رندرهای گران قیمت

هنگامی که یک تعامل در یک برنامه React رخ می دهد، معمولاً باعث تغییر حالت می شود. همانطور که قبلا توضیح داده شد، هنگامی که وضعیت یک جزء تغییر می کند، کامپوننت به همراه تمام فرزندان آن دوباره رندر می شود.

اگر یکی از این مؤلفه‌ها عملکردهای رندر کند کند، بر INP صفحه تأثیر منفی می‌گذارد زیرا احتمالاً یک کار طولانی ایجاد می‌شود و DOM زمان بیشتری برای به‌روزرسانی می‌گیرد.

تیم Fotocasa سعی کرد تا حد امکان محاسبات زمان بر را در تابع رندر کامپوننت ها به حداقل برساند. Chrome DevTools و React Developer Tools در تشخیص عملیات رندر کند بسیار مفید بودند.

تاخیر در اجرای کد

علاوه بر بهینه سازی عملکرد رندر کامپوننت ها، سایر توابع برای به حداقل رساندن کارهای طولانی تا حد امکان بهینه سازی شدند. با این حال، برخی از کارها را نمی توان بهینه کرد زیرا به کد شخص ثالث وابسته بودند.

یک مثال آنالیز بود. در این مورد، تصمیم بر این شد که اجرای کدهای تحلیلی به تعویق بیفتد و به‌روزرسانی‌های DOM در هنگام تعامل با کاربر اولویت‌بندی شود. برای دستیابی به این هدف، تیم Fotocasa از کتابخانه‌ای به نام idlefy استفاده کرد که همچنین تضمین می‌کرد که حتی اگر مرورگر بلافاصله پس از آن بسته شود، کد تجزیه و تحلیل همچنان اجرا می‌شود.

فرهنگ عملکرد

کار اجرایی یک تلاش یکباره نیست، چیزی است که باید با هر ویژگی منتشر شده برای تولید در نظر گرفته شود. همه اعضای تیم باید همسو باشند، در غیر این صورت رگرسیون در Core Web Vitals تقریباً اجتناب ناپذیر است.

برای حفظ این موضوع، تیم Fotocasa به طور فعال دانش را در تیم به اشتراک گذاشت و یک چارچوب روشن برای شناسایی مشکلات عملکرد بر اساس داده‌های Datadog RUM Fotocasa، از جمله نحوه بازتولید آنها ایجاد کرد. هشدارها برای Core Web Vitals - به ویژه INP - در سیستم RUM تنظیم شدند، پیکربندی شده‌اند تا مستقیماً در Slack به تیم Fotocasa اطلاع دهند. این رویکرد عملکرد را در سرلوحه ذهن خود نگه داشت و به حل مسائل قبل از تبدیل شدن به رگرسیون کمک کرد.

نتایج

بهبود INP در Fotocasa به ترکیبی از بهینه‌سازی‌های فنی و تغییرات فرهنگی نیاز داشت. تیم Fotocasa با حذف رندرهای غیرضروری، بهینه سازی قرار دادن حالت، کاهش رندرهای گران قیمت و به تعویق انداختن کدهای غیر بحرانی، با موفقیت تمام صفحات دسکتاپ را از «نیاز به بهبود» به «خوب» منتقل کرد و با ارتقای تقریباً همه صفحات «ضعیف» و «نیاز به بهبود» به «good» به طور قابل توجهی صفحات موبایل را بهبود بخشید.

این تغییرات تجربه کاربری کلی Fotocasa را بهبود بخشید و همراه با ابتکارات دیگر، باعث افزایش 27 درصدی در تبلیغات تماس و تلفن شد و به طور مستقیم معیارهای تجاری کلیدی شرکت را تقویت کرد.

نظارت بلادرنگ با Datadog به تیم Fotocasa اجازه داد تا بهبودهای INP را تأیید کند، ناهنجاری‌ها را سریع تشخیص دهد و از رگرسیون جلوگیری کند. فراتر از این دستاوردها، Fotocasa همچنین موفق شد عملکرد وب را در فرهنگ توسعه خود جاسازی کند و اطمینان حاصل کند که INP و Core Web Vitals در هر نسخه اولویت باقی می‌مانند.