برای خواندن گزارش PageSpeed Insights، ابتدا مشخص کن نتیجه مربوط به کدام صفحه و کدام دستگاه است؛ سپس داده‌های کاربران واقعی را از آزمون آزمایشگاهی جدا کن و در پایان، پیشنهادهای ابزار را به چند اقدام اولویت‌دار تبدیل کن. امتیاز بزرگ Performance فقط یکی از بخش‌های گزارش است و بهتنهایی وضعیت سرعت سایت را توضیح نمیدهد.
در این راهنما یاد می‌گیری از میان عددها و هشدارها، مسئلهٔ اصلی را پیدا کنی و گزارشی بنویسی که مدیر سایت و طراح وردپرس بتوانند بر اساس آن تصمیم بگیرند.
PageSpeed Insights چه چیزی را بررسی می‌کند؟
PageSpeed Insights ابزاری از گوگل برای بررسی عملکرد یک نشانی وب در موبایل و دسکتاپ است. گزارش آن دو لایه دارد: تجربهٔ ثبت‌شدهٔ کاربران واقعی و یک آزمون شبیه‌سازی‌شده با Lighthouse. اولی نشان میدهد کاربران چه تجربه‌ای داشته‌اند؛ دومی برای پیدا کردن سرنخ‌های فنی مفید است. راهنمای رسمی ابزار این دو بخش را جداگانه توضیح میدهد.
این مقاله روی اندازه‌گیری و اولویت‌بندی اصلاحات عملکرد تمرکز دارد. برای جایگاه سرعت در کنار موضوعاتی مانند خزش و ایندکس، مقالهٔ سئو تکنیکال چیست؟ راهنمای کاربردی بهینهسازی فنی سایت را بخوان.
قدم اول: صفحه و دستگاه درست را انتخاب کن
آزمون صفحهٔ اصلی، جای بررسی صفحهٔ محصول یا خدمات را نمی‌گیرد. از صفحه‌ای شروع کن که برای کسب‌وکارت مهم است: صفحهٔ فرود تبلیغ، محصول پرفروش یا صفحهٔ دریافت درخواست.
۱. نشانی کامل صفحه را در PageSpeed Insights وارد کن و Analyze را بزن.
۲. آدرس نهایی گزارش را بررسی کن؛ ممکن است صفحه به نشانی دیگری هدایت شده باشد.
۳. تب Mobile یا Desktop را آگاهانه انتخاب کن. اگر بیشتر مشتریانت با موبایل وارد می‌شوند، بررسی موبایل را جلوتر بگذار.
۴. تصویر کوچک صفحه را ببین؛ مطمئن شو ابزار صفحهٔ موردنظر را دریافت کرده، نه صفحهٔ خطا یا محدودیت دسترسی.
۵. تاریخ، ساعت، دستگاه و اطلاعات محیط آزمون را ثبت کن.
برای مقایسهٔ قبل و بعد، همان صفحه و همان نوع دستگاه را نگه دار. تفاوت امتیاز موبایل و دسکتاپ را بهتنهایی نشانهٔ خرابی نسخهٔ موبایل ندان؛ شرایط آزمون و شیوهٔ امتیازدهی آن‌ها یکسان نیست. مستند امتیازدهی Lighthouse این تفاوت را توضیح میدهد.
قدم دوم: دادهٔ میدانی را از دادهٔ آزمایشگاهی جدا کن
| بخش گزارش | منشأ داده | به چه پرسشی پاسخ میدهد؟ | محدودیت مهم |
|---|---|---|---|
| دادهٔ میدانی؛ تجربهٔ کاربران واقعی | مجموعه‌دادهٔ CrUX از کاربران واجد شرایط Chrome | کاربران در عمل چه تجربه‌ای داشته‌اند؟ | همهٔ بازدیدکنندگان را پوشش نمیدهد؛ ممکن است نمونهٔ کافی نداشته باشد |
| دادهٔ آزمایشگاهی؛ بررسی با Lighthouse | بارگذاری شبیه‌سازی‌شده در شرایط مشخص | در این اجرا چه موانعی دیده می‌شود؟ | نمایندهٔ تمام دستگاه‌ها، شبکه‌ها و تعامل‌های کاربران نیست |
طبق توضیح web.dev دربارهٔ تفاوت داده‌های میدانی و آزمایشگاهی، اختلاف این دو لزوماً خطا نیست. کاربران واقعی از دستگاه‌ها و شبکه‌های متفاوت استفاده می‌کنند، اما آزمون آزمایشگاهی شرایط محدودتری دارد.
This URL و Origin را اشتباه نگیر
در بخش دادهٔ میدانی دقت کن اطلاعات برای This URL است یا Origin. اولی به همان نشانی مربوط است؛ دومی دادهٔ تجمیعی صفحات یک مبدأ وب را نشان میدهد. مبدأ با پروتکل، میزبان و پورت مشخص می‌شود؛ بنابراین نسخه‌های www و بدون www الزاماً یک مبدأ نیستند.
اگر دادهٔ صفحه کافی نباشد، ابزار ممکن است دادهٔ Origin را نمایش دهد. نتیجهٔ Origin را به همان صفحه نسبت نده. دادهٔ میدانی PSI مربوط به یک دورهٔ ۲۸روزه است؛ تاریخ آن دوره را از خود گزارش بردار. نبود داده نیز به معنی سریع یا کند بودن صفحه نیست. این رفتار در مستندات PageSpeed Insights توضیح داده شده است.
قدم سوم: سه شاخص اصلی تجربهٔ کاربر را بخوان
Core Web Vitals سه جنبه را بررسی می‌کند: نمایش محتوای اصلی، پاسخ‌گویی به تعامل و ثبات بصری.
| شاخص | معنی کاربردی | خوب | نیازمند بهبود | ضعیف |
|---|---|---|---|---|
| LCP | زمان نمایش بزرگ‌ترین عنصر محتوایی قابل‌مشاهده | حداکثر ۲٫۵ ثانیه | بیشتر از ۲٫۵ تا ۴ ثانیه | بیشتر از ۴ ثانیه |
| INP | تأخیر پاسخ بصری به تعامل‌هایی مثل کلیک، لمس و تایپ | حداکثر ۲۰۰ میلی‌ثانیه | بیشتر از ۲۰۰ تا ۵۰۰ میلی‌ثانیه | بیشتر از ۵۰۰ میلی‌ثانیه |
| CLS | میزان جابه‌جایی غیرمنتظرهٔ چیدمان | حداکثر ۰٫۱ | بیشتر از ۰٫۱ تا ۰٫۲۵ | بیشتر از ۰٫۲۵ |
CLS واحد زمانی ندارد. عددهای میدانی را نیز «میانگین» نخوان: مبنای ارزیابی، صدک ۷۵ است؛ یعنی حدود ۷۵ درصد مشاهده‌ها مقداری برابر یا بهتر از آن داشته‌اند. تعریف‌ها و آستانه‌ها در راهنمای Web Vitals و جدول رسمی PSI آمده‌اند.
Passed و Failed چه می‌گویند؟
وقتی هر سه شاخص دادهٔ کافی داشته باشند، قبولی Core Web Vitals به خوب بودن هر سه در صدک ۷۵ نیاز دارد. اگر INP دادهٔ کافی نداشته باشد، PSI می‌تواند بر اساس LCP و CLS ارزیابی کند؛ نبود دادهٔ کافی برای LCP یا CLS مانع ارزیابی است. پس وضعیت ارزیابی را همراه با شاخص‌های موجود بخوان. منبع: قواعد ارزیابی PSI
قدم چهارم: امتیاز Performance را درست تفسیر کن
امتیاز Performance ترکیبی وزن‌دار از چند شاخص آزمایشگاهی است. محدوده‌های آن عبارت‌اند از:
- ۰ تا ۴۹: ضعیف.
- ۵۰ تا ۸۹: نیازمند بهبود.
- ۹۰ تا ۱۰۰: خوب.
عدد ۶۰ یعنی نتیجهٔ این آزمون در محدودهٔ نیازمند بهبود است؛ نه اینکه سایت «۶۰ درصد سریع» باشد. سبز بودن آن هم بهتنهایی قبولی Core Web Vitals را ثابت نمی‌کند. امتیازهای Accessibility، Best Practices و SEO نیز دسته‌های جداگانه‌اند. منبع: امتیازدهی Lighthouse
FCP، Speed Index و TBT به چه کار می‌آیند؟
کنار LCP و CLS آزمایشگاهی، این شاخص‌ها را می‌بینی:
- FCP: زمان ظاهر شدن نخستین محتوای صفحه؛ برای بررسی شروع نمایش محتوا مفید است.
- Speed Index: سرعت تکمیل بصری صفحه هنگام بارگذاری را توصیف می‌کند.
- TBT: مجموع بخش مسدودکنندهٔ کارهای طولانی در بازهٔ اندازه‌گیری؛ سرنخی برای بررسی مشغول بودن مسیر اصلی پردازش مرورگر است.
TBT همان INP نیست. آزمون معمول بارگذاری Lighthouse تعامل واقعی کاربر ندارد؛ بنابراین TBT می‌تواند به عیب‌یابی پاسخ‌گویی کمک کند، اما جای اندازه‌گیری INP را نمی‌گیرد. TBT پایین هم تضمین نمی‌کند منوی سایت یا فیلتر محصولات سریع پاسخ بدهد. منبع: راهنمای TBT
قدم پنجم: هشدارها را به مسئلهٔ قابل‌بررسی تبدیل کن
در بخش Insights و بررسی‌های تشخیصی، هر مورد را باز کن و فایل، عنصر یا درخواست مرتبط را ببین. عنوان هشدار بهتنهایی برای تجویز راه‌حل کافی نیست.
نام بعضی بررسی‌ها با آموزش‌های قدیمی فرق دارد. در Lighthouse 13، تعدادی از بررسی‌های قبلی با Insights جایگزین شده‌اند؛ مثلاً بررسی‌های مرتبط با تصاویر و منابع مسدودکنندهٔ نمایش بازسازمان‌دهی شده‌اند. نسخهٔ ثبت‌شده در گزارش خودت را ملاک قرار بده.
| نشانه | پرسش بعدی | بررسی اولیهٔ پیشنهادی |
|---|---|---|
| LCP بالا | عنصر LCP چیست و کدام بخش مسیر نمایش آن دیر تمام می‌شود؟ | پاسخ سند، زمان کشف منبع، دریافت و نمایش عنصر |
| INP نامطلوب یا TBT بالا | هنگام تعامل یا بارگذاری، چه پردازشی مرورگر را مشغول می‌کند؟ | اسکریپت‌ها، کارهای طولانی و تعامل مسئله‌دار |
| CLS بالا | کدام عنصر جابه‌جا می‌شود و چه چیزی آن را هل میدهد؟ | فضای تصاویر، بنرها، فونت و محتوای دیرهنگام |
| زمان رسیدن اولین بایت بالا | تأخیر قبل از دریافت پاسخ از کجا می‌آید؟ | شبکه، هدایتها، کش و پردازش سمت سرور |
این‌ها نقطهٔ شروع بررسی‌اند، نه تشخیص قطعی. برای مثال، LCP بالا همیشه با کم‌کردن حجم عکس حل نمی‌شود؛ تصویر ممکن است دیر کشف شود یا نمایش آن منتظر پردازش دیگری بماند. راهنمای بهبود Core Web Vitals بر بررسی مسیر واقعی تأخیر تأکید دارد.
اگر کنار چند پیشنهاد، صرفه‌جویی تخمینی دیدی، آن‌ها را جمع نزن و به‌عنوان بهبود قطعی گزارش نکن؛ اثر اصلاحات می‌تواند هم‌پوشانی داشته باشد. نتیجه باید با آزمون مجدد سنجیده شود.
نمونهٔ گزارش حاشیه‌نویسی‌شده با تاریخ آزمون
این نمونه کاملاً فرضی و آموزشی است؛ هیچ‌یک از عددهای زیر نتیجهٔ آزمون واقعی سبک‌تر یا یک مشتری نیست. تاریخ تهیهٔ نمونه ۲۲ سپتامبر ۲۰۲۶ است. تاریخ آزمون در سناریوی فرضی نیز همین روز در نظر گرفته شده؛ در گزارش واقعی باید زمان ثبت‌شدهٔ ابزار جایگزین شود.
مشخصات سناریوی فرضی
- صفحه: صفحهٔ خدمات یک سایت وردپرسی فرضی.
- دستگاه: Mobile.
- تاریخ آزمون فرضی: ۲۰۲۶/۰۹/۲۲، ساعت ۱۰:۰۰ UTC.
- دامنهٔ دادهٔ میدانی: Origin؛ برای خود صفحه دادهٔ کافی وجود ندارد.
- بازهٔ میدانی و نسخهٔ Lighthouse: در این نمونه ساخته نشده‌اند؛ در گزارش واقعی عیناً ثبت شوند.
گزارش همراه با یادداشت تحلیل‌گر
| ردیف | دادهٔ فرضی گزارش | حاشیه‌نویسی و برداشت درست |
|---|---|---|
| ۱ | Core Web Vitals: Failed در سطح Origin | مشکل در دادهٔ تجمیعی مبدأ دیده می‌شود؛ هنوز نمی‌توان وضعیت همین صفحه را قطعی دانست. |
| ۲ | LCP میدانی: ۳٫۲ ثانیه | نیازمند بهبود است؛ مبنای تحلیل، کاربران موبایل همان Origin هستند. |
| ۳ | INP میدانی: ۲۶۰ میلی‌ثانیه | پاسخ‌گویی نیازمند بررسی است؛ تعامل کند از این عدد مشخص نمی‌شود. |
| ۴ | CLS میدانی: ۰٫۰۶ | در محدودهٔ خوب است؛ فعلاً نشانهٔ اصلی مسئله در دادهٔ تجمیعی نیست. |
| ۵ | LCP آزمایشگاهی: ۴٫۶ ثانیه | نمایش محتوای اصلی این صفحه در اجرای فعلی کند بوده؛ عنصر و مسیر LCP بررسی شود. |
| ۶ | TBT آزمایشگاهی: ۴۲۰ میلی‌ثانیه | سرنخ بررسی کارهای طولانی است؛ آن را INP صفحه گزارش نکن. |
| ۷ | CLS آزمایشگاهی: ۰٫۰۲ | جابه‌جایی کمی در این اجرا ثبت شده؛ رفتار بعد از اسکرول و تعامل هنوز بررسی نشده است. |
| ۸ | تصویر بالای صفحه به‌عنوان عنصر LCP شناسایی شده | بررسی شود تصویر چه زمانی درخواست و نمایش داده می‌شود؛ صرفاً تغییر فرمت کافی نیست. |
امتیاز ترکیبی Performance را عمداً برای این نمونه نساخته‌ایم؛ محاسبهٔ آن به مجموعهٔ کامل شاخص‌ها و قواعد نسخهٔ ابزار نیاز دارد.
تصمیم عملی از این گزارش چیست؟
برای همین سناریوی فرضی، برنامهٔ اولیه می‌تواند چنین باشد:
۱. اولویت اول: بررسی LCP صفحه. مسیر بارگذاری تصویر اصلی و تأخیر نمایش آن ثبت شود؛ سپس فقط اصلاح مرتبط با علت تأییدشده انجام شود.
۲. اولویت دوم: بررسی پاسخ‌گویی. کارهای طولانی شناسایی و تعامل‌هایی مثل بازکردن منو و ارسال فرم جداگانه آزمایش شوند.
۳. اولویت سوم: کنترل بازگشت مشکل. بعد از اصلاح، نمایش صفحه و عملکرد فرم دوباره بررسی شود تا بهبود یک عدد باعث خرابی بخش دیگری نشده باشد.
خلاصهٔ قابل‌ارسال به مدیر سایت:
در آزمون فرضی موبایل، مسئلهٔ اصلی این صفحه تأخیر نمایش محتوای اصلی است. دادهٔ کاربران واقعی فقط در سطح Origin موجود است؛ برای نتیجه‌گیری دربارهٔ تجربهٔ همین صفحه، شواهد بیشتری لازم داریم.
در سایت وردپرسی، کدام اصلاح را جلوتر بگذاریم؟
اولویت را از ترکیب اهمیت صفحه، شواهد اثر بر کاربر، گستردگی مشکل و هزینهٔ اصلاح تعیین کن. یک فایل کوچکِ کم‌استفاده الزاماً از اسکریپتی که تعامل با فرم درخواست را کند می‌کند مهم‌تر نیست.
برای هر اقدام، این چهار مورد را بنویس:
- شاهد: چه عدد، عنصر یا فایلی مسئله را نشان داده است؟
- فرضیه: این مورد چگونه باعث کندی می‌شود؟
- اقدام محدود: دقیقاً چه چیزی تغییر می‌کند؟
- معیار پذیرش: با چه اندازه‌گیری و بررسی عملکردی، موفقیت را می‌سنجیم؟
برای نمونه، به‌جای «همهٔ افزونه‌ها را کم کنیم» بنویس: «اثر اسکریپت افزونهٔ مشخص بر بارگذاری این صفحه بررسی شود؛ اگر در این صفحه لازم نیست، بارگذاری آن با کنترل وابستگی‌ها متوقف شود.»
تغییرات را ابتدا در محیط آزمایشی انجام بده و منو، فرم و خرید را متناسب با سایت بررسی کن.
اگر تصمیم به حذف تصویر، ساده‌سازی بخش‌ها یا تغییر ساختار صفحه رسید، اصول مطرح‌شده در ۱۰ نکته مهم طراحی سایت برای ساخت وب‌سایتی حرفه‌ای، سریع و کاربرپسند کمک می‌کند عملکرد را در کنار کاربردپذیری ببینی.
بعد از اصلاح، چگونه نتیجه را بسنجیم؟
پیشنهاد اجرایی این راهنما این است که پیش و پس از تغییر، آزمون را چند بار با شرایط قابل‌مقایسه اجرا کنی؛ مثلاً سه اجرا داشته باشی و میانهٔ هر شاخص را همراه با دامنهٔ تغییرات ثبت کنی. بهترین اجرا را بهتنهایی به‌عنوان نتیجه معرفی نکن.
بهبود آزمایشگاهی را میتوان بلافاصله بررسی کرد، اما دادهٔ میدانی سابقهٔ کاربران را نشان میدهد و یک‌باره جایگزین نمی‌شود. برای مشاهدهٔ اثر تغییر، بازهٔ گزارش و تاریخ اعمال اصلاح را کنار هم نگه دار. اگر بررسی دقیق‌تر و سریع‌تر لازم است، پایش کاربران واقعی یا RUM می‌تواند مکمل باشد. راهنمای انتخاب ابزارهای Core Web Vitals نقش این روش‌ها را توضیح میدهد.
پرسش‌های متداول
چرا PageSpeed عدد خوبی نشان میدهد، اما سایت برای من کند است؟
ممکن است دستگاه، شبکه، موقعیت جغرافیایی یا کاری که انجام میدهی با شرایط آزمون فرق داشته باشد. همچنین آزمون بارگذاری لزوماً کندی بعد از ورود، اسکرول یا استفاده از فیلترها را نشان نمیدهد. همان مسیر کند را جداگانه بررسی کن.
آیا با این گزارش میتوان فهمید باید هاست را عوض کنم؟
بهتنهایی خیر. حتی تأخیر دریافت پاسخ هم نیازمند تفکیک علت است. ابتدا وضعیت کش، پردازش سمت سرور، هدایتها و مسیر شبکه را بررسی کن؛ سپس دربارهٔ تغییر هاست تصمیم بگیر.
اگر دادهٔ کاربران واقعی ندارم، بهینهسازی را متوقف کنم؟
خیر. با آزمونهای آزمایشگاهی، بررسی روی دستگاه واقعی و آزمایش مسیرهای مهم شروع کن. فقط نتیجه را با عنوان «آزمون آزمایشگاهی» گزارش بده و آن را نمایندهٔ همهٔ کاربران معرفی نکن.
آیا امتیاز ۱۰۰ رتبهٔ گوگل را تضمین می‌کند؟
خیر. امتیاز Lighthouse تضمین رتبه نیست. گوگل Core Web Vitals را در کنار سایر جنبه‌های تجربهٔ صفحه بررسی می‌کند؛ کیفیت و ارتباط محتوا نیز اهمیت دارند.
گزارش خوب باید به اقدام مشخص برسد
خروجی خواندن گزارش PageSpeed Insights بهتر است چیزی بیشتر از یک اسکرین‌شات رنگی باشد: صفحه و دستگاه مشخص، تفکیک دادهٔ میدانی و آزمایشگاهی، چند مسئلهٔ مستند و روشی روشن برای سنجش نتیجه.
از یک صفحهٔ مهم شروع کن، علت محتمل را بررسی کن و بعد از هر اصلاح دوباره اندازه بگیر. برای بررسی سرعت، یک صفحهٔ مهم سایتت و نوع دستگاه مخاطبانت را برای سبک‌تر بفرست تا بررسی را از همان‌جایی شروع کنیم که برای کسب‌وکارت اهمیت دارد.
توی این مقاله
برای طراحی سایت، بهتر دیده‌شدن یا تولید محتوا، از اینجا شروع کن.