مقالهٔ این سایت دربارهٔ شاخص‌های تجربهٔ کاربر، پیش از تغییرِ متریک تعامل نوشته شده و هنوز «تأخیر نخستین ورود» را معیار می‌داند. از 12 مارس 2024، آن متریک دیگر در دادهٔ میدان گزارش نمی‌شود و جایش را به سنجش «پاسخ بدترین تعامل» داده است. پس این صفحه، نسخهٔ تازهٔ همان بحث نیست؛ لایهٔ عمیقِ جدا از آن است، و اگر فقط یکی را می‌خوانی، این را بخوان چون تشخیصِ کندیِ حس‌شده، حالا ابزار دیگری می‌خواهد.
نکته‌ای که بیشترِ راهنماها از آن می‌گذرند: این تغییر، رابطهٔ «نمره» و «احساس کاربر» را عوض کرد. سایتی که در Lighthouse سبز است و پیشخوان یا فرم تسویه‌اش چند صد میلی‌ثانیه بعد از کلیک جواب میدهد، دیگر یک پارادوکس نیست؛ حالت عادیِ همان صفحه است. در ادامه می‌گویم متریک تازه دقیقاً چه می‌سنجد، در یک سایت وردپرسی روی سی‌پنل و لایت‌اسپید مقصرهای واقعی کدام‌اند، چطور با ابزار توسعه‌دهنده اسم فایل و خط را پیدا کنی، و بعد از رفع، چطور با دادهٔ واقعیِ کاربرانِ خودت تأیید کنی که درست کار کرده‌ای.
یک: متریک پیشین چه می‌سنجد و چه چیزی را پنهان می‌کرد
FID فاصلهٔ زمانی میان دو لحظه بود: لحظه‌ای که کاربر برای اولین بار چیزی را لمس یا کلیک می‌کند یا کلید می‌زند، و لحظه‌ای که مرورگر می‌تواند شروع به اجرای هندلر آن رویداد کند. دقت کن: شروع اجرای هندلر، نه پایان آن. یعنی اگر هندلر تو چند صد میلی‌ثانیه کار همگام انجام می‌داد، متریک پیشین می‌توانست عددی کوچک نشان دهد.
سه محدودیت داشت که هر سه، مستقیمِ تصمیمِ جایگزینی بودند.
محدودیت اول: فقط نخستین ورود. کاربری که وارد صفحه می‌شود، منو را می‌زند، اسلایدر را می‌کشد و دکمهٔ افزودن به سبد را فشار میدهد، تنها با همان نخستین لمس قضاوت می‌شد. اگر آن لمس اول روی متنی بی‌اسکریپت اتفاق می‌افتاد، بازدید «خوب» ثبت می‌شد و بقیهٔ تعامل‌ها هیچ وزنی نداشتند.
محدودیت دوم: فقط تأخیر، نه پردازش، نه نقاشی. کاری که خودِ کد تو بعد از شروع هندلر انجام میدهد و زمانی که صفحه طول می‌کشد تا تغییر را روی نمایشگر نشان دهد، خارج از معیار بود. پس صفحه‌ای با هندلرِ سنگین، نمرهٔ تمیز می‌گرفت.
محدودیت سوم: نبودِ داده در ابزارهای آزمایشگاهی. چون این کمیت وابسته به یک ورود واقعی بود، در شبیه‌سازی قابل اندازه‌گیری نبود؛ ابزارهای آزمایشگاهی مجبور بودند عددی جایگزین و شبیه‌سازی‌شده برای «کار روی نخ اصلی» گزارش کنند، نه خودِ تأخیر. یعنی نمره‌ای که می‌دیدی، سایهٔ متریک بود نه متریک.
نتیجه‌اش را در پروژه‌ها دیدیم: تنظیماتی که اسکریپت‌ها را عقب می‌انداختند، عدد آزمایشگاهی را بالا می‌بردند و همان‌وقت کاربر روی موبایل، همان کلیک را دو بار می‌زد.
دو: متریک تازه چه می‌سنجد؛ سه بخشِ یک پاسخ
INP برای هر تعاملِ کاربر در طول بازدید، سه فاصله را جمع می‌کند و بعد بدترینشان را انتخاب می‌کند.
تأخیر ورود. فاصلهٔ ثبت رویداد تا شروع اجرای اولین هندلر. این همان بخشی است که متریک پیشین تنها می‌دید. علتش کارِ نیمه‌تمام روی نخ اصلی است: اگر تسکی در حال اجرا باشد، ورودی در صف می‌ماند. تسکی که بیشتر از 50 میلی‌ثانیه روی نخ اصلی بماند، تسک بلند حساب می‌شود و خوراکِ همین تأخیر است.
مدت پردازش. وقتی هندلرها اجرا شدند و کارشان تمام شد. اینجا جایی است که کد خودت، افزونهٔ قالب، تگ‌های تحلیلی که روی کلیک می‌افتند، و حلقه‌های همگامِ بزرگ هزینه می‌سازند.
تأخیر نمایش. فاصلهٔ پایان پردازش تا نقاشیِ بعدی، یعنی تا لحظه‌ای که کاربر تغییر را روی صفحه می‌بیند. این بخش را درختِ DOM بزرگ، تغییر سبک‌های زیاد در یک نوبت، و کار چیدمانِ اجباری بالا می‌برد.
سه قاعدهٔ مهم که باعث می‌شود تفسیر عدد را درست کنی: تعاملی در شمارش می‌آید که پاسخِ دیدنی داشته باشد؛ آخرین تعاملِ هر بازدید حذف می‌شود، چون ممکن است صفحه پیش از نقاشی بسته شود؛ و در دادهٔ میدان Chrome برای هر بازدید، تقریبی از صدک 98 تعامل‌ها گرفته می‌شود، که عملاً یعنی «بدترینِ قابل‌اتکا»، نه میانگین. بعد میان بازدیدهای همان صفحه، صدک 75 گزارش می‌شود.
بنابراین متریک تازه، بدترین تجربهٔ رایج است، نه بهترین. و همین یک جمله، کل تغییرِ طرز فکر است.
سه: آستانه‌ها؛ کجای عدد سبز است
اعداد زیر، آستانه‌های رسمیِ خودِ متریک‌اند و تنها اعدادی‌اند که در این مقاله به‌عنوان «معیار» استفاده می‌کنم؛ بقیهٔ عدد را باید خودت روی سایت خودت اندازه بگیری.
| وضعیت | بازهٔ INP در صدک 75 | معادل فارسی در گزارش‌ها | |—|—|—| | سبز | 200 میلی‌ثانیه یا کمتر | خوب | | زرد | بین 200 تا 500 میلی‌ثانیه | نیازمند بهبود | | قرمز | بیشتر از 500 میلی‌ثانیه | بد |
برای مقایسه، آستانه‌های متریک پیشین 100 و 300 میلی‌ثانیه بود. پس عددِ آستانه بالاتر رفته، اما تعریفِ چیزی که اندازه گرفته می‌شود سخت‌گیرانه‌تر شده است؛ این دو را با هم مقایسه نکن و نگو «معیار آسان‌تر شد».
سه نکتهٔ عملی از همین جدول:
اول، چون معیار صدک 75 است، رفعِ مشکلِ تعاملی که یک‌بار در ده بازدید رخ میدهد، لزوماً عدد را تکان نمی‌دهد. برعکسش هم درست است: اگر همان کلیکِ کند، در بیش از یک‌چهارمِ بازدیدها اتفاق بیفتد، صفحه در همان آستانه می‌ماند. پس اول برو سراغ تعاملی که تعدادِ کاربرانش زیاد است: منوی موبایل، جابه‌جایی در تسویه، فیلد جستجو.
دوم، سبزِ آستانه یعنی همان 200، نه «کمتر از دیروز». اگر عددت از چند برابرِ آستانه به کمی بالاتر از آستانه رسیده، پیشرفت کرده‌ای ولی هنوز زرد است و در گزارشِ سنجشِ میدان هم زرد می‌ماند.
سوم، وضعیتِ متریک‌های بارگذاری و جابه‌جایی چیدمان جدا حساب می‌شود؛ یک صفحه می‌تواند در یکی سبز و در دیگری قرمز باشد، و درمان‌شان هم متفاوت است.
چهار: دادهٔ میدان در برابر دادهٔ آزمایشگاه؛ فقط یکی حکم دارد
دو منبع داده داریم و خلطِ آن‌ها، اصلی‌ترین خطای این بحث است.
دادهٔ میدان. گزارشِ تجربهٔ کاربر Chrome، که از بازدیدهای واقعیِ کاربران Chrome ساخته می‌شود، پنجره‌ای متحرک 28 روزه دارد، و در سرچ‌کنسول برای هر گروه نشانی و جداگانه برای موبایل و میزبان، صدک 75 را نشان میدهد. صفحه‌ای که بازدید کافی نداشته باشد در گزارش نمی‌آید و باید به سطح نام میزبان نگاه کنی. فقط مرورگرهای شرکت‌کننده را می‌بیند، پس نمونه‌ی «همهٔ کاربران» نیست؛ ولی تنها چیزی است که در ارزیابیِ تجربهٔ کاربر و در گزارشِ سرچ‌کنسول حساب می‌شود.
دادهٔ آزمایشگاه. یک اجرای ساختارمند: ابزار توسعه‌دهنده روی میزبان تو، شبیه‌ساز موبایل، یا Lighthouse. ارزشش بازتولیدِ مشکل است، نه داوری. در این حالت تو خودت تصمیم می‌گیری چه چیزی را کلیک کنی، با کشِ گرم یا سرد، روی سخت‌افزار خودت، و با سرعت اینترنت خودت. همین‌ها عدد را عوض می‌کنند.
چرا این تفکیک بعد از تغییر متریک مهم‌تر شد؟ چون بهینه‌سازی‌های محبوبِ دورهٔ قبل، دقیقاً روی نخ اصلیِ زمان بارگذاری دست می‌بردند: عقب انداختن اسکریپت‌ها، ترکیب فایل‌ها، تنبل‌سازی. آن‌ها کارِ اولیه را کم می‌کنند و عددِ آزمایشگاهی را بهتر می‌سازند، ولی کار را حذف نمی‌کنند؛ فقط آن را می‌اندازند روی لحظه‌ای که کاربر چیزی را می‌زند. و متریک تازه، همان لحظه را می‌سنجد. نتیجه: نمره بالا، تجربهٔ بد. اگر می‌خواهی فهرست کامل لایه‌های زمان بارگذاری را ببینی، مقالهٔ «چرا سایت وردپرسی کند است» در همین خوشه آن را باز کرده است.
پنج: در یک سایت وردپرسی، مقصرها معمولاً کدام‌اند
فهرست زیر به ترتیبِ فراوانی در سایت‌های وردپرسیِ روی هاست اشتراکی چیده شده، نه به ترتیبِ حجم. هر مورد را با نشانهٔ تشخیصش آورده‌ام تا حدس نزنی.
یک: اسکریپت همگامِ بلند در لحظهٔ باز شدن. فایل بزرگِ ترکیب‌شده که پس از دانلود یک‌جا تجزیه و اجرا می‌شود و نخ اصلی را چند صد میلی‌ثانیه قفل می‌کند. نشانه: هر چیزی که در پنجرهٔ دو ثانیهٔ اول صفحه بخواهی بزنی، دیر جواب میدهد، ولی بعد از آن صفحه روان است.
دو: انبوه افزونه‌های مبتنی بر jQuery. اسلایدر، مگا منو، حساب‌کنندهٔ قیمت، گالری، فرم‌ساز، شمارندهٔ بازدید. هر کدام روی آماده‌شدن سند هندلر ثبت می‌کنند و هر کلیک، از زنجیره‌ای از هندلرها و از حباب‌شدنِ رویداد رد می‌شود. نشانه: کلیک روی دکمهٔ ساده، تسک بلندِ اجرا در فایلِ افزونهٔ بی‌ربط می‌سازد.
سه: مدیر تگ و اسکریپت‌های شخص ثالث. کانتینری که با هر کلیک یا هر جابه‌جایی صفحه، ده‌ها تگ را در یک نوبت اجرا می‌کند؛ تحلیلی، تبلیغ، چت، و بنرِ رضایت. نشانه: در پنلِ شبکه، درست در لحظهٔ کلیک، چند درخواست پشت‌سرهم به میزبان‌های بیرونی می‌بینی.
چهار: خواندن و نوشتنِ متناوبِ چیدمان. هندلری که در حلقه، پیش از نوشتنِ سبک، اندازه‌های هندسی می‌خواند. هر خواندنِ بعد از یک نوشتن، مرورگر را مجبور می‌کند چیدمان را دوباره حساب کند. نشانه: در خطِ زمان، بلوک‌های کوچکِ چیدمانِ اجباری پشت‌سرهم؛ به‌خصوص در اسکرول یا در منویی که زیرمجموعه‌ها را با ارتفاع محاسبه‌شده باز می‌کند.
پنج: درختِ DOM بزرگ. هزاران گره در یک صفحهٔ سازندهٔ صفحه، یعنی هر به‌روزرسانیِ نمایش هزینهٔ بیشتر، حتی اگر کد تو کوتاه باشد. این مستقیم روی تأخیر نمایش می‌نشیند. نشانه: هندلر در خطِ زمان کوتاه است ولی نقاشیِ بعدی دیر می‌آید.
شش: کارِ شبکه در هندلر، پیش از پاسخِ دیدنی. هندلری که درخواست می‌فرستد، منتظر پاسخ می‌ماند، بعد ظاهر را عوض می‌کند. اگر رابط کاربری تا رسیدنِ پاسخ هیچ علامتی ندهد، زمانِ پاسخِ سرور هم در عدد می‌آید. نشانه: کلیک تا ناپدید شدنِ حالت «در حال» در دکمه، فاصله دارد.
هفت: هندلرِ هر کلیکِ کلید. جستجوی زنده، فیلترِ محصول، اعتبارسنجیِ لحظه‌ای فیلدها. هر کلید یک رویداد است و اگر کاری که انجام می‌دهی سنگین باشد، کاربر دقیقاً همان‌جا لکنت را حس می‌کند. نشانه: تایپِ روان با انگشتِ دیگران، ولی روی صفحهٔ خودت، حروف با تأخیر می‌آیند.
هشت: اسکریپت‌های بی‌ربط در آن صفحه. بارگذاریِ اسکریپتِ فرم در صفحه‌ای که فرم ندارد، یا اسکریپتِ گالری در نوشته‌ای بدون گالری. هر فایلِ اضافه، هم کارِ اولیه دارد هم شانسِ گرفتن روی رویداد.
شش: تنظیم «تأخیر در اجرای اسکریپت» که دقیقاً همان کلیک را می‌شکند
این بخش، مهم‌ترین پاراگرافِ این مقاله برای یک سایت وردپرسیِ بهینه‌شده است.
بسیاری از افزونه‌های کشِ روی لایت‌اسپید، گزینه‌ای دارند که اجرای همهٔ اسکریپت‌ها را تا نخستین تعاملِ کاربر نگه می‌دارد. منطقش برای متریک‌های بارگذاری درست بود: در پنجرهٔ بارگذاری کاری اجرا نمی‌شود، پس عددِ اولیه بهتر می‌شود. اما حالا ببین چه اتفاقی برای کاربر می‌افتد: کاربر دکمه را می‌زند، و همان کلیک، ماشهٔ بارگذاری و تجزیه و اجرا و ثبتِ هندلرها می‌شود. یعنی هندلرِ همان چیزی که کاربر زده، در لحظهٔ نیاز هنوز وجود نداشته است. کاربر یک بار می‌زند، هیچ اتفاقی نمی‌افتد؛ یک بار دیگر می‌زند، حالا کار می‌کند. و متریکِ تازه، دقیقاً همین تعامل را به‌عنوان بدترینِ بازدید ثبت می‌کند.
این تنظیم، نمرهٔ آزمایشگاهی را بالا می‌برد و عددِ میدان را خراب می‌کند؛ یعنی بدترین ترکیبِ ممکن. نشانهٔ فعال بودنش در سورسِ صفحه قابل دیدن است: اگر تگ‌های script آدرسِ واقعی‌شان را ندارند و نشانی در یک صفتِ سفارشی نگهداری شده، تأخیر روشن است. روشِ تشخیص و اصلاح:
1) در افزونهٔ کش، بخش تنظیمات JavaScript را باز کن و گزینهٔ Delay JS را پیدا کن.
2) یک بار آن را خاموش کن، کش را پاک کن، و با حالت ناشناس یک صفحه را باز کن.
3) در سورس صفحه جستجو کن: اگر src واقعی برگشت، یعنی تأخیر عامل بود.
4) حالا دوباره روشنش کن و فقط چند هندل یا نام فایل را در فیلد استثنا بگذار:
منوی موبایل، جستجو، اسلایدر، اسکریپت سبد خرید و فرم تسویه، اعتبارسنجی فرم.
5) بعد از هر تغییر، کش را پاک کن و همان تعامل را دوباره تست کن.نامِ دقیقِ فیلدها در نسخه‌های مختلف فرق می‌کند؛ دنبال گزینه‌ای با کلیدواژهٔ «تأخیر» و «استثنا» بگرد. ترتیبِ چیدنِ استثنا هم مهم است: اول آنچه کاربر در سه ثانیهٔ اول می‌زند، بعد بقیه. اگر فهرست استثنا بلند شد، یعنی تأخیر برای آن صفحه جواب ندارد و باید سراغِ حذفِ خودِ اسکریپت بروی، نه عقب انداختنش. یک هشدار: این گزینه روی مسیرهایِ ورودِ کاربر، سبد خرید و فرمِ پرداخت، خطرناک‌ترین انتخاب است؛ چون همان‌جا کلیک، یعنی پول.
هفت: چطور مقصر را در خطِ زمان پیدا کنی
ابزارِ اصلی، پنلِ Performance در ابزار توسعه‌دهنده است. روشی که کار می‌کند، «بارگذاری صفحه» نیست؛ «انجامِ تعامل‌های واقعی» است.
1. Chrome را روی حالتِ دسکتاپ باز کن، ابزار توسعه‌دهنده را با F12 باز کن، تب Performance.
2. روی آیکون چرخ‌دنده، "Screenshots" را روشن بگذار (برای دیدنِ لحظهٔ نقاشی).
3. دکمهٔ ضبط را بزن؛ در همان صفحه این کارها را به ترتیب انجام بده:
- یک بار روی لینکِ منوی موبایل کلیک کن
- یک بار در فیلد جستجو سه حرف تایپ کن
- دکمهٔ افزودن به سبد را بزن
- یک صفحه اسکرول کن
4. ضبط را متوقف کن. Reload نزن؛ همان را تحلیل کن.
5. در نوارِ بالایی، بخشِ "Timings" یا "Interactions" را نگاه کن:
برای هر تعامل یک بازهٔ رنگی می‌بینی. چیزی که از آستانه رد شده، علامتِ بلند دارد.
6. روی بازهٔ مورد نظر کلیک کن. در پنل پایین، تفکیکِ سه فاز را می‌خواهی:
input delay / processing duration / presentation delay
7. با کلیدهای W و S بزرگ‌نمایی و کوچک‌نمایی؛ با ماوس بازهٔ کند را انتخاب (drag) کن
تا فهرست "Bottom-up" فقط برای همان بازه پر شود.
8. در Bottom-up، ستون "Self Time" را نزولی مرتب کن: اولین ردیف، مقصر است،
و با دابل‌کلیک روی ردیف، فایل و خط در تب Sources باز می‌شود.تفسیر سه‌فازه، تصمیم را می‌سازد. اگر بیشترِ عدد «تأخیر ورود» است، مشکل پیش از هندلر توست: تسکِ بلندِ دیگری نخ را گرفته؛ درمان، کم‌کردن کارِ اولیه و شکستن کارهای بلند است. اگر بیشترِ عدد «پردازش» است، خودِ هندلر سنگین است؛ در همان خطِ زمان ببین کدام تابع بیشترین «زمان شخصی» را خورده. اگر بیشترِ عدد «تأخیر نمایش» است، کد تو تمام شده ولی صفحه دیر نقاشی می‌کند؛ درمان، کوچک‌کردنِ DOM و کم‌کردن دامنهٔ تغییرات است.
و یک احتیاط: خطِ زمان روی میزبانِ خودت، سخت‌افزارِ تو را نشان میدهد. برای موبایلِ واقعی، با کابل، گزینهٔ “chrome://inspect” را باز کن و صفحهٔ باز شده روی گوشی را از همان‌جا ردگیری کن؛ این تنها راهی است که مشکلِ کاربرِ ایرانی را روی دستگاهِ خودش می‌بینی. اگر دسترسی به گوشی نداری، در همان پنل، محدودسازی CPU را روی بالاترین درجه بگذار و عدد را دوباره بگیر؛ اختلافِ زیاد یعنی مشکل روی دستگاه‌های ضعیف‌تر خیلی بزرگ‌تر است.
هشت: هندلرها را روی خودِ عنصر ببین
وقتی فهمیدی کدام رویداد کند است، سؤالِ بعدی این است: چه کسی به آن گوش میدهد؟ این را نمی‌شود حدس زد، چون افزونه‌ها هندلر ثبت می‌کنند و هیچ‌جا در فهرستِ افزونه‌ها اسمشان نیست.
در ابزار توسعه‌دهنده، عنصرِ واقعی را با ابزارِ انتخاب انتخاب کن، و در همان تبِ Elements، پنلِ Event Listeners را باز کن. نوعِ رویداد را باز کن و فهرستِ هندلرها را ببین: نامِ تابع و فایل و شمارهٔ خط. با کلیک روی لینکِ فایل، مستقیم به جای ثبت‌شدن می‌روی. یک تلهٔ مهم: هندلرهای jQuery که به‌صورت واگذارشده روی رِیشه ثبت شده‌اند، روی خودِ عنصر دیده نمی‌شوند؛ از منوی همان پنل، نمایشِ هندلرهای فریمورک را روشن کن تا دیده شوند.
// Console > با کمک‌های خودِ ابزار توسعه‌دهنده، نه با کدِ صفحه:
getEventListeners(document.querySelector('.primary-nav a'))
monitorEvents(document.querySelector('.add_to_cart_button'), ['pointerdown','click','keydown'])
// شمار هندلرهای ثبت‌شده روی سند، برای دیدنِ وسعتِ مشکل:
Object.keys(getEventListeners(document)).map(k => k + ':' + getEventListeners(document)[k].length)monitorEvents را روی همان دکمهٔ سبد خرید روشن بگذار و یک بار کلیک کن: اگر در کنسول، پیش از هندلرِ خودت، چند رویداد از فایل‌های بی‌ربط رد می‌شوند، آن‌ها هم‌شرکتِ عددِ تو هستند. همین‌طور فهرست هندلرهای سند را نگاه کن؛ در یک سایتِ وردپرسیِ معمولی، ده‌ها هندلر روی یک یا دو عنصرِ مشترک جمع می‌شود و هر کدام هزینهٔ پردازش اضافه می‌کند. اگر هندلری را نشناختی، فایلش را در فهرستِ افزونه‌ها و قالبِ فرزند جستجو کن؛ اغلب با یک wp_dequeue_script با همان هندل، مسئله تمام می‌شود.
نه: ترتیبِ رفع، به ترتیبِ بازده
با همین ترتیب جلو برو؛ چون هر قدمِ بعدی روی صفحه‌ای معنا دارد که اولی انجام شده باشد.
یکم: همان تأخیرِ اسکریپت را درست کن. اگر روشن است و استثنا ندارد، بزرگ‌ترین جهشِ همین‌جاست. یا خاموشش کن، یا فقط اسکریپت‌هایِ غیرضروری را تأخیر بده و آنچه کاربر می‌زند از آن مستثنا باشد.
دوم: اسکریپت‌های بی‌ربط را از آن صفحه بردار. این تنها روشی است که کار را حذف می‌کند، نه جابه‌جا. ببین در آن صفحه چه هندل‌هایی بارگذاری شده و کدام‌ها بی‌مصرف‌اند؛ در افزونه‌های سازندهٔ صفحه، گزینه‌های «بارگذاری در همهٔ صفحات» را ببند.
// در functions.php قالبِ فرزند: حذفِ هندل‌هایی که در این نوعِ نوشته لازم نیستند
add_action( 'wp_enqueue_scripts', function () {
if ( is_cart() || is_checkout() || is_account_page() ) {
return; // در مسیرهایِ پول‌ساز دست نزن
}
wp_dequeue_script( 'wc-add-to-cart-variation' );
wp_dequeue_script( 'wc-cart-fragments' );
}, 99 );سوم: شخصِ ثالث را از رویِ رویداد بردار. تگِ تحلیلی که با هر کلیک اجرا می‌شود، بنرِ رضایت که هندلرِ سند دارد، ویجتِ چت که با هر جابه‌جایی صفحه کار می‌کند. این‌ها را یا حذف کن یا بعد از نقاشی و بیرون از مسیرِ رویدادِ کاربر بارگذاری کن. هیچ‌کدام از این‌ها برای کاربرِ تو ارزشِ دیدنی ندارند، ولی در عددِ تو هستند.
چهارم: کارِ بلند را بشکن. حلقهٔ بزرگ را به تکه‌های کوچک تقسیم کن و میان هر تکه، کنترل را به مرورگر برگردان تا یک ورودیِ در صف، منتظرِ کل حلقه نماند. برای رابطِ کاربریِ پیچیده، گزینه‌هایِ تازه‌ترِ زمان‌بندی در مرورگر همین کار را ممکن کرده‌اند؛ برای کدِ قدیمی‌تر، یک مرزِ زمان‌بندی ساده هم کافی است.
پنجم: اول ظاهر، بعد شبکه. در هندلر، وضعیتِ دیدنی را بی درنگ عوض کن (حالتِ «در حال افزودن»، غیرفعال شدنِ دکمه، پیش‌نمایشِ تغییر)، سپس درخواست را بفرست. این کارِ کوچک، حسِ کندی را بی‌آنکه کاری حذف کند، از بین می‌برد؛ و اگر پاسخ ناموفق بود، ظاهر را برگردان.
ششم: خواندنِ چیدمان را دسته کن. اگر هندلری اندازه می‌گیرد و بعد سبک می‌نویسد، همهٔ خواندن‌ها را یک‌جا و همهٔ نوشتن‌ها را بعدش انجام بده. برای جابه‌جایی و بزرگ‌نمایی، از تغییرِ موقعیت با ترفندهایِ ترکیبی استفاده کن که چیدمان را دوباره حساب نمی‌کنند.
هفتم: درخت DOM را کوچک کن. کپیِ گره‌هایِ پنهان را حذف کن، نه اینکه فقط نمایششان را خاموش کن؛ و اگر فهرستی رندر می‌شود، فقط بخشِ دیدنی را بساز. توجه: گره‌هایی که نمایششان خاموش است، در به‌روزرسانیِ نمایش حساب نمی‌شوند، پس تغییرِ متنی که کاربر نمی‌بیند، هزینهٔ نقاشی ندارد و اولویتِ رفعِ تو نیست.
هشتم: ورودیِ هر کلید را محدود کن. جستجوی زنده را با تأخیرِ کوتاه و با لغوِ درخواستِ قبلی پیاده کن. اگر نتایج از سرور می‌آیند، با هر کلید یک درخواستِ تازه نفرست.
ده: پیشخوان و صفحهٔ تسویه؛ جایی که کاربرِ اصلی تو معذب است
دو مسیر را در این بحث جدا ببین، چون دادهٔ میدان ندارند و باید دستی بررسی شوند.
پیشخوان. برای سایتی که روزانه با آن کار می‌کنی، کندیِ پیشخوان هزینهٔ واقعی دارد: ویرایشگر، افزودنِ محصول، مدیریتِ سفارش. اما در گزارشِ سنجشِ میدان نمی‌آید، چون بازدیدهایِ پشتِ ورود، علنی و کافی نیستند. پس تنها چیزی که داری، ردگیریِ دستیِ خودت است. روش: یک برگهٔ ویرایشِ نوشته باز کن، ضبط را روشن کن، و همان کارهایی که هر روز می‌کنی را بکن: کلیک روی بلوک، تایپ در عنوان، تغییرِ دسته، انتشار. بعد در همان ردگیری ببین کدامِ افزونه، هندلرِ سنگین دارد. مقصرهایِ معمول: افزونه‌هایِ سئو که با هر تغییرِ محتوا درخواست می‌فرستند، افزونه‌هایِ بلوکِ آماده که بلوک‌هایِ بی‌استفاده بار می‌کنند، و ویجت‌هایی که هر چند ثانیه یک بار کشیدنِ اطلاعات انجام می‌دهند. رفعِ این‌ها اغلب با غیرفعال‌کردنِ گزینه‌هایِ «بررسی زنده» و حذفِ افزونه‌هایِ غیرلازم برای نقش‌هایِ دیگر انجام می‌شود.
تسویه و سبد خرید. در WooCommerce، افزودنِ به سبد یک دورهِ کامل به سرور دارد و پس از آن، بخش‌هایی از صفحه که به وضعیتِ سبد وابسته‌اند تازه می‌شوند. اگر ظاهرِ دکمه تا رسیدنِ پاسخ هیچ تغییری نکند، زمانِ سرور هم داخلِ عددِ تعامل می‌نشیند. تشخیصش بیرون از خطِ زمان و در تبِ شبکه است: ببین در همان لحظه چند درخواست می‌روی و کدامِ آن‌ها لازم نبود. نکتهٔ مهم: کشِ صفحه، این مسیر را درست نمی‌کند. کش، زمانِ پاسخِ سرور در بارگذاری را بهتر می‌کند و روی متریکِ بارگذاری اثر دارد؛ متریکِ تعامل در مرورگر ساخته می‌شود و با هاستِ قوی‌تر یا کشِ بهتر، خودش درست نمی‌شود. اگر یکی از این دو مسیر برایت مهم است، لایه‌هایِ بارگذاری را در مقالهٔ مربوط به کندیِ وردپرس بخوان و بعد برگرد اینجا.
یازده: رفع را با دادهٔ واقعی تأیید کن، نه با نمرهٔ آزمایشگاهی
سه سطحِ تأیید داری و باید به ترتیبِ اعتبارشان جلو بروی.
سطح یک: ردگیریِ دستی، پیش و پس از تغییر. همان سناریویِ کلیک‌ها را قبل و بعد ضبط کن و سه عددِ فاز را یادداشت کن. این تنها سطحی است که می‌فهمد کدام تغییر، کدام فاز را کم کرده. یک تغییر، یک اندازه‌گیری؛ اگر سه کار را با هم بکنی، نمی‌دانی کدام مؤثر بوده و کدام مضر.
سطح دو: سنجشِ خودت روی بازدیدهایِ واقعی. کتابخانهٔ رسمیِ سنجشِ این متریک، مقدارِ بدترینِ تعامل را با نامِ عنصر و نوعِ رویداد میدهد. این کد را روی همهٔ صفحات بگذار تا بفهمی در دنیای واقعی، کدام کلیک بدترین است:
import { onINP } from 'https://unpkg.com/web-vitals/dist/web-vitals.attribution.js';
onINP((m) => {
if (m.value < 200) return; // فقط تعامل‌های بالاتر از آستانه
const a = m.attribution;
navigator.sendBeacon('/inp-log', JSON.stringify({
value: m.value, // بدترین تعاملِ این بازدید
target: a.interactionTarget, // عنصری که کاربر زده است
type: a.interactionType,
inputDelay: a.inputDelay, // فاز یک: تأخیر ورود
processing: a.processingDuration, // فاز دو: مدت پردازش
presentation: a.presentationDelay, // فاز سه: تأخیر نمایش
script: a.longestScript, // بلندترین اسکریپتِ مسئول در این تعامل
loadState: a.loadState, // آیا مشکل در پنجره بارگذاری بوده
path: location.pathname
}));
}, { reportAllChanges: true });بعد از چند روز، این ثبت‌ها را بر اساسِ نشانی و بر اساسِ سلکتور دسته کن: فهرستی میدهد که «کدام کلیک، روی کدام صفحه، بیشتر از آستانه است». این فهرست، نقشهٔ راهِ رفعِ توست و هیچ نمره‌ای جای آن را نمی‌گیرد. برای مسیرهایِ پشتِ ورود که در این داده نیستند، همان ردگیریِ دستی را برای نقشِ مدیرانه امتحان کن.
سطح سه: گزارشِ سرچ‌کنسول. تغییر را فوراً در آن نمی‌بینی: پنجرهٔ داده متحرک است، پس بازدیدهایِ تازه باید جای بازدیدهایِ کهنه را پر کنند و این زمان می‌برد. گزارش را هفتگی نگاه کن، نه روزانه، و به نمودارِ تاریخ‌دارِ همان گروهِ نشانی نگاه کن، نه به وضعیتِ لحظه‌ای. تفکیکِ موبایل و میزبان را جدی بگیر؛ اگر فقط میزبان سبز است، وضعیتت سبز نیست. و اگر صفحه‌ای «دادهٔ کافی» ندارد، با تغییرِ تو عددش عوض نمی‌شود؛ در آن حالت قضاوت را از سطحِ نامِ میزبان یا از همان ثبتِ خودت انجام بده.
یک تفسیرِ صادقانه: ممکن است رفعِ تو ردگیریِ دستی را درست کند و صدکِ هفتم را نه، چون آن تعامل در بازدیدها کم‌تکرار بوده؛ یا برعکس، عددِ میدان بهتر شود و تو در تستِ دستی چیزی نبینی، چون کاربرِ واقعی دستگاهِ ضعیف‌تر و شبکهٔ شلوغ‌تر دارد. دادهٔ میدان را معیارِ نهایی قرار بده و ردگیریِ دستی را معیارِ تشخیص.
دوازده: کجا بهینه نکنیم
سه حالت که هزینه‌کردن در آن اشتباه است:
صفحه‌ای که هیچ تعاملِ دیدنی ندارد. نوشته‌ای فقط متن و تصویر، بدترینِ تعاملِ معنادار ندارد و عددش ذاتاً خوب است. وقتِ تو جایی است که کاربر کاری انجام میدهد: فرم، فیلتر، منو، سبد.
بالایِ آستانه، وقتی کاربر راضی است. اگر دادهٔ میدان سبز است و بازخوردِ کاربری نمی‌شنوی، کارِ بعدی‌ات این نیست. کاهشی که کاربر احساسش نکند، فقط عدد را قشنگ می‌کند و ریسکِ شکستنِ کارکردِ صفحه را دارد. متریک، ابزارِ قضاوت است؛ اگر برای سبز کردنِ آن، کاری را از صفحه حذف کردی که کاربر لازم دارد، تو عدد را اصلاح کرده‌ای نه تجربه را.
سرریز کردنِ همهٔ جا. اگر در هر صفحه‌ای اسکریپت را تأخیر بدهی یا حذف کنی، دیر یا زود یکی از فرم‌ها می‌شکند. قاعدهٔ عملی: هر تغییرِ اسکریپت را فقط روی نوعِ صفحه‌ای اعمال کن که مشکل دارد، و بعد از هر تغییر، همان تعاملِ واقعی را خودت یک بار انجام بده. روی هاستِ اشتراکی، کشِ افزونه را بعد از هر تغییر پاک کن، وگرنه در تستِ بعدی همان کدِ قبلی را می‌بینی و نتیجه‌اش را غلط ثبت می‌کنی.
سیزده: خطاهایِ تفسیری که باعث می‌شوند رفعِ اشتباه بکنی
پنج خوانشِ غلط که در بررسیِ سایت‌ها بارها دیده‌ام:
یک: مقایسهٔ عددِ امروز با عددِ دورهٔ قبل. متریک عوض شده؛ اعدادِ دو دوره، یک کمیت نیستند. اگر در گزارشِ تاریخ‌دار، افتِ ناگهانی در همان تاریخِ تغییر می‌بینی، آن افت، تغییرِ تعریف است نه خرابیِ سایت.
دو: تستِ فقط یک بار، با کشِ گرم. اجرای دوم روی میزبانِ خودت، همهٔ فایل‌ها را از حافظهٔ مرورگر می‌خواند و کاری را که کاربرِ نخستینِ واقعی تجربه می‌کند، نمی‌سنجد. پنج بار و با حالتِ ناشناس اندازه بگیر.
سه: کلیک‌نکردن در تست. یک ردگیری بگیر و صفحه را نگاه کن، بدون اینکه چیزی بزنی؛ این فقط متریک‌هایِ بارگذاری را می‌سنجد. بدترینِ تعامل، حتماً با یک تعامل ساخته می‌شود.
چهار: درمانِ مشکلِ «پردازش» با کم‌کردنِ «تأخیر ورود». این دو فاز دو درمانِ جدا دارند. تفکیکِ فاز را نخوانده و تنظیم عوض نکن.
پنج: فرضِ اینکه هاستِ قوی‌تر مشکل را حل می‌کند. نخ اصلی در دستگاهِ کاربر قفل می‌شود، نه روی سرورِ تو. ارتقا، زمانِ پاسخِ سرور را بهتر می‌کند؛ این یکی را نه.
چهارده: چک‌لیستِ فشرده
اگر وقتِ تو محدود است، به همین ترتیب انجام بده و هربار فقط یک عدد یادداشت کن:
۱. گزارشِ سنجشِ میدان را باز کن و صدکِ هفتمِ موبایل را برای سه نشانیِ پربازدید بنویس. ۲. در همان ابزار، ببین مشکل در کدام فاز است: ورود، پردازش، یا نمایش. ۳. تنظیمِ تأخیرِ اسکریپت را بررسی کن و مسیرهایِ کلیک‌شونده را مستثنا کن. ۴. در یک برگه، هندل‌هایِ بارگذاری‌شده را فهرست کن و بی‌مصرف‌ها را همان صفحه حذف کن. ۵. با پنلِ Performance، روی موبایلِ واقعی، سه تعاملِ مهم را ضبط کن و مقصر را به نامِ فایل برسان. ۶. در پنلِ Event Listeners ببین چه کسی به آن عنصر گوش میدهد. ۷. هندلر را طوری بازنویسی کن که اول ظاهر را عوض کند، بعد شبکه. ۸. فقط یک تغییر بده، دوباره ردگیری کن، عدد را با تاریخ ثبت کن. ۹. بعد از دو تا چهار هفته، صدکِ هفتمِ میدان را دوباره بخوان. ۱۰. اگر عدد بهتر شد ولی کاربر هنوز می‌گوید کند است، سراغِ فازِ نمایش برو و DOM آن صفحه را کوچک کن.
و یادآوریِ پایانی: این متریک، بدترینِ پاسخ را می‌سنجد. پس کارِ تو «کم‌کردنِ میانگین» نیست؛ کارِ تو پیدا کردنِ همان یک کلیکِ رایجِ کند است. اول اسمش را بگذار، بعد حذفش کن، و آخر با دادهٔ واقعیِ کاربران خودت تأیید کن. اعضایِ این خوشه بقیهٔ لایه‌ها را باز می‌کنند: تفاوتِ وب‌سرورها در لایهٔ سرور، تله‌ای که دیپلوی را بی‌اثر نشان میدهد، و روشِ اندازه‌گیریِ لایه‌به‌لایهٔ کندی.
مقالبی بخوانی
- چرا سایت وردپرسی کند است؛ اندازه‌گیری به‌جای حدس
- google-core-web-vitals
- اعتبار موضوعی و لینک‌دهی خوشه‌ای؛ ساختار ستون و خوشه در عمل
- تفاوت LiteSpeed با Nginx و Apache برای وردپرس؛ کدام وب‌سرور واقعیت را سریع می‌کند؟
امید بداق
من متخصص سئو که عاشق اینه به کسب‌وکارها کمک کنه تو گوگل دیده بشن!از وردپرس گرفته تا سئو، هرچیزی که برای رشد آنلاین نیاز داری میتونم کمکت کنم.