Lighthouse 13 شکل بخشی از گزارش‌های عملکرد را عوض کرد؛ الگوریتم امتیاز Performance در این انتشار تغییر نکرد. این تفاوت در اعلام رسمی نسخه 13 صریح آمده است. مقاله قبلی از معیار تازه Smoothness، امتیازدهی جدید CSS و جایگزینی FID در همین نسخه حرف می‌زد. چنین توصیفی با اعلام انتشار همخوان نبود. تغییر مهم این نسخه، کنار رفتن تعدادی audit قدیمی و استفاده از Performance Insights مشترک با DevTools است.
INP هم در مارس ۲۰۲۴ جای FID را در Core Web Vitals گرفت؛ این اتفاق به انتشار Lighthouse 13 در اکتبر ۲۰۲۵ وابسته نبود. اعلام رسمی ورود INP تاریخ آن را مشخص می‌کند. برای خواندن یک گزارش باید ابتدا معلوم کنید کدام بخش داده آزمایشگاهی است، کدام بخش از کاربران واقعی آمده و کدام عدد صرفاً امتیاز ترکیبی ابزار است. بدون این تفکیک، اصلاح سایت ممکن است روی عددی متمرکز شود که مشکل کاربر را نشان نمی‌دهد.
گزارش آزمایشگاهی و داده واقعی دو سؤال دارند
Lighthouse در یک اجرای کنترل‌شده، وضعیت صفحه را با شرایط مشخص بررسی می‌کند. نتیجه برای پیدا کردن سرنخ فنی مفید است: کدام منبع دیر رسید، کدام کار thread اصلی را گرفت و چه چیزی نمایش را عقب انداخت. داده کاربران واقعی از تجربه‌های متعدد در دستگاه‌ها و شبکه‌های مختلف می‌آید. یک اجرا روی دستگاه توسعه‌دهنده نمی‌تواند تمام این تجربه‌ها را نمایندگی کند.
در PageSpeed Insights ممکن است داده Field و نتیجه Lab را کنار هم ببینید. این دو از زمان و شرایط یکسانی جمع نشده‌اند. اگر امروز فایل JavaScript را کوچک کرده‌اید، گزارش آزمایشگاهی می‌تواند تغییر را زود نشان دهد، ولی پنجره داده واقعی همچنان تجربه‌های قبلی را هم در بر دارد. اختلاف این دو لزوماً خطای ابزار نیست؛ ابتدا زمان، دامنه و نوع داده را بررسی کنید.
سطح داده نیز اهمیت دارد. نتیجه یک URL با نتیجه کل Origin فرق دارد. وقتی اطلاعات کافی برای یک مسیر وجود ندارد، خواندن عدد Origin به عنوان عملکرد همان مقاله یا صفحه پرداخت گمراه‌کننده است. در گزارش داخلی بنویسید داده به کدام دامنه تعلق دارد. مدیر محصول باید بداند عدد نمایش‌داده‌شده به صفحه‌ای که درباره آن تصمیم می‌گیرد مربوط است یا فقط نمای کلی سایت را نشان می‌دهد.
LCP، CLS و INP را به رفتار صفحه وصل کنید
LCP زمان نمایش بزرگ‌ترین عنصر محتوایی واجد شرایط در محدوده دید را نشان می‌دهد. ممکن است این عنصر تصویر اصلی یا یک بلوک متن باشد. راهنمای LCP توضیح می‌دهد کدام عنصرها در محاسبه دخیل‌اند. کاهش حجم فایل به تنهایی همیشه کافی نیست؛ دیر کشف شدن منبع یا انتظار برای پاسخ سند اولیه هم می‌تواند زمان نمایش را عقب ببرد.
برای یک مقاله، ابتدا ببینید خواننده چه چیزی را باید زود بخواند. اگر متن عنوان منتظر فونت یا زنجیره طولانی منابع است، مسئله فقط اندازه عکس نیست. اگر تصویر اصلی در HTML اولیه قابل کشف نیست و بعد از اجرای کد معرفی می‌شود، مسیر دانلود دیر شروع می‌شود. تحلیل باید از عنصر واقعی گزارش آغاز شود، نه نسخه عمومی «همه تصاویر را lazy load کنید»؛ تصویر اصلی صفحه شرایط متفاوتی دارد.
CLS جابه‌جایی غیرمنتظره چیدمان را دنبال می‌کند. مستندات CLS سازوکار محاسبه را شرح می‌دهد. مثال ساده، تبلیغ یا تصویری است که پس از نمایش متن وارد می‌شود و محل خواندن را پایین می‌برد. اگر جای لازم از قبل رزرو نشده باشد، کاربر ممکن است روی عنصر دیگری کلیک کند. تعیین ابعاد و برنامه‌ریزی محل محتوای دیررس به این مسئله مربوط است.
INP به پاسخ بصری صفحه در تعامل‌ها مربوط است. کاربر روی دکمه می‌زند و باید بازخورد مناسب ببیند. مرجع INP توضیح می‌دهد که این معیار تعامل‌های واجد شرایط را در طول حضور کاربر بررسی می‌کند. INP مدت تکمیل تمام درخواست‌های شبکه یک عملیات نیست؛ نمایش بازخورد اولیه و پایان کسب‌وکاری عملیات ممکن است دو لحظه جدا باشند.
برای مثال، هنگام ارسال فرم، دکمه می‌تواند وضعیت در حال ارسال را نشان دهد و نتیجه نهایی بعد از پاسخ سرور برسد. اگر thread اصلی پیش از همین بازخورد درگیر محاسبه سنگین باشد، صفحه بی‌واکنش به نظر می‌رسد. اگر بازخورد فوری است ولی API کند است، کاربر هنوز منتظر می‌ماند، اما علت فنی دیگری دارد. حل هر دو مهم است؛ یک معیار را جای توضیح کامل مسیر کاربر نگذارید.
TBT را با INP یکی نگیرید
Total Blocking Time یا TBT در گزارش Lab به زمان‌های مسدودکننده thread اصلی در بازه مربوط به بارگذاری اشاره دارد. این عدد برای پیدا کردن کارهای سنگین مفید است، اما مقدار INP کاربران واقعی نیست. راهنمای TBT روش محاسبه را توضیح می‌دهد. پایین بودن TBT، تعامل کندی را که فقط بعد از باز کردن یک پنل خاص رخ می‌دهد رد نمی‌کند.
کاهش کد شروع صفحه می‌تواند TBT را بهتر کند، ولی اگر همان کار سنگین را بی‌برنامه به نخستین کلیک منتقل کنید، تجربه تعامل ممکن است بدتر شود. مسئله را به زمان اجرای کار وصل کنید. چه چیزی برای نمایش اولیه لازم است؟ چه چیزی فقط پس از انتخاب کاربر لازم می‌شود؟ کدام محاسبه را می‌توان خرد کرد یا از thread اصلی بیرون برد؟ پاسخ‌ها باید از رفتار واقعی قابلیت بیایند.
Performance Insights و تغییر ساختار JSON
Lighthouse 13 برخی auditهای قدیمی را از گزارش و JSON حذف کرد و insightهای جدید را جای آن‌ها نشاند. اگر اسکریپت گزارش‌گیری شما به ID قدیمی وابسته است، ممکن است بعد از ارتقا داده مورد انتظار را پیدا نکند. این شکست را با بهبود خودکار سایت اشتباه نگیرید. نسخه ابزار و schema مصرف‌شده در داشبورد را همراه گزارش ثبت کنید.
برای نگهداری گزارش، داده خام را از متن قابل نمایش جدا کنید. اگر سیستم شما یک ID را نمی‌شناسد، بهتر است آن را به‌عنوان قابلیت گزارش‌نشده علامت بزند و خطای قابل پیگیری ثبت کند. مقدار صفر ساختگی یا برچسب «قبول» به خاطر نبودن فیلد، نتیجه غلط می‌سازد. مسئول داشبورد باید بداند نبودن داده با داده مطلوب فرق دارد. این موضوع برای pipelineهایی که گزارش چند پروژه را جمع می‌کنند حساس‌تر می‌شود.
یک امتیاز را چگونه گزارش کنیم؟
امتیاز Performance از ترکیب وزن‌دار معیارهای گزارش ساخته می‌شود و رابطه آن با مقدار خام خطی نیست. راهنمای Performance scoring شیوه تبدیل را توضیح می‌دهد. اختلاف چند امتیاز به خودی خود نشان نمی‌دهد کدام رفتار صفحه بهتر شده است. کنار امتیاز، مقدار خام معیار مرتبط و شرایط اجرا را نگه دارید تا نتیجه قابل تفسیر بماند.
در یک گزارش فرضی تیمی، به جای «سایت سریع شد» بنویسید «منبع اصلی زودتر کشف می‌شود و انتظار نمایش محتوای نخست کاهش یافته است». اگر عدد واقعی در اختیار ندارید، عدد نسازید. اگر آزمایش محدود است، دامنه نتیجه را همان‌قدر محدود بیان کنید. نتیجه یک صفحه landing، وضعیت پنل مدیریت یا مسیر پرداخت را اثبات نمی‌کند. تصمیم بودجه عملکرد باید برای مسیرهای مهم محصول جداگانه گرفته شود.
تغییر نسخه Chrome، نوع دستگاه، شرایط شبکه و محتوای صفحه هم روی مقایسه اثر دارند. اجرای صبح با صفحه cache شده را کنار اجرای دیگری با افزونه‌های مرورگر و داده متفاوت قرار ندهید و نتیجه قطعی نگیرید. ثبت شرایط تکرارپذیر به تیم کمک می‌کند از نوسان طبیعی گزارش یک داستان ساختگی درباره پیشرفت یا افت نسازد.
از گزارش به فهرست کار برسید
هر insight باید به یک فرضیه و مالک کار برسد. برای مثال، در مسئله کشف دیرهنگام تصویر اصلی، بررسی کنید آیا منبع در HTML اولیه قابل دسترس است. در مسئله جابه‌جایی صفحه، عنصری را پیدا کنید که اندازه‌اش دیر معلوم می‌شود. فهرست بلند هشدارها بدون اولویت، کار را پراکنده می‌کند. مسئله‌ای که کاربر در مسیر مهم با آن روبه‌رو می‌شود معمولاً نقطه شروع بهتری است.
پس از اصلاح، تغییر را به همان مسئله اولیه وصل کنید. حذف یک کتابخانه ممکن است حجم فایل را کم کند ولی عملکردی را هم از صفحه بردارد؛ نتیجه باید هر دو را در نظر بگیرد. مقاله Performance Budget برای فرانت‌اند به تبدیل هدف سرعت به محدودیت‌های قابل نگهداری مربوط است. برای طراحی بازخورد هنگام انتظار نیز Loading States و Skeleton Screens ادامه مفیدی است.
گام بعدی، انتخاب یک مسیر مهم و نوشتن مشکل قابل مشاهده آن است. سپس گزارش مناسب همان مشکل را بخوانید و فقط تغییرهایی را در اولویت بگذارید که رابطه روشنی با آن دارند. Lighthouse فهرست سرنخ می‌دهد؛ تصمیم درباره تجربه خواندن، خرید یا ثبت فرم همچنان به شناخت محصول نیاز دارد. نسخه ابزار را ثبت کنید و هر نتیجه را با نوع داده و محدوده آن تحویل دهید.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!