team.sefid.dev

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

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

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

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

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

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

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

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

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

Core Web Vitals به زبان ساده: LCP، INP و CLS

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

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

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

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

CLS: صفحه چقدر می‌پرد؟

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

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

INP و TBT: صفحه به لمس جواب می‌دهد؟

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

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

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

اگر سایت شما بازدید کافی داشته باشد، PageSpeed Insights گوگل بالای نتیجه‌اش داده‌ی کاربران واقعی Chrome را هم نشان می‌دهد، از جمله INP واقعی. طبق راهنمای PageSpeed Insights این داده مربوط به ۲۸ روز گذشته و صدک ۷۵ است. گزارش تیم سفید آزمایشگاهی است و چنین داده‌ای ندارد؛ این دو مکمل هم هستند، نه جایگزین هم.

FCP، Speed Index و پاسخ سرور (TTFB)

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

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

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

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

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

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

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

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

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

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

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

گواهی SSL همان چیزی است که نشانی سایت را از http به https می‌برد و اطلاعاتی را که بین بازدیدکننده و سایت رد و بدل می‌شود رمز می‌کند. سایتی که گواهی ندارد یا گواهی‌اش مشکل دارد، در مرورگر با هشدار «ناامن» دیده می‌شود.

امتیاز SSL در گزارش ما یک بررسی جداگانه است و این‌طور کار می‌کند: از ۱۰۰ شروع می‌شود؛ ایرادهای جدی مثل گواهی منقضی‌شده، گواهی‌ای که برای این دامنه صادر نشده، گواهی خودامضا یا زنجیره‌ی ناقص سقف امتیاز را پایین می‌آورند؛ و ایرادهای کوچک‌تر چند امتیاز کم می‌کنند: نزدیک بودن پایان اعتبار، روشن ماندن نسخه‌های قدیمی و ناامن TLS 1.0 و 1.1، و پشتیبانی نشدن TLS 1.3 که سریع‌ترین و امن‌ترین نسخه است. کنار امتیاز، صادرکننده و تعداد روزهای مانده تا پایان اعتبار هم آمده است. اگر این عدد کم است، تمدید خودکار گواهی را وارسی کنید.

زیر SSL، شش هدر امنیتی فهرست شده‌اند: HSTS، Content-Security-Policy، X-Content-Type-Options، X-Frame-Options، Referrer-Policy و Permissions-Policy. هدر یعنی پیام کوتاهی که سرور همراه صفحه به مرورگر می‌فرستد. این‌ها روی سرعت اثری ندارند، ولی جلوی حمله‌هایی مثل اجرای کد تزریق‌شده یا نمایش سایت شما داخل قاب یک سایت دیگر را می‌گیرند.

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

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

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

چند ردیف دیگر این بخش:

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

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

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

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

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

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

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

بررسی‌ها همان‌هایی است که ابزار isitagentready کلادفلر انجام می‌دهد، در پنج گروه: اجازه‌ی ورود (قانون ربات‌های هوش مصنوعی در robots.txt و اعلام اجازه‌ی استفاده از محتوا)، پیدا شدن (robots.txt، نقشه‌ی سایت، فایل llms.txt)، محتوا (اینکه سایت به ایجنت نسخه‌ی Markdown سبک‌تر می‌دهد یا نه)، پروتکل‌ها (مثل کارت سرور MCP) و خرید توسط ایجنت که فقط نشان داده می‌شود و در امتیاز حساب نمی‌شود. کنارش یک آزمایش واقعی هم هست که بیشترین وزن را دارد: صفحه‌ی اصلی را با شناسه‌ی ایجنت‌های ChatGPT و Claude درخواست می‌کنیم و می‌بینیم سایت جواب می‌دهد یا صفحه‌ی چالش و مسدودی نشان می‌دهد. گاهی فایروال یا CDN بی‌آنکه صاحب سایت بداند همین ایجنت‌ها را می‌بندد.

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

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

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

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

یک قانون هم همیشه برقرار است: داخل هر بخش، ایرادهای بالای فهرست را اول درست کنید؛ همان‌هایی که بیشترین زمان را آزاد می‌کنند.

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

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

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

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

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

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

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

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

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

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

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

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

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

INP فقط از کاربران واقعی جمع می‌شود. اگر سایتتان بازدید کافی داشته باشد، PageSpeed Insights و گزارش Core Web Vitals در Search Console آن را نشان می‌دهند. در تست آزمایشگاهی، TBT نزدیک‌ترین نشانه به آن است.

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

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

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

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