دیدن عدد پایین زیر «Performance» در گزارش PageSpeed Insights برای خیلی از صاحبان سایت ناامیدکننده است، به‌خصوص وقتی سایت از نظر ظاهری کاملاً روان به نظر می‌رسد. واقعیت این است که این امتیاز از یک فرمول وزن‌دار محاسبه می‌شود، نه یک حس کلی از سرعت. در این مقاله قدم‌به‌قدم نشان می‌دهیم امتیاز موتور تحلیل چطور محاسبه می‌شود و برای رسیدن به عدد ۹۰ به بالا (و در نهایت ۱۰۰) دقیقاً روی چه مواردی باید تمرکز کنید.

امتیاز Performance از کجا می‌آید؟

برخلاف تصور رایج، امتیاز Performance یک عدد ساده نیست؛ ترکیبی وزن‌دار از شش معیار است که هرکدام سهم متفاوتی در امتیاز نهایی دارند:

• LCP (۲۵٪): زمان نمایش بزرگ‌ترین عنصر صفحه
• TBT (۳۰٪): Total Blocking Time، مجموع زمانی که thread اصلی مرورگر مسدود بوده
• CLS (۲۵٪): میزان جابه‌جایی عناصر
• FCP (۱۰٪): اولین رنگی که روی صفحه دیده می‌شود
• Speed Index (۱۰٪): سرعت پر شدن بصری صفحه

همان‌طور که می‌بینید، TBT و LCP بیشترین سهم را دارند؛ یعنی اگر بخواهید با کمترین تلاش بیشترین بهبود امتیاز را بگیرید، باید اول سراغ این دو بروید.

گام ۱: LCP را کوتاه کنید

عنصر LCP معمولاً یک تصویر بزرگ یا بلوک متنی هدر است. سه اقدام زیر بیشترین تاثیر را دارند:

• از <link rel="preload"> برای تصویر اصلی هدر استفاده کنید تا مرورگر زودتر از موعد شروع به دانلود آن کند.
• فونت‌های وب را با font-display: swap بارگذاری کنید تا رندر متن منتظر دانلود فونت نماند.
• CSS بحرانی (critical CSS) بالای صفحه را inline کنید و بقیه‌ی CSS را غیرمسدودکننده بارگذاری کنید.

گام ۲: TBT را کاهش دهید

TBT زمانی بالا می‌رود که جاوااسکریپت سنگین thread اصلی مرورگر را برای بیش از ۵۰ میلی‌ثانیه قفل کند. راهکارها:

• Code splitting: فقط جاوااسکریپتی را بارگذاری کنید که همان صفحه به آن نیاز دارد.
• Defer/async: اسکریپت‌های غیرضروری برای رندر اولیه را با defer بارگذاری کنید.
• حذف کتابخانه‌های سنگین: jQuery کامل یا کتابخانه‌های آنالیتیکس اضافی را با جایگزین‌های سبک‌تر عوض کنید.
• اسکریپت‌های شخص‌ثالث (تبلیغات، ویجت چت، آنالیتیکس) را با async یا با تاخیر بعد از تعامل اول کاربر بارگذاری کنید.

اگر فقط یک کار می‌توانید انجام دهید، جاوااسکریپت غیرضروری شخص‌ثالث را پیدا و حذف کنید — در اکثر سایت‌ها این تنها اقدام، ده‌ها امتیاز TBT را کاهش می‌دهد.

گام ۳: CLS را صفر کنید

همان‌طور که در مقاله Core Web Vitals توضیح دادیم، همیشه ابعاد تصاویر، ویدیوها و فضای تبلیغات را از قبل رزرو کنید. یک نکته‌ی کمتر شناخته‌شده: فونت‌های وب هم می‌توانند CLS ایجاد کنند (وقتی فونت fallback با فونت نهایی اندازه‌ی متفاوتی دارد) — با size-adjust در @font-face می‌توانید این تفاوت را جبران کنید.

گام ۴: تصاویر و فونت‌ها را فشرده کنید

موتور تحلیل چند Audit مشخص برای این بخش دارد: «Properly size images»، «Serve images in next-gen formats» و «Efficiently encode images». همه‌ی این‌ها با تبدیل تصاویر به WebP/AVIF و آپلود در ابعاد واقعی نمایش (نه ابعاد اصلی دوربین) برطرف می‌شوند. برای جزئیات کامل‌تر این بخش، راهنمای بهینه‌سازی تصاویر را ببینید.

گام ۶: کش مرورگر و فشرده‌سازی متنی را فعال کنید

دو Audit دیگر که معمولاً امتیاز را پایین می‌آورند «Serve static assets with an efficient cache policy» و «Enable text compression» هستند. مورد اول یعنی فایل‌های استاتیک (CSS، JS، فونت، تصاویر) باید هدر Cache-Control با عمر طولانی داشته باشند تا در بازدید دوم دوباره دانلود نشوند؛ مورد دوم یعنی سرور باید پاسخ‌های متنی را با Gzip یا Brotli فشرده کند. اکثر هاست‌های مدرن این دو مورد را به‌صورت پیش‌فرض فعال دارند، اما ارزش دارد با ابزارهایی مثل DevTools مرورگر (تب Network) بررسی کنید هدر content-encoding واقعاً برای فایل‌های سایت شما فعال است یا نه.

اشتباهات رایجی که امتیاز را پایین نگه می‌دارند

حتی بعد از انجام همه‌ی مراحل بالا، بعضی اشتباهات ساده می‌توانند امتیاز را قفل کنند:

• تست روی محیط دولوپمنت: امتیاز محیط dev (بدون minify، بدون کش، با source map) با production یکی نیست؛ همیشه نسخه‌ی نهایی deploy‌شده را تست کنید.
• پلاگین‌ها و ویجت‌های اضافه‌شده بعداً: یک ویجت چت آنلاین یا پاپ‌آپ خبرنامه که بعد از بهینه‌سازی اولیه اضافه می‌شود، می‌تواند به‌تنهایی ده‌ها امتیاز TBT از بین ببرد.
• فونت‌های آیکون سنگین: بارگذاری کل یک فونت آیکون (مثل Font Awesome کامل) فقط برای سه چهار آیکون، هم حجم و هم CLS اضافه می‌کند؛ به‌جای آن از SVG inline استفاده کنید.
• عدم تست روی شبکه‌ی موبایل واقعی: موتور تحلیل به‌صورت پیش‌فرض یک شبکه‌ی موبایل کند را شبیه‌سازی می‌کند؛ چیزی که روی وای‌فای سریع دفتر شما «سریع» به‌نظر می‌رسد، ممکن است برای کاربر موبایل واقعی کند باشد.

به Audit های امنیتی و Best Practices هم توجه کنید

گاهی امتیاز پایین ربطی به کارایی ندارد؛ نبود HTTPS، کنسول پر از خطای جاوااسکریپت یا نبود ویژگی‌های دسترس‌پذیری (accessibility) هم می‌توانند در گزارش کلی PageSpeed دیده شوند، حتی اگر مستقیماً روی عدد Performance اثر نگذارند.

چطور پیشرفت را دنبال کنیم؟

بعد از هر تغییر، دوباره تست بگیرید — اما نه فقط یک‌بار. امتیاز موتور تحلیل به‌خاطر تغییرات شبکه و بار سرور کمی نوسان دارد، پس بهتر است ۲ تا ۳ بار تست کنید و میانگین بگیرید. با تست سرعت SpeedScan می‌توانید تاریخچه‌ی امتیازها را نگه دارید و روند بهبود را در طول زمان ببینید، نه فقط یک عدد لحظه‌ای.