راهنمای افزایش سرعت سایت و بهینه‌ سازی Core Web Vitals در سال ۲۰۲۶

چرا سرعت سایت در سئوی مدرن یک فاکتور مرگ و زندگی است؟

رفتار کاربران وب طی سال های اخیر دستخوش تحول بزرگی شده است. تحقیقات متوالی تیم توسعه وب کروم نشان می دهد که با افزایش زمان لود صفحه از ۱ ثانیه به ۳ ثانیه، احتمال پرش کاربر (Bounce Rate) بیش از ۳۲ درصد افزایش می یابد. اگر این تاخیر به ۵ ثانیه برسد، احتمال ترک صفحه تا ۹۰ درصد اوج می گیرد. در بازار وب فارسی، با توجه به تنوع سخت افزاری دستگاه های کاربران و ناپایداری های مقطعی شبکه اینترنت، هر میلی ثانیه بهینه سازی در سطح کد و سرور تفاوت میان یک فروش موفق یا از دست رفتن کامل مشتری بالقوه است.

از منظر معماری جستجو، موتورهای جستجو ربات های خزشگر خود را بر اساس محدوده ای مشخص به نام بودجه خزش به سایت شما می فرستند. زمانی که کدهای صفحه غیربهینه بوده و TTFB سرور بالا باشد، فرآیند خزش به شدت کند شده و در نتیجه ایندکس صفحات جدید یا آپدیت مقالات ماه ها به تعویق می افتد. برای درک عمیق تر سازوکار ربات های خزنده، بررسی مدیریت بودجه خزش (Crawl Budget) مکمل این بخش خواهد بود.

تفاوت بنیادین داده های آزمایشگاهی (Lab Data) و داده های میدانی (Field Data / CrUX)

بزرگ ترین خطایی که سئوکاران و توسعه دهندگان مرتکب می شوند، اکتفا کردن به امتیاز ۱۰۰ در تب آزمایشگاهی ابزار Lighthouse است. گوگل برای رتبه بندی نتایج در کنسول سرچ، به نتایج تست مصنوعی رایانه شما اتکا نمی کند؛ مبنای ارزیابی موتور جستجو Chrome UX Report (CrUX) است.

• داده های آزمایشگاهی (Lab Data): شرایط شبیه سازی شده در یک شبکه و سخت افزار ثابت هستند. این داده ها برای فرآیند دیباگ حین کدنویسی در محیط استیجینگ عالی اند، اما بازتاب دهنده واقعیت تعامل کاربران گوناگون نیستند.
• داده های میدانی (Field Data): داده هایی هستند که از هزاران کاربر واقعی در سراسر وب با ابعاد نمایشگر متفاوت، پردازنده های ضعیف و اتصالات شبکه متنوع در بازه ۲۸ روز گذشته جمع آوری می شوند. گوگل ارزیابی موفقیت سایت را در صدک ۷۵ (75th Percentile) کاربران واقعی می سنجد. یعنی حداقل ۷۵ درصد از تمامی جلسات (Sessions) ورودی باید در محدوده مجاز و استاندارد قرار داشته باشند.

جدول آستانه ها و شاخص های رسمی هسته حیاتی وب (Core Web Vitals)

از مارس ۲۰۲۴ و تداوم استانداردهای آن در سال ۲۰۲۶، شاخص قدیمی FID به طور دائم منسوخ شده و معیار مدرن و سخت گیرانه INP جایگزین آن گردیده است. جدول زیر مقادیر استاندارد و تفکیک وضعیت هر شاخص را نشان می دهد:

کالبدشکافی شاخص LCP؛ ۴ بخش پنهان که رقبا از آن غافل اند

شاخص LCP فقط یک تایمر کلی نیست. برای رساندن LCP به زیر ۲.۵ ثانیه، باید آن را به ۴ زیرمؤلفه مستقل تفکیک کنید. در یک سایت استاندارد، نسبت بهینه این بخش ها به صورت زیر توزیع می شود:

1. Time to First Byte (TTFB) – سهم بهینه ~۴۰٪: مدت زمانی که طول می کشد تا مرورگر کاربر اولین بایت HTML را پس از ارسال درخواست از سرور شما دریافت کند. اگر TTFB سرور شما بالای ۸۰۰ میلی ثانیه باشد، دستیابی به LCP سبز تقریبا غیرممکن خواهد بود.
2. Resource Load Delay (تاخیر شروع دانلود منبع) – سهم بهینه کمتر از ۱۰٪: فاصله زمانی بین رسیدن سند HTML تا زمانی که مرورگر شروع به دانلود منبع LCP (مثل عکس بنر یا فایل فونت اصلی) می کند. اگر عکس هیرو درون فایل CSS با دستور `background-image` فراخوانی شود یا در انتهای صفحه قرار داشته باشد، این تاخیر افزایش می یابد.
3. Resource Load Duration (زمان دانلود فایل منبع) – سهم بهینه ~۴۰٪: مدت زمان لازم برای دریافت کامل بایت های فایل تصویر یا فونت LCP بر بستر شبکه کاربر که مستقیما به فشرده سازی و فرمت عکس مربوط است.
4. Element Render Delay (تاخیر در رندر المان) – سهم بهینه کمتر از ۱۰٪: زمانی که فایل عکس دریافت شده اما کدهای جاوا اسکریپت طولانی یا کدهای CSS مسدودکننده در ترد اصلی (Main Thread)، مانع از نقاشی (Paint) آن روی نمایشگر می شوند.

برای پیاده سازی زیرساخت های کدنویسی اصولی در سطوح فنی، استفاده از اصول سئو تکنیکال (Technical SEO) مسیر شفافی پیش روی شما می گذارد.

بهینه سازی عملی شاخص LCP؛ عبور از مرز ۲.۵ ثانیه

بزرگ ترین چالش توسعه دهندگان و متخصصان سئو در گزارش های کروم، بهبود شاخص LCP است. بر اساس آمارهای رسمی، بیش از ۴۰ درصد وب سایت ها در رسیدن به حد نصاب استاندارد این شاخص ناموفق هستند. همان طور که در بخش پیشین دیدیم، عنصر LCP معمولا یک تصویر بنر بزرگ (Hero Image)، یک ویدیو با تصویر پوستر شاخص، یا یک بلوک متنی سرتیتر H1 به همراه فونت اختصاصی است. برای کاهش زمان بارگذاری این عنصر، باید چهار مرحله فنی زیر را به صورت هم زمان پیاده سازی کنید.

۱. کشف زودهنگام منبع با پیش بارگذاری (Preload) و ویژگی مدرن fetchpriority

یکی از مخرب ترین خطاهای طراحی وب، تعریف عکس بنر اصلی درون فایل های استایل خارجی با دستور background-image است. در این حالت، مرورگر ابتدا باید سند HTML را بخواند، فایل CSS خارجی را دانلود و تجزیه کند و تازه پس از ساخت درخت رندر (Render Tree) متوجه شود که باید تصویر بنر را دانلود نماید. این چرخه، تاخیر بارگذاری منبع (Resource Load Delay) را به شدت بالا می برد.

تصویر شاخص بالای صفحه حتما باید در تگ استاندارد img درون بدنه HTML قرار گیرد. علاوه بر آن، با قرار دادن یک تگ پیوند پیش بارگذاری در بخش head صفحه و اضافه کردن صفت fetchpriority=”high”، به مرورگر اعلام می کنید که دانلود این فایل بالاترین اولویت شبکه را دارد:

۲. خطای نابخشودنی Lazy Loading روی تصاویر بالای صفحه (Above the Fold)

بارگذاری تنبل یا Lazy Load یک تکنیک فوق العاده برای صرفه جویی در پهنای باند است؛ اما استفاده ناآگاهانه از آن روی نخستین تصویری که کاربر بدون اسکرول کردن مشاهده می کند، فاجعه ای برای سئو و شاخص LCP به همراه دارد. وقتی به عکس هیرو ویژگی loading=”lazy” می دهید، موتور رندر مرورگر دانلود آن را به تعویق می اندازد تا مطمئن شود تصویر در دید کاربر قرار گرفته است؛ همین اقدام ساده می تواند تا ۱.۵ ثانیه زمان LCP شما را هدر دهد.

قانون طلایی: اولین تصویر بالای تا (Hero Element) هرگز نباید تنبل لود شود. برای این تصویر باید اولویت بالا تعیین شده و دستور لود تنبل صرفا برای تصاویری که زیر خط تا قرار دارند رزرو گردد:

۳. حذف منابع مسدودکننده رندر (Render-Blocking Resources)

مرورگر تا زمانی که فایل های CSS موجود در تگ head را دانلود و پردازش نکند، فرآیند رسم محتوا روی صفحه را متوقف می کند. فایل های جاوا اسکریپت همگام نیز مانع از پیشروی تجزیه کننده HTML (DOM Parser) می شوند. برای باز کردن این گلوگاه ها باید استراتژی استایل های حیاتی (Critical CSS) و بارگذاری غیرهمگام اسکریپت ها را اعمال کنید.

• استخراج Critical CSS: کدهای استایلی که برای رندر اولیه بخش بالای صفحه نیاز است را استخراج کرده و به صورت مستقیم (Inline) درون تگ
  
• بارگذاری غیرهمگام استایل های حجیم باقی مانده: فایل CSS اصلی سایت را با استفاده از ویژگی media=”print” و تغییر آن در رویداد onload به صورت پس زمینه لود کنید:

• مدیریت اسکریپت ها با صفت های defer یا async: تمام کدهای جاوا اسکریپتی که ارتباطی به نقاشی اولیه صفحه ندارند، به ویژه کدهای ردیابی، آمارگیرها و کتابخانه های جانبی باید با صفت defer نشانه گذاری شوند تا اجرای آن ها تا پایان پردازش ساختار HTML به تعویق بیفتد.

۴. فرمت های تصویر نسل جدید و کاهش نرخ انتقال داده

استفاده از فرمت های قدیمی نظیر PNG و JPG برای تصاویر بزرگ وب سایت پذیرفتنی نیست. فرمت های مدرن مانند WebP و به خصوص AVIF میزان فشرده سازی فوق العاده ای با حفظ شفافیت تصویر ارائه می دهند. استفاده از تگ استاندارد picture امکان ارائه نسخه بهینه به مرورگرهای پیشرفته و حفظ نسخه پشتیبان برای مرورگرهای قدیمی تر را فراهم می سازد:

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

مهار شاخص INP؛ هنر روان سازی تعاملات کاربر در جاوا اسکریپت

شاخص Interaction to Next Paint (INP) جانشین سخت گیرانه معیار قدیمی FID است. در حالی که FID تنها نخستین کلیک کاربر را می سنجید، INP تمامی تعاملات صفحه نظیر کلیک روی دکمه ها، باز کردن منوهای کشویی، تایپ در فیلدهای جستجو و تب های متنی را در طول کل زمان حضور کاربر رصد می کند. بدترین تاخیر در پاسخ دهی به عنوان نمره نهایی ثبت می شود و هدف شما حفظ این عدد زیر ۲۰۰ میلی ثانیه است.

هر تعامل کاربر به سه فاز زمانی تقسیم می شود: تاخیر ورودی (Input Delay)، مدت زمان پردازش کد جاوا اسکریپت (Processing Duration)، و تاخیر نقاشی پاسخ روی نمایشگر (Presentation Delay). اصلی ترین دلیل بالا رفتن INP، قفل شدن رشته اصلی پردازش (Main Thread) با کارهای طولانی یا به اصطلاح Long Tasks (فرایندهایی با زمان اجرای بیش از ۵۰ میلی ثانیه) است.

۱. شکستن کارهای سنگین با متد مدرن scheduler.yield()

اگر تابعی دارید که پردازش های محاسباتی سنگین، آرایه های طولانی یا تغییرات متوالی در DOM انجام می دهد، مرورگر در حین اجرای آن کاملا منجمد می شود. با استفاده از متد نوین scheduler.yield() یا تکنیک سنتی جایگزین بر پایه setTimeout، می توانید اجرای تابع را در فواصل مشخص متوقف کنید تا رشته اصلی فرصت دریافت ورودی های لمسی یا کلیک های کاربر را پیدا کند:

// تابع کمکی برای تسلیم کردن ترد اصلی به رخدادهای کاربر
async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

// نمونه شکستن حلقه های پردازشی سنگین
async function processLargeBatchOfItems(items) {
  for (let i = 0; i < items.length; i++) {
    // انجام پردازش روی المان
    handleComplexCalculations(items[i]);
    
    // بعد از هر ۵۰ آیتم، رشته اصلی آزاد می شود
    if (i % 50 === 0) {
      await yieldToMain();
    }
  }
}

۲. جلوگیری از چالش بازترسیم اجباری (Forced Reflow / Layout Thrashing)

یکی از بزرگ ترین اشتباهات در توسعه فرانت اند، ترکیب ناآگاهانه خواندن و نوشتن ویژگی های هندسی صفحات است. اگر در یک حلقه ابتدا اندازه یک عنصر را از مرورگر استعلام بگیرید (مانند offsetHeight) و بلافاصله استایل المان دیگر را ویرایش کنید، موتور رندر را مجبور به محاسبه مجدد کل صفحه می کنید. همیشه تمام مقادیر خواندنی را ابتدا در متغیرها ذخیره کنید و سپس تمام تغییرات استایل را در قالب یک فاز گروهی اعمال نمایید.

به صفر رساندن شاخص CLS؛ ثبات کامل چیدمان بصری صفحه

هیچ تجربه ای آزاردهنده تر از این نیست که کاربر آماده کلیک روی یک دکمه باشد، اما ناگهان با باز شدن یک بنر تبلیغاتی یا دانلود دیر هنگام یک تصویر، المان جابجا شده و روی یک پیوند ناخواسته کلیک شود. شاخص Cumulative Layout Shift (CLS) این جابجایی های ناگهانی را اندازه گیری می کند. برای سبز نگه داشتن CLS زیر ۰.۱، باید استراتژی های هندسی زیر را روی کدهای قالب اعمال کنید.

۱. رزرو همیشگی ابعاد در تگ های چندرسانه ای و CSS Aspect-Ratio

مرورگر تا قبل از بارگذاری بایت های یک تصویر، ابعاد دقیق آن را نمی داند و در ابتدا فضایی با ارتفاع صفر در نظر می گیرد؛ پس از لود شدن، المان ها با پرش ناگهانی به پایین پرتاب می شوند. برای تمامی تگ های img، ویدیویی و آی فریم ها باید صفت های عرض (width) و ارتفاع (height) صریح ذکر شوند. همچنین با ویژگی مدرن aspect-ratio در کدهای CSS، مرورگر پیش از دانلود منبع فضای دقیق را رزرو می کند:

/* رزرو کادر تصویر حتی قبل از دریافت بایت های عکس */
.article-featured-image {
  width: 100%;
  height: auto;
  aspect-ratio: 16 / 9;
  background-color: #e2e8f0; /* نمایش یک لایه پیش نمایش مات تا زمان لود کامل */
}

۲. مدیریت رزرو فضا برای بلوک های پویا و تبلیغات

جایگاه های بنرهای اطلاع رسانی، تبلیغات، یا المان های مشروط که به صورت ناهمگام در صفحه تزریق می شوند، عامل اصلی جهش های بصری هستند. کانتینر در بر گیرنده این المان ها باید در استایل های اولیه دارای min-height مشخصی باشد تا با رسیدن دیتای سرور، صفحه دچار کشش یا انقباض نشود.

۳. مهار پرش های ناشی از وب فونت ها (FOIT و FOUT)

هنگامی که فونت اختصاصی فارسی دانلود می شود، اگر ساختار متنی با فونت پیش فرض سیستم عامل هم خوانی نداشته باشد، جایگزینی فونت موجب جا به جایی پاراگراف ها می گردد. با استفاده از font-display: swap در تگ @font-face و تنظیم صفت های size-adjust، ascent-override و descent-override می توانید فونت موقت سیستمی را به طور دقیق با ابعاد فونت وب منطبق کنید تا پس از اعمال فونت نهایی، کوچک ترین تغییری در خطوط متن رخ ندهد:

@font-face {
  font-family: 'CustomFontFallback';
  src: local('Tahoma');
  ascent-override: 95%;
  descent-override: 20%;
  size-adjust: 100%;
}

@font-face {
  font-family: 'MyCustomFont';
  src: url('/fonts/vazir.woff2') format('woff2');
  font-display: swap;
}

رعایت این جزییات فنی از مبانی غیر قابل انکار در بهینه سازی وب سایت است. پس از پیاده سازی استانداردهای پرفورمنس، گام طبیعی و هوشمندانه بعدی برای بالا کشیدن رتبه صفحات در رقابت های فشرده، اجرای دقیق اصول لینک سازی در سال ۲۰۲۶ بر روی بستری سریع و کاملا بهینه خواهد بود.

بهینه سازی زیرساخت سرور و بک اند؛ کاهش زمان تا اولین بایت (TTFB)

هر چقدر هم که در بخش فرانت اند و کدهای مرورگر ظریف عمل کنید، اگر پاسخ اولیه سرور شما با تاخیر چند ثانیه ای ارسال شود، هیچ شانسی برای دریافت نمره قبولی در Core Web Vitals نخواهید داشت. بر اساس راهنماهای رسمی گوگل، زمان تا دریافت اولین بایت یا Time to First Byte (TTFB) باید زیر ۸۰۰ میلی ثانیه و در حالت ایده آل کمتر از ۲۰۰ میلی ثانیه باشد. در زیرساخت های وب، این شاخص نشان دهنده کیفیت سخت افزار، معماری پایگاه داده و سرعت مفسر کدهای سمت سرور شما است.

۱. ارتقای پروتکل شبکه به HTTP/3 و QUIC

بسیاری از سرورهای معمولی هنوز بر بستر پروتکل قدیمی HTTP/1.1 یا HTTP/2 کار می کنند. در پروتکل HTTP/2 مشکل انسداد سرخط (Head-of-Line Blocking) در لایه انتقال TCP همچنان وجود دارد؛ به این معنی که اگر حتی یک بسته داده (Packet) در شبکه ناپایدار از دست برود، تمام درخواست های هم زمان تا زمان ارسال مجدد آن متوقف می شوند.

استفاده از HTTP/3 که بر پایه پروتکل نوین QUIC و بستر UDP اجرا می شود، این گلوگاه را به کلی حذف می کند. دست دادن اولیه (Handshake) سریع تر، رمزنگاری یکپارچه TLS 1.3 و جابجایی بدون قطعی اتصال هنگام تغییر شبکه کاربر (مثلا از Wi-Fi به اینترنت همراه) سرعت بارگذاری منابع صفحه را تا ۳۰ درصد ارتقا می بخشد.

۲. برتری فشرده سازی الگوریتم Brotli نسبت به Gzip

اگرچه هنوز فشرده سازی Gzip پرکاربرد است، اما الگوریتم Brotli (br) به شکل چشمگیری در متون متراکم مانند فایل های HTML، CSS و جاوا اسکریپت عملکرد بهتری از خود نشان می دهد. داده های آماری نشان می دهند Brotli فایل های فرانت اند را بین ۱۵ تا ۲۰ درصد فشرده تر از Gzip تحویل می دهد. این کاهش حجم به ویژه برای کاربرانی که با سرعت اینترنت محدود متصل می شوند تاثیری شگفت انگیز دارد.

نمونه کانفیگ فعال سازی الگوریتم بروتلی در وب سرور Nginx به صورت زیر است:

# فعال سازی فشرده سازی مدرن بروتلی در وب سرور Nginx
brotli on;
brotli_comp_level 6;
brotli_static on;
brotli_types text/plain text/css application/javascript application/json image/svg+xml;

۳. استراتژی کشینگ پیشرفته با هدر Cache-Control و stale-while-revalidate

سریع ترین درخواست وب، درخواستی است که هرگز به سرور ارسال نشود! با استفاده صحیح از هدرهای مدیریت حافظه پنهان مرورگر (HTTP Caching)، می توانید اطمینان حاصل کنید که المان های ثابت (Static Assets) مانند لوگوها، فونت ها، استایل ها و اسکریپت های اصلی در سیستم کاربر ذخیره شده و در مراجعات بعدی با سرعت صفر میلی ثانیه فراخوانی شوند.

برای منابعی که ممکن است هر از چند گاهی به روزرسانی شوند، دستور مدرن stale-while-revalidate معجزه می کند. مرورگر نسخه کش شده را فورا به کاربر نمایش می دهد و به طور هم زمان در پشت صحنه آخرین نسخه را از سرور استعلام می گیرد:

# تنظیم هدر پاسخ برای کش مرورگر تا یک سال به همراه بررسی نسخه جدید
Cache-Control: public, max-age=31536000, stale-while-revalidate=86400, immutable

۴. بهینه سازی کوئری های دیتابیس و کشینگ در لایه حافظه (Object Cache)

در وب سایت های داینامیک و مدیریت محتوا مانند وردپرس، عمده تاخیر در پاسخ سرور ناشی از اجرای کوئری های کند پایگاه داده (Slow Queries) است. حلقه های تکرارشونده و افزونه های سنگین دیتابیس را اشباع می کنند. برای برطرف ساختن این موضوع، باید سه گام کلیدی بردارید:

• نمایه گذاری صحیح جداول (Indexing): ستون هایی از جداول که در دستورهای WHERE، JOIN و ORDER BY به کرات فراخوانی می شوند باید ایندکس گذاری اصولی داشته باشند.
• استفاده از Redis یا Memcached: فعال سازی ابزارهای کش اشیا در حافظه رم (RAM)، مانع از اجرای مجدد درخواست های تکراری به سمت MySQL یا PostgreSQL شده و زمان تولید HTML را به کسری از ثانیه می رساند.
• پاک سازی رونوشت ها و جداول گذرا (Transients): حذف داده های انباشته شده و بدون استفاده در دیتابیس، حجم جداول را کاهش داده و سرعت جستجو را مضاعف می کند.

گاهی با وجود بهینه سازی کامل سرور، صفحات به دلیل وجود خطاهای ساختاری و مسیرهای شکسته، فشار مضاعفی به منابع سیستم وارد می کنند. مدیریت صحیح چرخه خطا و بهره گیری از تکنیک های هدایت ترافیک نظیر ریدایرکت ۳۰۱ تضمین می کند که هیچ درخواست بیهوده ای توان پردازشی سرور شما را تلف نکند.

ابزارهای پایش و رصد مداوم سرعت؛ تله تست های آزمایشگاهی

یکی از متداول ترین اشتباهات وب مستران، تکیه مطلق بر نمره سبز ابزارهایی مانند Google PageSpeed Insights در حالت تست دستی است. این بررسی ها تحت عنوان داده های آزمایشگاهی (Lab Data) شناخته می شوند و عملکرد یک دستگاه فرضی شبیه سازی شده را می سنجند. آن چه رتبه ارگانیک شما را تعیین می کند، تجربه واقعی تک تک کاربران شما در سراسر کشور یعنی داده های میدانی (Field Data یا CrUX) است.

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

• گزارش Core Web Vitals در گوگل سرچ کنسول: بهترین مرجع برای تفکیک صفحاتی که وضعیت قرمز (Poor) یا نیازمند ارتقا (Need Improvement) دارند بر مبنای بازه ۲۸ روزه داده های واقعی گوگل کروم.
• کتابخانه web-vitals جاوا اسکریپت: تزریق این کتابخانه سبک در سایت به شما اجازه می دهد ارقام واقعی شاخص های LCP، INP و CLS را همراه با ابعاد صفحه نمایش به گوگل آنالیتیکس ۴ یا دیتابیس اختصاصی ارسال کرده و ناهنجاری های لحظه ای را پیش از کاهش رتبه شناسایی کنید.
• پلاگین Web Vitals برای مرورگر گوگل کروم: نمایشگر زنده برای تحلیل گران فرانت اند تا در حین اسکرول و کلیک در سایت، رفتارهای غیرعادی INP و پرش های CLS را درجا عیب یابی کنند.

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

چک لیست اجرایی بهینه سازی Core Web Vitals برای تیم فنی

برای پیاده سازی سریع و بدون سردرگمی، مراحل عملیاتی را به صورت خلاصه در دستور کار تیم فنی یا توسعه دهنده سایت خود قرار دهید:

1. شاخص LCP: افزودن fetchpriority="high" به تصویر هیرو، حذف Lazy Loading از اولین عکس بالای صفحه، تبدیل تصاویر به فرمت WebP یا AVIF و پیاده سازی پیش بارگذاری (Preload).
2. شاخص INP: شکستن حلقه ها و اسکریپت های طولانی جاوا اسکریپت با متد مدرن scheduler.yield()، کاهش لایه های تو در توی DOM و به تعویق انداختن اسکریپت های آماری جانبی با ویژگی defer.
3. شاخص CLS: تعریف دقیق ابعاد width و height یا استایل aspect-ratio برای همه تصاویر و کادرها، تخصیص حداقل ارتفاع برای بنرهای تبلیغاتی و استفاده از font-display: swap به همراه تنظیمات تطبیق فونت پیش فرض.
4. زیرساخت سرور و TTFB: راه اندازی وب سرور با HTTP/3، فعال سازی فشرده سازی فوق العاده سریع Brotli، پیاده سازی کش اشیا در رم با Redis و استفاده از کش مرورگر با سیاست stale-while-revalidate.