امتیاز PageSpeed Insights پایین آمده، اما سایت را تغییر نداده‌اید. یا بعد از اصلاح تصویر اصلی، امتیاز آزمایش بهتر شده ولی بخش تجربه کاربران هنوز قرمز است. این دو موقعیت لزوماً تناقض نیستند. PageSpeed Insights چند نوع داده را کنار هم نشان می‌دهد و اگر آن‌ها را یک عدد واحد بدانیم، ممکن است مشکل اشتباهی را دنبال کنیم.
این راهنما در ۱۰ اکتبر ۲۰۲۶ بر اساس منابع رسمی گوگل بازبینی شده است. منظور از راهنمای ۲۰۲۶، بررسی وضعیت مستند ابزار در زمان بازبینی است؛ تغییرات سال‌های قبل را به‌عنوان خبر تازه این سال معرفی نمی‌کنیم. مهم‌ترین اصلاح نسبت به نسخه قبلی مقاله این است که INP وزن ۳۰ درصدی در امتیاز Performance ندارد و اعداد ادعایی LCP و CLS نیز درست نبودند.
کدام تغییرات واقعاً تأیید شده‌اند؟
طبق Release Notes رسمی PageSpeed Insights، به‌روزرسانی این ابزار و API به Lighthouse 13.0 در ۲۰ اکتبر ۲۰۲۵ ثبت شده است. در صفحه بررسی‌شده، اعلان جدیدی با تاریخ ۲۰۲۶ برای تغییر وزن معیارها پیدا نشد. نسخه API همچنان با عنوان v5 مستند شده و نسخه Lighthouse مستقل از آن تغییر می‌کند؛ v5 به معنی Lighthouse 5 نیست.
اعلان Lighthouse 13 توضیح می‌دهد که تعدادی از Auditهای قدیمی با Performance Insights جایگزین شده‌اند و موارد قدیمی از گزارش و JSON حذف شده‌اند. همین اعلان صریحاً می‌گوید این نسخه وزن‌دهی امتیاز Performance را تغییر نداده است. بنابراین عوض‌شدن عنوان یا جای یک پیشنهاد، به‌تنهایی به معنی عوض‌شدن فرمول امتیاز نیست.
این تغییر برای تیمی که گزارش را با اسکریپت می‌خواند مهم است. اگر ابزار داخلی به شناسه یک Audit قدیمی وابسته باشد، ممکن است بعد از ارتقا دیگر آن فیلد را نبیند. نسخه Lighthouse، تاریخ گزارش و شناسه‌های مورد استفاده را ثبت کنید و نبود یک فیلد را خودکار به معنی رفع مشکل نگیرید. برای گزارش جدید، نسخه واقعی همان اجرا را مرجع قرار دهید.
Field Data و Lab Data چه فرقی دارند؟
بخش Field Data از CrUX یا Chrome User Experience Report می‌آید و تجربه کاربران واجد شرایط را در یک بازه گذشته خلاصه می‌کند. بخش Lab Data با Lighthouse، بارگذاری صفحه را در محیط کنترل‌شده بررسی می‌کند. اولی برای فهم وضعیت تجربه واقعی مفید است و دومی برای تشخیص علت و بررسی اثر اصلاحات. هیچ‌کدام جای دیگری را کامل نمی‌گیرد.
بر اساس مستندات PSI، داده واقعی در گزارش بازه ۲۸ روز گذشته را پوشش می‌دهد. اگر داده کافی برای URL وجود نداشته باشد، ممکن است گزارش به سطح Origin برگردد؛ یعنی تجربه مجموعه صفحه‌های همان مبدأ را نشان دهد. اگر Origin هم داده کافی نداشته باشد، این بخش در دسترس نیست. نبود داده، نمره قبولی یا ردشدن محسوب نمی‌شود.
قبل از تفسیر، ببینید گزارش درباره همان URL است یا Origin و کدام دستگاه را نشان می‌دهد. نتیجه کلی مبدأ را به‌عنوان نتیجه دقیق یک صفحه محصول گزارش نکنید. برای یک سایت تازه یا صفحه کم‌مراجعه، گزارش آزمایشگاهی همچنان می‌تواند کمک کند، اما نمی‌توان از آن نتیجه گرفت همه کاربران همان تجربه را دارند.
Core Web Vitals را از امتیاز صدتایی جدا بخوانید
Core Web Vitals شامل LCP، INP و CLS است. LCP زمان دیده‌شدن بزرگ‌ترین تصویر یا بلوک متن واجد شرایط در محدوده دید را می‌سنجد. INP پاسخ‌گویی صفحه به تعامل‌های کاربر را بررسی می‌کند. CLS جابه‌جایی غیرمنتظره چیدمان را اندازه می‌گیرد. ورود INP به این مجموعه و جایگزینی FID، رویداد تازه مخصوص ۲۰۲۶ نیست.
مرز وضعیت خوب برای LCP حداکثر ۲٫۵ ثانیه، برای INP حداکثر ۲۰۰ میلی‌ثانیه و برای CLS حداکثر ۰٫۱ است. ارزیابی داده واقعی به صدک ۷۵ مربوط است، نه میانگین ساده تمام بازدیدها. CLS نیز زمان نیست؛ آن را با واحد ثانیه یا درصد گزارش نکنید. این تفاوت‌ها هنگام توضیح نتیجه به مشتری به اندازه خود عدد اهمیت دارند.
در حالت معمول و با داده کافی، خوب‌بودن هر سه معیار برای عبور از ارزیابی لازم است. مستندات PSI برای کمبود نمونه INP استثنای مشخصی توضیح می‌دهند: اگر LCP و CLS داده کافی و وضعیت خوب داشته باشند، ارزیابی می‌تواند عبور کند. پس نبود INP را با مقدار صفر برابر نگیرید و نتیجه را همراه با وضعیت داده بخوانید.
وزن‌دهی امتیاز Lighthouse چه می‌گوید؟
برای یک مرجع نسخه‌دار، در پیکربندی رسمی Lighthouse 13.0.0، وزن‌های Performance در حالت معمول Navigation این‌گونه‌اند:
| معیار | وزن در امتیاز |
|---|---|
| FCP | ۱۰٪ |
| Speed Index | ۱۰٪ |
| LCP | ۲۵٪ |
| TBT | ۳۰٪ |
| CLS | ۲۵٪ |
این جدول را به نسخه مشخص نسبت می‌دهیم، نه اینکه آن را قانون دائمی همه اجراها بدانیم. INP در این پیکربندی وزن صفر دارد. TBT یا Total Blocking Time در آزمایش بارگذاری، نشانه‌ای از زمان مسدودشدن Main Thread است؛ با INP واقعی که به تعامل‌های کاربر مربوط است، یکی نیست. کم‌بودن TBT هم تضمین نمی‌کند همه تعامل‌های بعدی سریع باشند.
راهنمای امتیازدهی Lighthouse توضیح می‌دهد که امتیاز از معیارها ساخته می‌شود، نه از تعداد پیشنهادهای قرمز و سبز. اصلاح یک Insight از راه بهترکردن معیار مرتبط اثر می‌گذارد. بنابراین حذف سه هشدار، الزاماً سه افزایش مستقل و قابل جمع در امتیاز ایجاد نمی‌کند.
گزارش را با این ترتیب بخوانید
ابتدا URL نهایی، دستگاه و تاریخ اجرا را مشخص کنید. سپس در داده واقعی، سطح URL یا Origin و وضعیت معیارها را ببینید. بعد سراغ آزمایش Lighthouse بروید و معیار ضعیف را پیدا کنید. در پایان، Insightهای مربوط به همان مشکل را بررسی کنید. این ترتیب کمک می‌کند قبل از دست‌کاری فایل‌ها، بدانید چه چیزی باید بهتر شود.
مثلاً در یک فروشگاه فرضی، اگر LCP ضعیف است اما پاسخ به تعامل مناسب است، کوچک‌کردن همه کدهای JavaScript بدون بررسی مسیر تصویر اصلی شاید اولویت درستی نباشد. اگر کاربر هنگام بازکردن فیلترها تأخیر حس می‌کند، تنها کاهش حجم تصویر مسئله را حل نمی‌کند. گزارش باید به فرضیه‌ای درباره علت برسد، نه صرفاً فهرستی از کارهای پراکنده.
امتیاز Mobile و Desktop را هم در شرایط خودشان بخوانید. تفاوت توان پردازش، شبکه و تنظیمات آزمایش روی نتیجه اثر دارد. سبزبودن Desktop دلیل کافی برای نادیده‌گرفتن Mobile نیست. راهنمای Mobile First کمک می‌کند اولویت‌های صفحه کوچک و دستگاه ضعیف‌تر از ابتدا وارد طراحی شوند.
برای LCP، مسیر کامل نمایش محتوا را بررسی کنید
در راهنمای بهینه‌سازی LCP، مسیر به دریافت پاسخ اولیه، تأخیر شروع بارگذاری منبع، زمان دریافت منبع و تأخیر نمایش تقسیم می‌شود. تصویر سبک‌تر مفید است، اما اگر تصویر پس از اجرای یک اسکریپت دیر کشف شود یا تا پایان یک کار طولانی پنهان بماند، کاهش حجم به‌تنهایی کافی نیست.
عنصر LCP را در همان صفحه پیدا کنید. اگر تصویر اصلی است، اندازه مناسب، فرمت و نحوه کشف آن را بررسی کنید؛ تصویر LCP را Lazy Load نکنید. Preload و Fetch Priority می‌توانند برای منبع مهم کمک کنند، اما به همه تصویرها اولویت بالا ندهید. رقابت منابع اضافی می‌تواند مسیر مهم را شلوغ‌تر کند.
اگر پاسخ اولیه سرور کند است، به Cache، Redirectها و پردازش پاسخ نگاه کنید. CDN و Edge Computing می‌توانند بخشی از راه‌حل باشند، ولی خرید CDN بدون تشخیص گلوگاه تضمین نتیجه نیست. در صفحه‌ای که محتوای اصلی متن است، فونت و منابع مسدودکننده نمایش هم ممکن است نقش داشته باشند.
برای INP، تعامل واقعی را دنبال کنید
راهنمای بهینه‌سازی INP تأخیر تعامل را به انتظار پیش از اجرای رویداد، پردازش و زمان رسیدن به نمایش بعدی تفکیک می‌کند. پیشنهاد کلی «همه اسکریپت‌ها را defer کنید» این مسئله را کامل پوشش نمی‌دهد. یک اسکریپت می‌تواند بعد از بارگذاری هم در پاسخ به کلیک، کار سنگینی انجام دهد.
بازکردن منو، تغییر فیلتر، افزودن به سبد و ارسال فرم را در سناریوی واقعی بررسی کنید. در یک مثال فرضی، فیلترکردن هزاران ردیف هم‌زمان با بازسازی کل جدول ممکن است پاسخ را عقب بیندازد. راه‌حل می‌تواند کاهش کار غیرضروری، شکستن کار طولانی یا تغییر روش نمایش داده باشد. انتخاب دقیق به Trace و ساختار برنامه وابسته است.
نمایش فوری بازخورد به کاربر هم مهم است، اما نباید جای تکمیل درست عملیات را بگیرد. اگر درخواست شبکه طول می‌کشد، وضعیت در حال انجام را روشن نشان دهید. یک Spinner به‌تنهایی ثابت نمی‌کند Main Thread آزاد است یا عملیات سریع شده. پس از طراحی تجربه، علت فنی تأخیر را جدا بررسی کنید.
برای CLS، فضای عناصر را پیش از رسیدن داده مشخص کنید
راهنمای بهینه‌سازی CLS به علت‌هایی مانند تصویر بدون اندازه، محتوای تزریق‌شده و تغییر فونت می‌پردازد. برای تصویر و ویدئو، ابعاد یا نسبت مناسب تعریف کنید. برای تبلیغ، Embed و بلوک داده‌ای که دیر می‌رسد، درباره فضای رزروشده تصمیم بگیرید. اضافه‌شدن ناگهانی یک نوار بالای متن می‌تواند محتوا را جابه‌جا کند.
تغییر فونت نیز ممکن است عرض واژه‌ها و ارتفاع سطر را عوض کند. خانواده جایگزین و رفتار بارگذاری را با متن واقعی ببینید؛ راهنمای تایپوگرافی فارسی این موضوع را توضیح می‌دهد. تمام مشکلات بعد از اسکرول یا تعامل در یک اجرای کوتاه بارگذاری دیده نمی‌شوند؛ به همین دلیل داده واقعی و بررسی سناریوها کنار هم ارزش دارند.
چطور نتیجه اصلاح را درست گزارش کنیم؟
قبل و بعد را با URL، دستگاه، نسخه و شرایط قابل مقایسه ثبت کنید. به‌جای انتخاب بهترین اجرای اتفاقی، چند اجرای هم‌شرایط را کنار هم ببینید و نوسان را در نظر بگیرید. اگر نسخه ابزار عوض شده، آن را در توضیح نتیجه بنویسید. تغییر امتیاز بدون تغییر سایت می‌تواند از شرایط اجرا یا ابزار بیاید.
برای داده واقعی انتظار به‌روزرسانی فوری نداشته باشید. پس از انتشار اصلاح، بازه ۲۸ روزه هنوز بخشی از تجربه نسخه قبلی را در خود دارد. نتیجه آزمایش می‌تواند سریع‌تر نشانه‌ای از اثر تغییر بدهد، اما ادعای «تجربه همه کاربران اصلاح شد» به شواهد واقعی نیاز دارد. همچنین صفحه‌های محصول، مقاله و فهرست را یک نمونه واحد فرض نکنید.
در گزارش تیمی، مشکل، علت احتمالی، اصلاح انجام‌شده و معیار مورد انتظار را بنویسید. برای نمونه: «تصویر اصلی دیر کشف می‌شد؛ منبع در HTML اولیه قابل کشف شد؛ اثر را در LCP بررسی می‌کنیم». این جمله از «سرعت سایت افزایش یافت» قابل ارزیابی‌تر است. عدد صد، رتبه جست‌وجو یا افزایش فروش را به‌عنوان نتیجه قطعی یک اصلاح وعده ندهید.
پرسش‌های رایج
امتیاز سبز یعنی Core Web Vitals قبول شده است؟
خیر؛ امتیاز آزمایش و ارزیابی داده واقعی از یک روش ساخته نمی‌شوند. سطح داده، دستگاه و وضعیت معیارها را جدا بخوانید. یک نتیجه سبز آزمایشگاهی می‌تواند کنار تجربه واقعی نیازمند بهبود قرار بگیرد.
نبود CrUX یعنی سایت مشکل دارد؟
نه؛ ممکن است نمونه کافی در دسترس نباشد. آزمایش تشخیصی و در صورت نیاز RUM یا Real User Monitoring می‌توانند به بررسی کمک کنند، اما نبود داده را به نتیجه عملکرد تبدیل نکنید.
در ۲۰۲۶ باید همه توصیه‌های قبلی را کنار گذاشت؟
خیر؛ نام و ساختار برخی Auditها تغییر کرده، اما اصل تشخیص گلوگاه، حفظ ثبات چیدمان و پاسخ‌گویی سریع همچنان کاربرد دارد. توصیه را با نسخه ابزار و مشکل واقعی صفحه بسنجید. PageSpeed Insights زمانی مفید است که گزارشش به یک اصلاح مشخص و قابل ارزیابی برسد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!