parsvt.com

تفسیر گزارش PageSpeed را از کجا شروع کنیم؟

گزارش سرعت در نگاه اول شلوغ است. قدم اول در تفسیر گزارش PageSpeed این است که از بالا به پایین و از کلی به جزئی بخوانید.

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

بعد یک جمله‌ی خلاصه درباره‌ی موبایل می‌آید. این جمله از امتیاز سرعت موبایل ساخته می‌شود: از ۹۰ به بالا «سریع»، از ۵۰ تا ۸۹ «قابل قبول، ولی جای بهتر شدن دارد» و زیر ۵۰ «کند»؛ و اگر LCP اندازه گرفته شده باشد، همان زمان را هم کنارش می‌نویسد. زیر جمله، چند ایراد مهم آمده که هر کدام شما را به بخش خودش می‌برد: دو ایراد اول سرعت (همان‌هایی که بیشترین زمان را آزاد می‌کنند)، مشکل گواهی SSL، کار کردن سایت فقط با HTTP/1.1، تعداد ایرادهای سئو، و آماده نبودن جدی سایت برای هوش مصنوعی. اگر هیچ‌کدام نبود، نوشته شده «ایراد مهمی پیدا نشد». اگر فقط وقت خواندن همین بالای گزارش را دارید، همین فهرست کوتاه کار اول شماست.

هفت عقربه و سه رنگ: امتیاز از ۱۰۰ را چطور بخوانیم

بعد از خلاصه، عقربه‌ها می‌آیند. هر عقربه یک امتیاز از ۱۰۰ است و رنگش از قاعده‌ی خود Lighthouse می‌آید. طبق مستندات امتیازدهی Lighthouse، ۹۰ تا ۱۰۰ سبز و خوب است، ۵۰ تا ۸۹ نارنجی و نیازمند بهبود، و ۰ تا ۴۹ قرمز و ضعیف. در گزارش ما کنار رنگ، شکل هم هست (دایره برای خوب، مربع برای متوسط و مثلث برای ضعیف) تا کسی که رنگ‌ها را خوب تشخیص نمی‌دهد هم بتواند گزارش را بخواند.

هفت امتیاز گزارش این‌هاست: سرعت موبایل، سرعت دسکتاپ، سئو، گواهی SSL، آمادگی برای هوش مصنوعی، دسترس‌پذیری و شیوه‌های درست. پنج تای آن‌ها (دو سرعت، سئو، دسترس‌پذیری و شیوه‌های درست) خروجی مستقیم Lighthouse است. امتیاز SSL و هوش مصنوعی را بررسی‌های جداگانه‌ی خود ابزار می‌دهند و پایین‌تر توضیحشان می‌دهیم.

Lighthouse چیست و چه ربطی به PageSpeed دارد؟

اسم PageSpeed را بیشتر شنیده‌اید، ولی موتوری که پشت آن کار می‌کند Lighthouse است. طبق معرفی Lighthouse در مستندات Chrome، Lighthouse ابزاری خودکار و متن‌باز برای بهتر کردن کیفیت صفحه‌های وب است که بررسی‌هایی برای سرعت، دسترس‌پذیری، سئو و موارد دیگر دارد؛ می‌شود آن را داخل ابزارهای توسعه‌دهنده‌ی Chrome، از خط فرمان یا به شکل یک ماژول Node اجرا کرد. ابزار ما همین Lighthouse را اجرا می‌کند. پس هر عدد سرعت در گزارش ما خروجی خود Lighthouse است و نام انگلیسی هر سنجه (LCP، TBT، CLS، FCP و SI) کنار نام فارسی‌اش آمده تا بتوانید آن را با PageSpeed Insights یا گزارش Lighthouse داخل Chrome مقایسه کنید.

امتیاز PageSpeed (Performance) چطور حساب می‌شود؟

امتیاز سرعت یک نمره‌ی جادویی نیست؛ میانگین وزن‌دار پنج سنجه است. طبق همان مستندات Lighthouse، وزن‌ها در جدول نسخه‌ی ۱۰ این‌طور است: TBT سی درصد، LCP بیست‌وپنج درصد، CLS بیست‌وپنج درصد، FCP ده درصد و Speed Index ده درصد.

یعنی سه سنجه هشتاد درصد امتیاز را می‌سازند: TBT، LCP و CLS. برای همین در تفسیر گزارش PageSpeed به جای خیره شدن به عدد کلی، ببینید کدام سنجه قرمز است. کنار هر سنجه در گزارش ما همان نقطه‌ی رنگی و شکل هست، پس در یک نگاه معلوم است کدام عدد امتیاز را پایین کشیده.

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

Core Web Vitals چیست؟

گوگل سه سنجه را «شاخص‌های حیاتی وب» یا Core Web Vitals نامیده است، چون هر کدام یک بخش اصلی تجربه‌ی بازدیدکننده را می‌سنجد: بار شدن (LCP)، پاسخ دادن (INP) و ثبات (CLS). گوگل در راهنمای جستجو درباره‌ی Core Web Vitals این‌ها را مجموعه‌ای از سنجه‌ها می‌نامد که تجربه‌ی واقعی کاربر را می‌سنجند، به صاحبان سایت توصیه می‌کند در آن‌ها به نتیجه‌ی خوب برسند و می‌گوید این، کنار جنبه‌های دیگر تجربه‌ی صفحه، با چیزی هم‌سو است که سیستم‌های اصلی رتبه‌بندی‌اش می‌خواهند پاداش بدهند.

مرزها از مقاله‌ی تعیین آستانه‌های Core Web Vitals در web.dev می‌آید:

• LCP: تا ۲٫۵ ثانیه خوب، بیشتر از ۴ ثانیه ضعیف.
• INP: تا ۲۰۰ میلی‌ثانیه خوب، بیشتر از ۵۰۰ میلی‌ثانیه ضعیف.
• CLS: تا ۰٫۱ خوب، بیشتر از ۰٫۲۵ ضعیف.

همان مقاله می‌گوید برای قضاوت درباره‌ی یک صفحه یا سایت، صدک ۷۵ همه‌ی بازدیدها به کار می‌رود؛ یعنی اگر دست‌کم ۷۵ درصد بازدیدها در محدوده‌ی خوب باشند، آن سنجه خوب است. این نکته در تفسیر گزارش مهم است: یک تست خوب روی گوشی شما یعنی صفحه می‌تواند سریع باشد، نه اینکه برای همه سریع است.

LCP سایت چیست؟ بخش اصلی صفحه کی دیده می‌شود

LCP لحظه‌ای است که بزرگ‌ترین متن یا عکس صفحه روی صفحه‌نمایش می‌آید؛ معمولا عکس اصلی بالای صفحه، اسلایدر یا تیتر بزرگ. این همان لحظه‌ای است که بازدیدکننده حس می‌کند «صفحه باز شد». مقاله‌ی LCP در web.dev هدف ۲٫۵ ثانیه یا کمتر را پیشنهاد می‌کند.

دلیل‌های رایج LCP بد: سروری که دیر جواب می‌دهد، عکس اصلی سنگین یا بزرگ‌تر از اندازه‌ی نمایش، عکسی که مرورگر دیر پیدایش می‌کند (مثلا چون با جاوااسکریپت اضافه می‌شود یا «بارگذاری تنبل» رویش گذاشته‌اند)، و فایل‌های CSS و جاوااسکریپتی که تا کامل نرسند جلوی نمایش را می‌گیرند.

در گزارش، بخشی به نام «جزئیات زمان LCP» هست که زمان را به مرحله‌ها تقسیم می‌کند تا معلوم شود تأخیر از سرور است، از دانلود یا از نمایش. راهنمای بهینه‌سازی LCP چهار مرحله را نام می‌برد (پاسخ سرور، تاخیر شروع بارگذاری عکس، زمان دانلود عکس و تاخیر نمایش) و برای صفحه‌ای که خوب بهینه شده، حدود ۴۰ درصد را سهم پاسخ سرور و ۴۰ درصد را سهم دانلود می‌داند و هر کدام از دو تاخیر را زیر ۱۰ درصد. اگر در گزارش شما یکی از دو تاخیر بزرگ است، مشکل معمولا در کد صفحه است، نه در سرور یا حجم عکس. یک ردیف دیگر هم به کار می‌آید: «پیدا شدن زودهنگام عکس LCP»، که می‌گوید مرورگر عکس اصلی را از همان اول در HTML می‌بیند یا نه.

CLS سایت چیست؟ صفحه چقدر می‌پرد

حتما برایتان پیش آمده که می‌خواهید روی لینکی بزنید و همان لحظه عکسی بالای صفحه بار می‌شود و انگشتتان روی چیز دیگری می‌نشیند. CLS همین پرش‌ها را جمع می‌زند. طبق مقاله‌ی CLS در web.dev، هر بار که یک بخش دیده‌شدنی از یک فریم تا فریم بعد جایش را عوض کند، یک جابه‌جایی چیدمان رخ داده است. عدد CLS بی‌واحد است: تا ۰٫۱ خوب و بیشتر از ۰٫۲۵ ضعیف.

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

INP چیست و چرا در گزارش TBT آمده؟

INP می‌گوید وقتی بازدیدکننده روی دکمه‌ای می‌زند یا منویی را باز می‌کند، چقدر طول می‌کشد تا نتیجه را ببیند. طبق مقاله‌ی INP در web.dev، این سنجه تأخیر همه‌ی تعامل‌های کاربر با صفحه را می‌بیند و یک عدد گزارش می‌کند که همه یا تقریبا همه‌ی تعامل‌ها زیر آن بوده‌اند. تا ۲۰۰ میلی‌ثانیه خوب است، تا ۵۰۰ نیازمند بهبود، و بیشتر از آن ضعیف.

ولی INP فقط با کلیک‌های واقعی آدم‌ها اندازه گرفته می‌شود و در یک تست آزمایشگاهی که کسی روی صفحه نمی‌زند، وجود ندارد. web.dev صریح می‌گوید ابزاری مثل Lighthouse که صفحه را بدون کاربر باز می‌کند نمی‌تواند INP را بسنجد، ولی TBT در آزمایشگاه سنجیدنی است و نشانه‌ی نزدیکی برای INP است؛ بهتر شدن TBT در آزمایشگاه معمولا INP واقعی را هم بهتر می‌کند. برای همین گزارش ما INP ندارد و TBT را نشان می‌دهد.

TBT سایت چیست؟ صفحه چقدر قفل است

TBT جمع زمان‌هایی است که مرورگر سرش با اجرای کد گرم است و نمی‌تواند به کاربر جواب بدهد؛ در گزارش ما اسم فارسی‌اش «زمان قفل بودن صفحه» است. طبق مقاله‌ی TBT در web.dev، هر کاری که بیش از ۵۰ میلی‌ثانیه طول بکشد «طولانی» حساب می‌شود و فقط مقدار بیش از ۵۰ میلی‌ثانیه‌اش در TBT جمع می‌شود؛ همان مقاله هدف کمتر از ۲۰۰ میلی‌ثانیه روی سخت‌افزار موبایل معمولی را پیشنهاد می‌کند.

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

FCP، Speed Index و پاسخ سرور (TTFB) چیست؟

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

FCP (نخستین نمایش محتوا) لحظه‌ای است که اولین متن یا عکس روی صفحه می‌آید و صفحه‌ی سفید تمام می‌شود. طبق web.dev، تا ۱٫۸ ثانیه خوب و بیشتر از ۳ ثانیه ضعیف است. اگر FCP بد باشد، بازدیدکننده مدتی به صفحه‌ی خالی نگاه می‌کند و شک می‌کند که اصلا چیزی بار می‌شود. فاصله‌ی زیاد بین FCP و LCP هم چیزی می‌گوید: صفحه زود شروع کرده، ولی بخش اصلی‌اش دیر رسیده؛ معمولا یعنی عکس اصلی سنگین است یا دیر پیدا می‌شود.

Speed Index (شاخص سرعت) می‌گوید صفحه با چه سرعتی جلوی چشم پر می‌شود. Lighthouse از بار شدن صفحه فیلم می‌گیرد و پیشرفت تصویر را فریم به فریم می‌سنجد. طبق مستندات Speed Index، روی موبایل تا ۳٫۴ ثانیه سبز، تا ۵٫۸ ثانیه نارنجی و بیشتر از آن قرمز است.

پاسخ سرور (TTFB) زمانی است که طول می‌کشد تا سرور اولین بایت صفحه را بفرستد. این عدد جزو امتیاز Lighthouse نیست، ولی در گزارش ما جدا آمده چون پایه‌ی همه‌ی عددهای دیگر است: تا سرور جواب ندهد، هیچ چیزی شروع نمی‌شود. web.dev تا ۰٫۸ ثانیه را خوب و بیشتر از ۱٫۸ ثانیه را ضعیف می‌داند و رنگ این ردیف در گزارش ما از همین آستانه‌ها می‌آید. همان مقاله یادآوری می‌کند که TTFB جزو Core Web Vitals نیست، پس لازم نیست حتما سبز باشد؛ ولی اگر بالا باشد، LCP خوب سخت می‌شود. TTFB بالا معمولا یعنی هاست شلوغ، سرور دور از بازدیدکننده، نبود کش صفحه یا کدهای سنگین سمت سرور؛ در سایت‌های وردپرسی، افزونه‌های زیاد و پایگاه داده‌ی تنظیم‌نشده هم دلیل رایجی است.

فهرست ایرادها را چطور بخوانیم؟

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

این تخمین‌ها راهنما هستند، نه قول؛ Lighthouse آن‌ها را از شبیه‌سازی حساب می‌کند. ولی برای اولویت‌بندی عالی‌اند. چند ایراد که در گزارش‌ها زیاد دیده می‌شود:

• بهینه‌سازی تحویل عکس‌ها: عکس‌هایی که حجمشان زیاد است یا بزرگ‌تر از اندازه‌ای هستند که نمایش داده می‌شوند. معمولا ساده‌ترین و پربازده‌ترین کار است.
• درخواست‌های مانع نمایش: فایل‌های CSS و جاوااسکریپتی که مرورگر تا دانلودشان چیزی نشان نمی‌دهد.
• جاوااسکریپت بی‌استفاده یا تکراری: کدهایی که دانلود می‌شوند ولی در این صفحه به کاری نمی‌آیند.
• مدت نگهداری فایل‌ها در حافظه‌ی مرورگر: اگر فایل‌های ثابت کش نشوند، بازدیدکننده در هر بازدید دوباره آن‌ها را دانلود می‌کند.
• کدهای شخص ثالث: ابزارهایی که از سایت‌های دیگر می‌آیند و روی سرعت شما کنترلی ندارید.
• زنجیره‌ی درخواست‌های شبکه: فایل‌هایی که پشت سر هم و وابسته به هم بار می‌شوند.

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

بخش «وزن صفحه» حجم کل و تعداد درخواست‌ها را به تفکیک نوع فایل نشان می‌دهد: HTML، CSS، جاوااسکریپت، عکس، فونت و بقیه. اگر یک نوع بیشتر حجم را گرفته، همان‌جا را نگاه کنید؛ عکس سنگین بیشتر LCP را خراب می‌کند و جاوااسکریپت سنگین بیشتر TBT را.

گواهی SSL و هدرهای امنیتی

گواهی SSL همان چیزی است که نشانی سایت را از http به https می‌برد و اطلاعاتی را که بین بازدیدکننده و سایت رد و بدل می‌شود رمز می‌کند. سایتی که گواهی ندارد یا گواهی‌اش مشکل دارد، در مرورگر با هشدار امنیتی دیده می‌شود. اگر سایتی اصلا روی HTTPS جواب ندهد، گزارش ما همین را بالای این بخش می‌نویسد و بقیه‌ی تست را روی نسخه‌ی HTTP انجام می‌دهد.

برای سایتی که گواهی دارد، گزارش این‌ها را نشان می‌دهد: معتبر یا نامعتبر بودن، صادرکننده، تاریخ صدور و پایان اعتبار با تعداد روزهای مانده، دامنه‌هایی که گواهی برایشان صادر شده، نوع کلید و اتصالی که برقرار شده است. وقتی تا پایان اعتبار ۲۱ روز یا کمتر مانده، این ردیف نارنجی می‌شود؛ در این حالت تمدید خودکار گواهی را وارسی کنید.

ردیف «نسخه‌های TLS» چهار نسخه را نشان می‌دهد. TLS 1.3 و 1.2 نسخه‌های امروزی‌اند. اگر TLS 1.0 یا 1.1 روشن مانده باشد، گزارش آن را «روشن (ناامن)» می‌نویسد؛ این دو نسخه قدیمی‌اند و باید در سرور خاموش شوند. هر ایراد دیگری در تنظیم گواهی هم زیر عنوان «چیزهایی که باید درست شوند» آمده است.

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

HTTP/2 و HTTP/3، فشرده‌سازی و تغییر مسیرها

بخش «شبکه و پروتکل» می‌گوید سایت با چه زبانی با مرورگر حرف می‌زند. HTTP زبان اصلی وب است و نسخه‌هایش فرق بزرگی در سرعت دارند. در HTTP/1.1 قدیمی، مرورگر فایل‌ها را تقریبا یکی‌یکی می‌گیرد؛ HTTP/2 چند فایل را همزمان روی یک اتصال می‌فرستد؛ و HTTP/3 روی پایه‌ی تازه‌ای به نام QUIC ساخته شده که در اینترنت ناپایدار، مثل اینترنت همراه، بهتر رفتار می‌کند.

ابزار ما HTTP/2 را از خود اتصال امن (ALPN) تشخیص می‌دهد و HTTP/3 را از اعلام خود سرور در هدری به نام Alt-Svc می‌خواند. اگر سایتی هنوز فقط HTTP/1.1 دارد، این از ایرادهای مهمی است که در خلاصه‌ی بالای گزارش هم می‌آید، و معمولا با یک تنظیم در سرور یا CDN درست می‌شود.

ردیف‌های دیگر این بخش:

• فرستادن HTTP به HTTPS: کسی که نشانی را بدون https می‌نویسد باید خودکار به نسخه‌ی امن برسد.
• فشرده‌سازی: متن صفحه با Brotli، Zstandard یا gzip فشرده فرستاده می‌شود یا نه. فشرده‌سازی حجم فایل‌های متنی را خیلی کم می‌کند.
• HSTS: به مرورگر می‌گوید از این به بعد همیشه با HTTPS بیاید.
• IPv6: سایت روی نسل تازه‌ی نشانی‌های اینترنت هم در دسترس است یا نه.
• اولین پاسخ سرور (TTFB): همان عدد بخش سرعت، با همان رنگ‌ها.
• نشانی با www: نسخه‌ی با www به همین سایت می‌رسد، به جای دیگری می‌رود یا کار نمی‌کند.
• تغییر مسیر تا صفحه‌ی اصلی: هر تغییر مسیر (مثلا از نسخه‌ی بدون www به www و بعد به https) یک رفت‌وبرگشت اضافه است. وقتی بیشتر از یک بار باشد، گزارش آن را نارنجی می‌کند.

هاست و تکنولوژی: سایت روی چه چیزی ایستاده

این بخش می‌گوید سایت کجا میزبانی می‌شود و با چه ساخته شده است: شبکه یا دیتاسنتر، کشور سرور، CDN اگر هست، سرویس DNS، وب‌سرور؛ و هر تکنولوژی‌ای که تشخیص داده شده، به تفکیک دسته (مثلا سیستم مدیریت محتوا، فروشگاه‌ساز، ابزار آمار). طبق قاعده‌ی گزارش، فقط چیزی آمده که واقعا تشخیص داده شده؛ اگر ردیفی نیست، یعنی ابزار نشانه‌ای از آن پیدا نکرده است.

این بخش برای تفسیر بقیه‌ی گزارش به کار می‌آید. اگر TTFB بالاست و سرور در کشوری دور از بازدیدکننده‌هاست، بخشی از جواب همین‌جاست. اگر سایت وردپرسی است، می‌دانید ایرادهای TBT احتمالا از قالب و افزونه‌ها می‌آید. و اگر CDN هست ولی TTFB باز هم بالاست، احتمالا صفحه‌ها کش نمی‌شوند.

سئو تکنیکال، دسترس‌پذیری و شیوه‌های درست

سئو در گزارش دو بخش دارد. اول بررسی‌های پایه‌ی خود ابزار: عنوان و توضیح صفحه، تیتر اصلی (H1)، نشانی اصلی (canonical)، اجازه‌ی ایندکس، زبان صفحه، تنظیم موبایل (viewport)، پیش‌نمایش اشتراک‌گذاری در شبکه‌های اجتماعی (Open Graph)، داده‌ی ساختاریافته (Schema)، robots.txt، نقشه‌ی سایت و چند مورد دیگر. بعد بررسی‌های سئوی Lighthouse با امتیاز از ۱۰۰. امتیاز سئوی Lighthouse بیشتر می‌گوید گوگل می‌تواند صفحه را درست بخواند یا نه؛ امتیاز ۱۰۰ در این بخش یعنی ایراد فنی پایه‌ای نیست، نه اینکه سایت در گوگل اول است. محتوا، لینک‌ها و اعتبار سایت را هیچ گزارش خودکاری نمی‌سنجد. ولی ایرادهایی مثل noindex اشتباهی، robots.txt که کل سایت را بسته یا نبودن تیتر و عنوان، جدی هستند و باید فورا درست شوند.

دسترس‌پذیری یعنی اینکه سایت برای همه قابل استفاده باشد: کسی که با صفحه‌خوان کار می‌کند، کسی که چشمش ضعیف است، کسی که فقط با صفحه‌کلید کار می‌کند. طبق مستندات امتیاز دسترس‌پذیری Lighthouse، این امتیاز میانگین وزن‌دار بررسی‌های خودکار است و هر بررسی یا کامل قبول می‌شود یا رد؛ برخلاف بررسی‌های سرعت، قبول شدن نیمه‌کاره امتیازی ندارد. همان مستندات فهرست جداگانه‌ای از بررسی‌های دستی هم دارند. پس امتیاز ۱۰۰ دسترس‌پذیری یعنی ایراد خودکاری پیدا نشد، نه اینکه سایت برای همه بی‌نقص است. ایرادهای رایج: تضاد کم رنگ متن با زمینه، دکمه‌ها و لینک‌های بی‌نام و عکس‌های بدون متن جایگزین.

شیوه‌های درست چیزهایی مثل استفاده از HTTPS و نبود خطا در کنسول مرورگر را می‌سنجد؛ کمتر به چشم می‌آید، ولی نشان می‌دهد سایت چقدر تمیز ساخته شده است.

آمادگی سایت برای هوش مصنوعی

این بخش در گزارش‌های معمول سرعت نیست. سوالش ساده است: آیا ChatGPT، Claude و ایجنت‌های هوش مصنوعی دیگر می‌توانند وارد سایت شما شوند، آن را بخوانند و با آن کار کنند؟

بررسی‌ها همان ۲۲ بررسی ابزار isitagentready.com کلادفلر است، با همان قاعده‌ها. نتیجه دو عدد دارد. یکی سطح از ۵، با نام انگلیسی و فارسی‌اش، و یک جمله که می‌گوید برای رسیدن به سطح بعد چه چیزی کم است. دیگری امتیاز از ۱۰۰، که سهم بررسی‌های قبول‌شده است از بررسی‌هایی که به همین سایت مربوط بودند. کنار آن، سهم هر گروه آمده است: پیدا شدن، محتوا، اجازه‌ی ربات‌ها، و API و ورود و MCP. زیر هر گروه، فهرست بررسی‌ها با جزئیات و یک خط «چه کار کنید» آمده است.

دو بخش دیگر در امتیاز حساب نمی‌شوند. خرید توسط ایجنت فقط برای فروشگاه نشان داده می‌شود؛ اگر سایت فروشگاه به نظر نرسد، گزارش می‌نویسد پنج بررسی خرید به آن مربوط نیست. بررسی‌های خود ما هم جدا آمده‌اند، از جمله یک آزمایش واقعی: صفحه‌ی اصلی را با شناسه‌ی ایجنت‌ها درخواست می‌کنیم و می‌بینیم سایت جواب می‌دهد یا مسدود می‌کند. گاهی فایروال یا CDN بی‌آنکه صاحب سایت بداند همین ایجنت‌ها را می‌بندد. گزارش‌هایی که پیش از ۹ مهر ۱۴۰۵ گرفته شده‌اند، با همان گروه‌های قدیمی خودشان نشان داده می‌شوند.

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

اول چه چیزی را درست کنیم؟ ترتیب عملی در تفسیر گزارش PageSpeed

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

1. هر چیزی که سایت را از دسترس خارج می‌کند. گواهی منقضی یا نامعتبر، noindex اشتباهی روی صفحه‌ی اصلی، robots.txt که کل سایت را بسته است. این‌ها فوری‌اند، چون یا بازدیدکننده را با هشدار می‌ترسانند یا سایت را از گوگل بیرون نگه می‌دارند.
2. پاسخ سرور. اگر TTFB قرمز است، از اینجا شروع کنید. روی سرور کند، بهینه‌سازی صفحه فقط بخشی از مشکل را حل می‌کند. کش صفحه، به‌روز کردن نسخه‌ی PHP یا رفتن از هاست اشتراکی شلوغ به سرور اختصاصی معمولا همین‌جا اثر می‌کند.
3. LCP موبایل. عکس اصلی را سبک و هم‌اندازه‌ی نمایش کنید، بارگذاری تنبل را از رویش بردارید و فایل‌های مانع نمایش را کم کنید.
4. TBT. افزونه‌ها و اسکریپت‌های اضافه را حذف کنید، کدهای شخص ثالث را بازبینی کنید و جاوااسکریپت بی‌استفاده را کنار بگذارید.
5. CLS. به عکس‌ها و قاب‌ها اندازه بدهید و برای تبلیغ و بنر از قبل جا نگه دارید. معمولا سریع درست می‌شود.
6. پروتکل و فشرده‌سازی. HTTP/2 یا HTTP/3، Brotli و کش طولانی فایل‌های ثابت. بیشترشان تنظیم سرور هستند، نه تغییر سایت.
7. ایرادهای سئو، دسترس‌پذیری و هدرهای امنیتی. هر کدام جداگانه کار کمی می‌برد و با هم سایت را تمیز و قابل اعتماد می‌کنند.

یک قانون هم همیشه برقرار است: داخل هر بخش، ایرادهای بالای فهرست را اول درست کنید؛ همان‌هایی که بیشترین زمان را آزاد می‌کنند. بهینه‌سازی Core Web Vitals در عمل همین ترتیب است: سرور، بعد LCP، بعد TBT، بعد CLS.

بعد از درست کردن: دوباره تست کنید

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

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

اگر نمی‌خواهید خودتان درگیر شوید

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

• بهینه‌سازی سرعت سایت: وقتی امتیاز سرعت موبایل زیر ۹۰ است. ایرادهای بخش سرعت را یکی‌یکی درست می‌کنیم؛ ۱۰ میلیون تومان، با تحویل در ۷ روز.
• پیکربندی سرور وردپرس: وقتی سایت وردپرسی است. وردپرس را روی سرور خود شما، با پیکربندی مخصوص همان سایت، راه می‌اندازیم و منتقل می‌کنیم؛ ۱۵ میلیون تومان، با تحویل در ۳ روز.
• سئو تکنیکال: وقتی بخش سئو دو ایراد یا بیشتر دارد یا امتیاز سئو زیر ۹۰ است. ایرادهای فنی که جلوی دیده شدن در گوگل را گرفته‌اند؛ ۱۵ میلیون تومان، با تحویل در ۷ روز.
• آماده‌سازی سایت برای ایجنت‌های هوش مصنوعی: وقتی امتیاز آمادگی برای هوش مصنوعی زیر ۸۰ است. بررسی‌های ردشده را یکی‌یکی روی سایت پیاده می‌کنیم؛ ۱۰ میلیون تومان، با تحویل در ۷ روز.

همه‌ی این کارها ۷ روز پشتیبانی رایگان دارند و اگر عجله دارید، با دو برابر هزینه زودتر تحویل می‌شوند (مثلا سئو تکنیکال در ۲ روز). برای هر سوالی هم می‌توانید با ما تماس بگیرید.

پرسش‌های رایج

چرا عدد این گزارش با PageSpeed Insights گوگل فرق دارد؟

موتور یکی است، ولی جای تست نه. طبق راهنمای PageSpeed Insights، تست آزمایشگاهی PageSpeed در یکی از مراکز داده‌ی گوگل در آمریکای شمالی، اروپا یا آسیا اجرا می‌شود و گزارش ما از تهران. مسیر شبکه تا سرور سایت فرق می‌کند و عددها هم. علاوه بر این، امتیاز هر بار کمی نوسان دارد.

PageSpeed نوشته «Core Web Vitals Assessment: Failed»؛ این یعنی چه؟

آن ارزیابی از داده‌ی کاربران واقعی Chrome می‌آید، نه از تست آزمایشگاهی. همان راهنمای PageSpeed Insights می‌گوید این داده تجربه‌ی ۲۸ روز گذشته است و برای هر سنجه صدک ۷۵ را گزارش می‌کند. «رد شد» یعنی دست‌کم یکی از سه سنجه برای بخش بزرگی از بازدیدکننده‌ها در محدوده‌ی خوب نبوده است. گزارش ما آزمایشگاهی است و چنین ارزیابی‌ای ندارد؛ ولی LCP و CLS و TBT همین گزارش نشان می‌دهند مشکل احتمالا کجاست.

INP سایت من را از کجا ببینم؟

INP فقط از کاربران واقعی جمع می‌شود. اگر سایت‌تان بازدید کافی داشته باشد، PageSpeed Insights آن را بالای نتیجه‌اش نشان می‌دهد. گزارش Core Web Vitals در Search Console هم صفحه‌های سایت را به گروه‌های شبیه هم تقسیم می‌کند و برای هر گروه می‌گوید LCP، INP و CLS در ۲۸ روز گذشته خوب، نیازمند بهبود یا ضعیف بوده است. اگر آنجا «داده‌ای در دسترس نیست» دیدید، یعنی هنوز داده‌ی کافی از کاربران واقعی جمع نشده است. در تست آزمایشگاهی، TBT نزدیک‌ترین نشانه به INP است.

در تفسیر گزارش PageSpeed مهم‌ترین عدد کدام است؟

برای بیشتر سایت‌ها LCP موبایل، چون هم بیشترین اثر را روی حس بازدیدکننده دارد و هم جزو Core Web Vitals است. بعد از آن TBT، که بیشترین وزن را در امتیاز دارد.

امتیاز ۱۰۰ لازم است؟

نه. مستندات امتیازدهی Lighthouse می‌گوید امتیاز کامل ۱۰۰ بسیار سخت است و انتظارش نمی‌رود؛ بردن امتیاز از ۹۹ به ۱۰۰ تقریبا همان‌قدر بهبود می‌خواهد که بردنش از ۹۰ به ۹۴. هدف این است که سنجه‌ها در محدوده‌ی خوب باشند و سایت برای آدم‌ها سریع باشد. رسیدن از قرمز به سبز ارزش زیادی دارد؛ چند واحد آخر معمولا نه.

اگر تست ناموفق بود، یعنی چه؟

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

چرا فقط صفحه‌ی اصلی تست شده است؟

قاعده‌ی این ابزار است: هر نشانی‌ای نوشته شود، صفحه‌ی اصلی همان دامنه تست می‌شود. برای صفحه‌های داخلی می‌توانید از Lighthouse داخل Chrome یا PageSpeed Insights استفاده کنید؛ همین راهنما برای خواندن نتیجه‌ی آن‌ها هم کار می‌کند.