آموزش PageSpeed Insights؛ خواندن گزارش و انتخاب اولین اصلاح سایت

اگر گزارشی از PageSpeed Insights گرفته‌اید و تنها به عدد رنگی بالای صفحه نگاه می‌کنید، احتمال دارد مهم‌ترین نکته را از دست بدهید. این ابزار برای یک نشانی وب، دیدی از تجربه کاربران و یک آزمون فنی فراهم می‌کند؛ این دو نوع داده را نباید جای یکدیگر گذاشت. در این آموزش PageSpeed Insights یاد می‌گیرید یک صفحه مهم را بررسی کنید، LCP و INP و CLS را درست بخوانید و به جای فهرست بلند پیشنهادها، یک اصلاح قابل‌آزمون انتخاب کنید.

فرض کنید صفحه معرفی خدمات سایتتان در موبایل کند به نظر می‌رسد. هدف این راهنما این نیست که برای همان صفحه نتیجه‌ای واقعی ادعا کند؛ سناریو صرفاً نمونه تصمیم‌گیری است. اگر مسئله شما اصلاً دیده‌نشدن صفحه در جست‌وجو است، ابتدا راهنمای Search Console و عیب‌یابی ایندکس را بخوانید. گزارش عملکرد صفحه و گزارش ایندکس دو پرسش جدا پاسخ می‌دهند.

۱. صفحه و هدف آزمون را پیش از باز کردن گزارش مشخص کنید

یک URL عمومی و مشخص انتخاب کنید: برای مثال صفحه محصول، فرم ثبت‌نام یا مقاله‌ای که برای مخاطب اهمیت دارد. نسخه درست نشانی را با HTTPS، مسیر و اسلش انتهایی ثبت کنید. اگر سایت چند قالب دارد، یک صفحه نماینده از هر قالب را بعداً جداگانه بررسی کنید؛ میانگین یک صفحه را به تمام سایت تعمیم ندهید. در راهنمای رسمی Core Web Vitals در Search Console هم تصریح شده که گزارش آن URLها را در گروه‌های مشابه جمع می‌کند، در حالی که PageSpeed Insights عموماً URL منفرد را می‌سنجد.

نشانی را در ابزار PageSpeed Insights وارد کنید و دو نمای موبایل و دسکتاپ را جدا بخوانید. برای تصمیم‌گیری، یکی را به جای دیگری انتخاب نکنید. اگر کاربران اصلی شما با موبایل وارد می‌شوند، داده موبایل را در اولویت عملی بگذارید؛ اما تغییرات دسکتاپ را هم کنترل کنید تا اصلاح یک نما به نمای دیگر آسیب نزند. تاریخ اجرا، URL و نوع دستگاه را در یادداشت خود ثبت کنید. اگر صفحه پشت ورود است یا دسترسی عمومی ندارد، محدودیت آزمون عمومی را نیز صریح بنویسید.

چه چیزی را پیش از مقایسه ثابت نگه داریم؟

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

۲. داده کاربران واقعی را از داده آزمایشگاهی جدا کنید

بخش تجربه کاربران واقعی بر داده‌های گردآوری‌شده از بازدیدهای واقعی تکیه دارد؛ بخش آزمایشگاهی یک بارگذاری شبیه‌سازی‌شده و تشخیص فنی ارائه می‌کند. داده واقعی برای فهم تجربه‌ای که کاربران داشته‌اند مفید است، اما لزوماً علت دقیق کندی را نشان نمی‌دهد. داده آزمایشگاهی برای یافتن سرنخ و بازآزمایی تغییر مناسب است، اما به‌تنهایی جانشین رفتار کاربران در دستگاه و شبکه‌های گوناگون نیست. مستندات رسمی گوگل درباره اختلاف داده یک URL در PSI با گروه همان URL در Search Console و تفاوت آزمون زنده و داده کاربران واقعی توضیح می‌دهد.

ابتدا ببینید داده واقعی برای همان URL نمایش داده شده یا برای کل Origin سایت. اگر فقط داده Origin موجود است، آن را با عملکرد همان صفحه یکی ندانید؛ این داده تجربه مجموعه‌ای از صفحات همان مبدا را بازتاب می‌دهد. اگر داده واقعی اصلاً وجود ندارد، برچسب «بدون داده کافی» را به‌عنوان شکست یا موفقیت عملکرد تفسیر نکنید. در چنین حالتی گزارش آزمایشگاهی را برای ساخت فرضیه استفاده کنید، نه برای اعلام وضعیت همه کاربران. راهنمای وظایف Search Console نیز پایش معیارهای تجربه صفحه در مقیاس سایت را از بررسی یک URL جدا می‌کند.

چرا دو گزارش ممکن است یکسان نباشند؟

Search Console معمولاً URLهای مشابه را گروه‌بندی می‌کند و داده کاربران واقعی را برای گروه نشان می‌دهد؛ PSI بیشتر بر URL واردشده تمرکز دارد و در نبود داده کافی ممکن است سطح مبدا را نمایش دهد. یک صفحه خاص می‌تواند از گروه خود بهتر یا بدتر باشد. همچنین داده واقعی حاصل بازه‌ای از بازدیدهاست، نه نتیجه فوری آخرین تغییر کد. پس اگر امروز یک تصویر را اصلاح کردید و گزارش واقعی هنوز تغییری نشان نمی‌دهد، فوراً نتیجه نگیرید اصلاح بی‌اثر بوده است. نخست نتیجه آزمون آزمایشگاهی و ثبت تغییر را بررسی کنید و برای جمع‌شدن داده واقعی زمان بدهید.

۳. سه معیار اصلی را به زبان مسئله ترجمه کنید

LCP زمان نمایان‌شدن بزرگ‌ترین عنصر محتوایی در محدوده دید را توصیف می‌کند؛ این عنصر ممکن است تصویر اصلی یا بلوک بزرگ متن باشد. INP به پاسخ‌گویی صفحه به تعامل‌هایی مانند کلیک، لمس یا تایپ مربوط است. CLS میزان جابه‌جایی غیرمنتظره اجزای صفحه را نشان می‌دهد. طبق جدول رسمی وضعیت معیارها، بازه «خوب» برای LCP حداکثر ۲٫۵ ثانیه، برای INP حداکثر ۲۰۰ میلی‌ثانیه و برای CLS حداکثر ۰٫۱ است. این مرزها برای خواندن وضعیت‌اند، نه وعده رتبه یا تضمین تجربه یکسان برای همه.

اگر LCP مسئله‌دار است، در گزارش تشخیصی به عنصر بزرگ صفحه و مسیر بارگذاری آن نگاه کنید: تصویر بالای صفحه، پاسخ اولیه سرور و منابعی که نمایش را به تأخیر می‌اندازند نامزدهای بررسی‌اند. اگر INP بد است، تعامل مشخصی را پیدا کنید که کاربر واقعاً انجام می‌دهد و ببینید آیا کار سنگین جاوااسکریپت یا واکنش کند رابط با آن هم‌زمان است. اگر CLS بد است، هنگام بارگذاری و تعامل مشاهده کنید آیا تصویر، تبلیغ، فونت یا بخش دیررس بدون فضای رزروشده باعث پرش چیدمان می‌شود. اینها فرضیه‌های فنی‌اند؛ علت را باید با مشاهده همان صفحه تأیید کرد.

تفاوت معیار کاربر با یک نمره کلی

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

۴. از گزارش، یک مسئله و یک فرضیه اصلاح بیرون بکشید

برای سناریوی فرضی صفحه خدمات، فرض کنید در موبایل LCP در وضعیت نیازمند بهبود است و گزارش آزمایشگاهی تصویر بالای صفحه را به‌عنوان عنصر بزرگ نشان می‌دهد. عبارت «تصویر را بهینه کنید» هنوز برنامه عمل نیست. فرضیه دقیق‌تر چنین است: فایل تصویر بیش از نیاز صفحه سنگین است یا دیر درخواست می‌شود؛ اگر اندازه و نحوه بارگذاری آن را با حفظ کیفیت و نسبت درست اصلاح کنیم، بارگذاری همان عنصر در آزمون قابل‌مقایسه بهتر می‌شود. سپس پیش از دست‌زدن به چند بخش دیگر، نسخه فعلی تصویر، روش ارائه و نتیجه آزمون را ثبت کنید.

اگر شواهد به تصویر اشاره نکنند، همین اصلاح را کورکورانه انجام ندهید. برای LCP ناشی از کندی پاسخ اولیه، مسیر سرور و کش را بررسی کنید؛ برای INP به تعامل کند واقعی و کارهای مسدودکننده نگاه کنید؛ برای CLS فضای اجزای دیررس را بسنجید. ترتیب بررسی تابع داده صفحه است. راهنمای رفع مشکل گوگل پیشنهاد می‌کند موارد «Poor» را پیش از «Needs improvement» و سپس گروه‌های پراثر یا صفحات مهم را اولویت بدهید. این یک قاعده عملی برای صف کار است، نه ادعای اینکه هر مورد با یک تغییر ساده حل می‌شود.

فرم کوتاه برای ثبت تصمیم

• صفحه و دستگاه: URL دقیق و موبایل یا دسکتاپ.
• نوع داده: کاربران واقعی همان URL، مبدا سایت یا آزمون آزمایشگاهی؛ نبود داده را هم بنویسید.
• مشکل: LCP، INP یا CLS و وضعیت آن، بدون تعمیم به همه صفحات.
• شاهد: عنصر، تعامل یا جابه‌جایی مشخصی که در گزارش یا مشاهده صفحه دیده‌اید.
• فرضیه: یک علت احتمالی و یک تغییر محدود برای آزمودن آن.
• بازسنجی: همان URL، همان نما و یادداشت زمان اجرا و تغییر اعمال‌شده.

این فرم کوچک جلوی کار پراکنده را می‌گیرد. اگر شاهد کافی ندارید، نتیجه را «نامشخص» بنویسید و ابتدا داده بیشتر جمع کنید؛ عدد ساختگی یا نتیجه آزمون انجام‌نشده را در گزارش تیم قرار ندهید.

۵. بازسنجی را با دو افق زمانی انجام دهید

پس از یک تغییر کوچک، آزمون زنده همان صفحه را در همان نمای دستگاه تکرار کنید. علاوه بر نمره، معیار مرتبط و تشخیص فنی را بخوانید: آیا عنصر LCP عوض شده، پرش صفحه از بین رفته یا تعامل کند در شرایط آزمون بهبود یافته است؟ چند اجرای قابل‌مقایسه را ثبت کنید تا نوسان یک اجرا شما را گمراه نکند. اگر ظاهر یا دسترسی‌پذیری صفحه خراب شده است، تغییر را موفق ندانید حتی اگر یک عدد بهتر شده باشد.

برای تجربه واقعی کاربران، گزارش Core Web Vitals در Search Console را نیز بعداً پایش کنید. این گزارش داده تاریخی و گروهی دارد و به‌روزرسانی‌اش همان لحظه بازنویسی صفحه نیست. اگر URL یا گروه داده کافی ندارد، آن را شفاف گزارش کنید. راهنمای گوگل مراحل اولویت‌بندی، آزمون اصلاح و پیگیری اعتبارسنجی را توضیح می‌دهد؛ صرف فشار دادن دکمه اعتبارسنجی جای اصلاح واقعی و مشاهده نتیجه نیست.

اشتباه‌های رایج در تفسیر PageSpeed Insights

1. نمره آزمایشگاهی را به‌عنوان تجربه قطعی همه بازدیدکنندگان بیان‌کردن.
2. داده Origin را با داده همان URL یا وضعیت گروه Search Console یکسان دانستن.
3. نبود داده کاربران واقعی را «سرعت عالی» یا «سرعت بد» معناکردن.
4. موبایل و دسکتاپ را در یک نتیجه واحد مخلوط‌کردن.
5. چند تغییر بزرگ را هم‌زمان انجام‌دادن و بعد علت تغییر نمره را حدس‌زدن.
6. برای رسیدن به عدد خاص، تصویر یا تعامل ضروری را حذف‌کردن و کیفیت استفاده را نادیده‌گرفتن.
7. مشکل ایندکس را با مشکل سرعت یکی دانستن. برای اولی گزارش ایندکس Search Console و راهنمای رسمی Page indexing مناسب‌اند.

پرسش‌های متداول

چرا برای URL من داده واقعی نیست؟

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

آیا نمره سبز یعنی کار تمام است؟

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

اول کدام معیار را اصلاح کنم؟

صفحات مهم و موارد با وضعیت ضعیف و داده معتبر را جلو بگذارید. سپس شواهد همان صفحه را ببینید و یک تغییر محدود با امکان بازسنجی انتخاب کنید. برای همه سایت‌ها یک ترتیب ثابت وجود ندارد.

آیا بهبود سرعت، رتبه جست‌وجو را تضمین می‌کند؟

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

جمع‌بندی و گام بعدی

PageSpeed Insights وقتی مفید است که از آن برای طرح پرسش دقیق استفاده کنید: داده از کاربر واقعی آمده یا از آزمون؟ مربوط به همین URL است یا مبدا؟ مشکل اصلی بارگذاری، پاسخ‌گویی یا پایداری چیدمان است؟ با پاسخ به این پرسش‌ها می‌توان از یک گزارش شلوغ به یک فرضیه اصلاح رسید. اگر تازه ساختار صفحه را یاد می‌گیرید، راهنمای نخستین صفحه HTML و CSS به فهم اجزایی که اندازه و جایگاهشان بر چیدمان اثر می‌گذارد کمک می‌کند.

یک صفحه مهم سایتتان را در موبایل و دسکتاپ بررسی کنید، یک فرضیه اصلاح کوچک بنویسید و نتیجه را با همان URL و شرایط قابل‌مقایسه دوباره بسنجید.