بهینه‌سازی سرعت بارگذاری صفحه

۰۱اول اندازه بگیرید

دو نوع داده دارید و هر دو لازم‌اند. داده‌ی آزمایشگاهی (Lighthouse، PageSpeed Insights) در شرایط کنترل‌شده تکرارپذیر است و برای عیب‌یابی عالی است. داده‌ی میدانی (گزارش Core Web Vitals در Search Console) تجربه‌ی واقعی کاربران روی گوشی‌ها و شبکه‌های ضعیف را نشان می‌دهد و همان چیزی است که گوگل در نظر می‌گیرد.

سه شاخص را زیر نظر بگیرید: LCP برای سرعت دیده‌شدن محتوای اصلی، INP برای پاسخ‌گویی و CLS برای ثبات چیدمان. توضیح کامل‌شان در راهنمای Core Web Vitals است. برای شروع، تب Network در DevTools را روی «Slow 4G» و CPU را روی کند بگذارید و صفحه را بارگذاری کنید؛ سه بزرگ‌ترین درخواست‌ها معمولاً نصف مشکل را لو می‌دهند.

۰۲تصویرها: بزرگ‌ترین و ساده‌ترین برد

سه کار کافی است: اندازه‌ی واقعی نمایش را بسازید (تصویر ۴۰۰۰ پیکسلی برای کادر ۴۰۰ پیکسلی هدر دادن است)، فرمت مدرن مثل WebP یا AVIF بدهید، و تصویرهای پایین صفحه را تنبل (lazy) بارگذاری کنید. تصویر اصلی بالای صفحه را هرگز lazy نکنید؛ برعکس به آن اولویت بدهید.

<!-- Hero image: high priority, explicit size to avoid layout shift -->
<img src="hero-800.webp" alt="Team at work"
     srcset="hero-480.webp 480w, hero-800.webp 800w, hero-1200.webp 1200w"
     sizes="(max-width: 700px) 100vw, 800px"
     width="800" height="450" fetchpriority="high">

<!-- Below the fold -->
<img src="card.webp" alt="Project card" width="400" height="300"
     loading="lazy" decoding="async">

ویژگی‌های width و height به مرورگر اجازه می‌دهند جای تصویر را از قبل رزرو کند و از پرش چیدمان جلوگیری کنید. جزئیات این ویژگی‌ها در مستندات عملکرد MDN آمده است.

۰۳جاوااسکریپت: کمتر بفرستید، دیرتر اجرا کنید

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

• حذف: با گزارش bundle analyzer ببینید کدام کتابخانه‌ها سنگین‌اند. اغلب یک کتابخانه‌ی تاریخ یا ابزارک بزرگ برای یک تابع کوچک وارد شده است.
• تقسیم: کدی که در بارگذاری اولیه لازم نیست را با import() پویا بارگذاری کنید.
• تأخیر: اسکریپت‌های غیرحیاتی را با defer یا async بارگذاری کنید تا رندر را مسدود نکنند.

// Load the heavy chart library only when the user opens the tab
const btn = document.querySelector('#show-chart');
btn.addEventListener('click', async () => {
  const { renderChart } = await import('./chart.js');
  renderChart(document.querySelector('#chart'));
}, { once: true });

اگر از ریکت و نکست استفاده می‌کنید، کامپوننت‌های سروری حجم جاوااسکریپت ارسالی را به‌طور محسوس کم می‌کنند؛ به ویژگی‌های Next.js 13 سر بزنید.

۰۴CSS و فونت‌ها

CSS مسدودکننده‌ی رندر است، پس حجمش مهم است. استایل‌های بحرانی بالای صفحه را می‌توان درون خود HTML گذاشت و بقیه را بعداً بارگذاری کرد، ولی برای بیشتر سایت‌های کوچک، یک فایل CSS فشرده‌ی کم‌حجم و کش‌شده کافی و ساده‌تر است.

فونت‌ها دو خطر دارند: متن نامرئی تا رسیدن فایل و پرش چیدمان هنگام جایگزینی. راه‌حل‌ها ساده‌اند: فقط وزن‌ها و زیرمجموعه‌ی حروف لازم را بارگذاری کنید، فرمت woff2 بدهید و font-display را تنظیم کنید. برای فونت‌های فارسی که معمولاً سنگین‌ترند، این‌ها اهمیت بیشتری دارند.

@font-face {
  font-family: "Vazirmatn";
  src: url("/fonts/vazirmatn-var.woff2") format("woff2");
  font-weight: 100 900;
  font-display: swap;
}

<link rel="preload" href="/fonts/vazirmatn-var.woff2" as="font" type="font/woff2" crossorigin>

۰۵کش، فشرده‌سازی و CDN

بازدیدکننده‌ی دوم نباید همه‌چیز را دوباره دانلود کند. فایل‌هایی که نام‌شان با هر تغییر عوض می‌شود (مثل app.3f9a1c.js) را برای مدت طولانی و immutable کش کنید، و HTML را با عمر کوتاه یا اعتبارسنجی مجدد. فشرده‌سازی Brotli یا gzip هم متن‌ها را معمولاً به‌شدت کوچک می‌کند.

# nginx: long cache for hashed assets, compression on
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;

location ~* \.(?:js|css|woff2|webp|avif)$ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}

CDN فاصله‌ی فیزیکی تا کاربر را کم می‌کند و برای مخاطب پراکنده یا فایل‌های سنگین بیشترین فایده را دارد. اگر سرور و کش API هم جزو گلوگاه شما هستند، کش‌کردن با Redis را ببینید.

۰۶اولویت‌بندی و چک‌لیست نهایی

همه‌ی کارها یک اندازه اثر ندارند. جدول زیر ترتیب پیشنهادی ما را بر اساس «اثر در برابر زحمت» نشان می‌دهد؛ اعداد دقیق به پروژه‌ی شما بستگی دارند، ولی ترتیب معمولاً همین است.

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