daroo.online

تفسیر گزارش 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. پس به عدد کلی خیره نشوید؛ ببینید کدام سنجه قرمز است. کنار هر سنجه در گزارش ما همان نقطه‌ی رنگی و شکل هست. در یک نگاه معلوم است کدام عدد امتیاز را پایین کشیده است.

دو نکته را هم بدانید. اول، امتیاز از یک تست تا تست بعد چند واحد بالا و پایین می‌شود. مستندات 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 را فقط کلیک آدم‌های واقعی می‌سازد. در تست آزمایشگاهی کسی روی صفحه نمی‌زند، پس 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 و ایجنت‌های هوش مصنوعی دیگر می‌توانند وارد سایت شما شوند، آن را بخوانند و با آن کار کنند؟

نتیجه‌ی این بخش دو عدد دارد. اولی سطح از ۵ است، با نام انگلیسی و فارسی‌اش، و یک جمله که می‌گوید برای رسیدن به سطح بعد چه چیزی کم است. دومی امتیاز از ۱۰۰ است. یعنی از بررسی‌هایی که به همین سایت مربوط بودند، چه سهمی قبول شده است. کنار آن، سهم هر گروه آمده است: پیدا شدن، محتوا، اجازه‌ی ربات‌ها، و 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 می‌گوید امتیاز کامل ۱۰۰ بسیار سخت است و انتظارش نمی‌رود. بردن امتیاز از ۹۹ به ۱۰۰ تقریبا همان‌قدر بهبود می‌خواهد که بردنش از ۹۰ به ۹۴. هدف این است که سنجه‌ها در محدوده‌ی خوب باشند و سایت برای آدم‌ها سریع باشد. رسیدن از قرمز به سبز ارزش زیادی دارد؛ چند واحد آخر معمولا نه.

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

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