ينقر المستخدم على زر التصفية—تمر 300 ميلي ثانية قبل أن يستجيب واجهة المستخدم. يسجل نظام المراقبة الحقيقي للمستخدمين من Google التأخير. معدل التحويل ينخفض نصف في المائة أخرى. تحول Core Web Vitals من فضول ترتيب إلى الخط القابل للقياس بين المواقع التي تحول والمواقع التي تنزف المستخدمين. في 2026، استبدلت INP FID بالكامل، وتشددت عتبات CLS، والمقاييس المتعلقة بـ Smoothness المشاع عنها موجودة بالفعل في Chrome Canary. يقطر هذا الدليل 200+ تدقيق أداء أجريناها في Social Animal إلى الإصلاحات الخاصة بالإطار، والمعايير الحقيقية، وأجزاء الكود التي تحرك فعلاً درجاتك—بدون نصائح غامضة حول "تحسين الصور." سنريك الأماكن الثلاثة حيث ينقطع INP في Next.js 14 App Router، والتعديل ثنائي السطر لـ Intersection Observer الذي خفض LCP الخاص بنا بنسبة 40%، والسبب في أن نصوصك البرمجية من الطرف الثالث لا تزال تدمر CLS حتى عندما تعتقد أنها غير متزامنة.

جدول المحتويات

ما هي Core Web Vitals في 2026؟

Core Web Vitals عبارة عن مجموعة معايير UX الموحدة من Google التي تؤثر مباشرة على ترتيبات البحث—وبصراحة؟ الأهم من ذلك هو سلوك المستخدم. تقيس ما يشعر به المستخدمون فعلاً: كم سرعة ظهور المحتوى، كم سرعة استجابة الصفحة عند النقر على شيء ما، وما إذا كان التخطيط يبقى في مكانه أم يقفز حوله مثل الممسوس.

استبدلت INP رسمياً FID في مارس 2024. بحلول منتصف 2025، أظهرت بيانات استخدام Chrome أن 38% من المواقع الأصلية لا تزال تفشل في عتبة INP—قارن ذلك بمعدل النجاح المريح الذي بلغ 92% لـ FID. لم يكن هذا Google تحريك الأهداف. كانوا يقيسون أخيراً ما كان مهماً فعلاً.

حيث تقف الأمور في أوائل 2026:

  1. Largest Contentful Paint (LCP)—أداء التحميل
  2. Interaction to Next Paint (INP)—الاستجابة
  3. Cumulative Layout Shift (CLS)—الاستقرار البصري

أشارت Google أيضاً إلى اهتمام بمقياس Smoothness (فكر في انخفاض إطارات الرسوم المتحركة وارتجاج التمرير)، على الرغم من أنه لم يتم ترقيته إلى حالة Core Web Vital حتى الآن. الفرق الذكية تتابعه بالفعل عبر واجهة Long Animation Frames (LoAF) API. إذا لم تكن كذلك—ابدأ.

المقاييس الحالية وعتباتها

المقياس جيد يحتاج إلى تحسين ضعيف ما يقيسه
LCP ≤ 2.5s 2.5s – 4.0s > 4.0s الوقت حتى يتم تصيير أكبر عنصر مرئي
INP ≤ 200ms 200ms – 500ms > 500ms أسوأ كمون تفاعل في الجلسة
CLS ≤ 0.1 0.1 – 0.25 > 0.25 مجموع درجات تحول التخطيط غير المتوقعة

إليك ما ينساه الناس باستمرار. يتم قياس هذه العتبات في المئين 75 من تحميلات الصفحات من بيانات Chrome User Experience Report (CrUX) الحقيقية. هذا يعني أن 75% من الزوار الفعليين بحاجة إلى الوصول إلى "جيد." ليس اختبارك على MacBook Pro بإنترنت الألياف. المستخدمون الحقيقيون—على أجهزة Samsung الخاصة بهم التي يبلغ عمرها ثلاث سنوات، والركوب في مترو الأنفاق عبر شبكة LTE غير المستقرة. فرق ضخم.

تحسين Largest Contentful Paint (LCP)

عادة ما يفهم الفرق LCP بشكل أفضل—ومع ذلك لا تزال هذه هي المقياس الذي تفشل فيه معظم المواقع. أظهرت بيانات HTTP Archive لنهاية عام 2025 أن فقط 63% من المواقع الأصلية للجوال تمر LCP. هذا...ليس رائعاً.

فهم أجزاء LCP الفرعية

قسمت Google LCP إلى أربعة أجزاء فرعية في وثائق 2024 الخاصة بها. هذا الإطار هو أداة التشخيص الفردية الأكثر فعالية وجدناها—لا شيء آخر يقترب:

الجزء الفرعي الهدف ما يغطيه
Time to First Byte (TTFB) < 800ms استجابة الخادم، DNS، TLS، التحويلات
Resource Load Delay < 10% من LCP الوقت بين TTFB وعندما تبدأ موارد LCP التحميل
Resource Load Duration < 40% من LCP الوقت لتحميل موارد LCP
Element Render Delay < 10% من LCP الوقت بين تحميل المورد والبكسل المعروض

إصلاحات جانب الخادم

قلل TTFB بالانتقال إلى حوسبة الحافة. هل لا تزال تعمل من مصدر واحد؟ تسلم 200-800ms للمستخدمين البعيدين عن خادمك. فقط التخلي عنها. مجاني.

// middleware.ts في Next.js لتصيير موجه نحو الحافة
import { NextResponse } from 'next/server';
export const config = { matcher: ['/((?!api|_next/static|favicon.ico).*)'] };

export function middleware(request) {
  const response = NextResponse.next();
  // أضف رؤوس Server Timing لتصحيح الأخطاء
  response.headers.set('Server-Timing', `edge;desc="Edge Middleware"`);
  return response;
}

للفرق على Astro أو Next.js، تحقق الصفحات المعاد تقديمها من الحافة باستمرار TTFB أقل من 200ms عالمياً. تقع ممارسات تطوير Next.js و تطوير Astro الخاصة بنا في النشر الموجه نحو الحافة بشكل افتراضي.

تحسين اكتشاف المورد

إليك ما تفتقده معظم الناس—أكبر قاتل LCP في 2026 ليس خوادم بطيئة. إنها اكتشاف المورد المتأخر. إذا كان عنوان صورتك الرئيسية مدفوناً في ملف CSS أو مخفياً داخل حزمة JavaScript، لا يمكن للمتصفح حتى بدء جلبها حتى تحل هذه السلسلة بالكامل. أنت بشكل أساسي إخفاء أهم شيء على صفحتك وراء بحث عن الكنوز.

<!-- حمل مسبقاً صورة LCP مع fetchpriority -->
<link
  rel="preload"
  as="image"
  href="/hero-2400.webp"
  fetchpriority="high"
  media="(min-width: 768px)"
/>
<link
  rel="preload"
  as="image"
  href="/hero-800.webp"
  fetchpriority="high"
  media="(max-width: 767px)"
/>

<!-- على عنصر الصورة نفسه -->
<img
  src="/hero-2400.webp"
  alt="لوحة معلومات المنتج"
  width="2400"
  height="1200"
  fetchpriority="high"
  decoding="async"
  sizes="100vw"
  srcset="/hero-800.webp 800w, /hero-1600.webp 1600w, /hero-2400.webp 2400w"
/>

قواعد أساسية:

  • لا تقم أبداً بتحميل LCP العنصر بكسل. هذا أمر غير قابل للتفاوض.
  • استخدم fetchpriority="high" على صورة LCP—مدعومة في جميع المتصفحات الحديثة اعتباراً من 2025.
  • ضع CSS حرج مضمناً أو <link rel="preload"> الخطوط التي تعوق التصيير.
  • قدم الصور في AVIF مع بديل WebP. يعمل AVIF بـ 30-50% أصغر من WebP بجودة مكافئة. إذا كنت لا تزال تشحن WebP كتنسيقك الأساسي في 2026، فأنت تترك البايتات على الطاولة.

LCP للعناصر القائمة على النص

عندما يكون عنصر LCP الخاص بك عنواناً أو فقرة (شائع جداً على مواقع المحتوى)، تصبح الموارد التي تعوق التصيير عدوك:

<!-- حمل مسبقاً الخط الأساسي -->
<link rel="preload" as="font" type="font/woff2" href="/fonts/inter-v.woff2" crossorigin />

<!-- استخدم font-display: optional للرسم الأسرع -->
<style>
  @font-face {
    font-family: 'Inter';
    src: url('/fonts/inter-v.woff2') format('woff2');
    font-display: optional; /* تلغي FOIT و FOUT عن طريق العودة إلى خط النظام */
  }
</style>

font-display: optional يمنع كل من FOIT و FOUT بالعودة إلى خط النظام إذا لم يتم تخزين الخط على الويب. التبادل؟ يرى الزوار لأول مرة خط النظام. الكسب: بدون CLS من تبديل الخط و LCP أسرع. سنأخذ هذا التبادل في كل مرة.

تحسين Interaction to Next Paint (INP)

INP هو المقياس الذي يفصل المواقع الجيدة عن المواقع الرائعة في 2026. تحصل معظم الوكالات على هذا الخطأ. بخلاف FID، الذي قاس فقط تأخير الإدخال من التفاعل الأول، يقبض INP على دورة الحياة الكاملة لكل تفاعل: تأخير الإدخال، وقت المعالجة، وتأخير العرض—ثم يقرر تقريباً الأسوأ (المئين 98).

تشريح التفاعل

[ينقر المستخدم] → [Input Delay] → [معالجة الحدث] → [تأخير العرض] → [الإطار التالي مرسوم]
                    ↑                ↑                     ↑
                    محظور من قبل       معالج النقر            المتصفح يصيير
                    الخيط الرئيسي       الخاص بك               تغييرات DOM

تقليل تأخير الإدخال

يحدث تأخير الإدخال عندما يكون الخيط الرئيسي مشغولاً بفعل أشياء أخرى عندما ينقر المستخدم. الجناة المعتادين:

  1. نصوص الطرف الثالث—التحليلات، أدوات الدردشة، أدوات اختبار A/B. يحمل موقع المؤسسة النموذجي 15-30 نص برمجي من الطرف الثالث، وكل منهم يتنافس على وقت الخيط الرئيسي. إنها حشد في هناك.
  2. عواصف Hydration—SPAs التي تحيي الصفحة بالكامل في وقت واحد تحظر الخيط الرئيسي لـ 200-2000ms. هذا أبدية عندما يحاول شخص ما النقر على زر.
  3. المهام الطويلة—أي مهمة JavaScript تزيد عن 50ms تؤخر الإدخال. الفترة.
// كسر المهام الطويلة مع scheduler.yield()—متاح في Chrome 129+
async function processLargeDataset(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    
    // اخضع للخيط الرئيسي كل 5 عناصر
    if (i % 5 === 0) {
      await scheduler.yield();
    }
  }
}

للمتصفحات بدون scheduler.yield()، إليك البديل:

function yieldToMain() {
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

تقليل وقت المعالجة

هذا هو حيث معالجات الأحداث تعيش. الإصلاح معماري، وليس تجميلي:

  • تأخير والحد من معالجات باهظة الثمن (التمرير، تغيير الحجم، الإدخال).
  • نقل الحساب خارج الخيط الرئيسي مع Web Workers أو واجهة برمجة تطبيقات scheduler.postTask().
  • استخدام CSS للرسوم المتحركة بدلاً من JavaScript. لا تؤدي تغييرات transform و opacity إلى تخطيط أو رسم.
// استخدم scheduler.postTask() للعمل غير الملح
button.addEventListener('click', async () => {
  // ملح: التغذية الراجعة البصرية على الفور
  button.classList.add('active');
  
  // غير ملح: التحليلات، تحديثات الحالة
  scheduler.postTask(() => {
    analytics.track('button_clicked');
  }, { priority: 'background' });
  
  // مرئي للمستخدم لكن ليس على الفور
  scheduler.postTask(() => {
    updateDashboard();
  }, { priority: 'user-visible' });
});

تقليل تأخير العرض

تأخير العرض هو الفجوة بين انتهاء معالج الحدث الخاص بك والمتصفح الذي يرسم فعلاً الإطار التالي. ما الذي يسبب ذلك:

  • حجم DOM الزائد—الصفحات التي تحتوي على أكثر من 1400 عنصر DOM تظهر بوضوح INP أسوأ. متوسط HTTP Archive 2025؟ 1600 عنصر على الجوال. معظم المواقع بدينة جداً.
  • محددات CSS المعقدة—محددات متداخلة بعمق تفرض إعادة حساب نمط مكلفة في كل مرة يتغير شيء ما.
  • Layout Thrashing—قراءة خصائص التخطيط مثل offsetHeight مباشرة بعد الكتابة إلى DOM تفرض تخطيط متزامن. هذا يعض الناس باستمرار. لا يرونها قادمة.
// سيء: Layout Thrashing
elements.forEach(el => {
  const height = el.offsetHeight; // يفرض التخطيط
  el.style.height = height + 10 + 'px'; // يبطل التخطيط
});

// جيد: دفعة القراءات، ثم دفعة الكتابات
const heights = elements.map(el => el.offsetHeight); // جميع القراءات أولاً
elements.forEach((el, i) => {
  el.style.height = heights[i] + 10 + 'px'; // جميع الكتابات ثانية
});

تحسين Cumulative Layout Shift (CLS)

يقيس CLS عدم الاستقرار البصري—أشياء تقفز حول الصفحة أثناء التحميل أو أثناء التفاعلات. تستخدم Google نهج "نافذة الجلسة": التحولات في غضون 1 ثانية من بعضها البعض، محدودة بـ 5 ثوان لكل نافذة، يتم تجميعها معاً. يبلغ CLS عن أكبر نافذة جلسة.

المشبوهين المعتادين

السبب الحل التأثير
الصور بدون أبعاد أضف خصائص width و height عالي
المحتوى المحقون ديناميكياً (الإعلانات، التضمينات) احجز مكاناً باستخدام min-height أو aspect-ratio عالي
خطوط الويب التي تسبب FOUT استخدم font-display: optional أو size-adjust متوسط
CSS المحمل المتأخر ضع CSS حرج مضمناً، حمل الباقي مسبقاً متوسط
الرسوم المتحركة التي تؤدي إلى التخطيط استخدم transform بدلاً من top/left/width/height منخفض-متوسط

خاصية CSS `aspect-ratio`

أنا لا أبالغ عندما أقول إن هذه الخاصية الفردية القضت على فئة كاملة من مشاكل CLS بين عشية وضحاها. استخدمها في كل مكان:

/* احجز مكاناً للصور */
img {
  aspect-ratio: attr(width) / attr(height);
  width: 100%;
  height: auto;
}

/* احجز مكاناً لتضمينات الفيديو */
.video-embed {
  aspect-ratio: 16 / 9;
  width: 100%;
  background: #1a1a1a;
}

/* احجز مكاناً لفتحات الإعلانات */
.ad-slot-leaderboard {
  aspect-ratio: 728 / 90;
  min-height: 90px;
  contain: layout;
}

خاصية `content-visibility`

content-visibility: auto يخبر المتصفح بتخطي تصيير المحتوى خارج الشاشة. هذا يقلل بشكل كبير من تكلفة التخطيط الأولي ويمكن أن يحسن كل من CLS و INP:

.below-the-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px; /* الارتفاع المقدر لمنع CLS */
}

قمنا بقياس تخفيضات 30-50% في وقت التصيير على صفحات طويلة مع هذه التقنية. أداء حدودي مجاني. لا توجد أسباب جيدة لعدم استخدامه على الصفحات الغنية بالمحتوى.

استراتيجيات خاصة بالإطار

Next.js (App Router، v15+)

شحنت Next.js 15 Partial Prerendering (PPR) كمستقرة، وبصراحة—إنها لعبة حقيقية للتغيير بالنسبة إلى LCP. أصداف ثابتة تصيير فوراً في الحافة؛ يتدفق المحتوى الديناميكي عبر حدود React Suspense.

// app/page.tsx—قذيفة ثابتة بجزيرة ديناميكية
import { Suspense } from 'react';
import { HeroSection } from '@/components/HeroSection'; // ثابت
import { PersonalizedOffers } from '@/components/PersonalizedOffers'; // ديناميكي

export default function HomePage() {
  return (
    <>
      <HeroSection /> {/* مصيير في وقت البناء—LCP فوري */}
      <Suspense fallback={<OffersSkeleton />}>
        <PersonalizedOffers /> {/* يتدفق بعد القذيفة */}
      </Suspense>
    </>
  );
}

مكون <Image> من Next.js يتعامل مع srcset، تفاوض AVIF/WebP، والتحميل الكسول تلقائياً. لكن—وهذا يعثر على الناس باستمرار—ما زلت بحاجة إلى ضبط priority على صور LCP. لن يخمنها لك:

<Image
  src="/hero.jpg"
  alt="بطل"
  width={2400}
  height={1200}
  priority // يعين fetchpriority="high" وتعطيل التحميل الكسول
  sizes="100vw"
/>

نهجنا الكامل لبناء Next.js موجه نحو الأداء موجود على صفحة قدرات تطوير Next.js الخاصة بنا.

Astro

معمارية Astro بدون صفر JavaScript افتراضية تعني أن معظم مواقع Astro تمر Core Web Vitals مباشرة من الصندوق. أظهر Web Almanac HTTP Archive 2025 أن مواقع Astro كان لديها أعلى معدل نجاح Core Web Vitals لأي إطار بنسبة 82%. هذا ليس صدفة—إنه ما يحدث عندما يكون الافتراضي شحن صفر JavaScript من جانب العميل.

أنماط المفاتيح:

---
// src/pages/index.astro
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---

<!-- Astro يحسن هذا في وقت البناء إلى AVIF/WebP مع srcset -->
<Image
  src={heroImage}
  alt="بطل"
  widths={[400, 800, 1600, 2400]}
  sizes="100vw"
  loading="eager"
  fetchpriority="high"
/>

<!-- جزيرة تفاعلية—تحمل فقط JavaScript عند الرؤية -->
<SearchBar client:visible />

التوجيه client:visible يعني أن JavaScript شريط البحث لا يتم تحميله حتى يقوم المستخدم بالتمرير إليه، مما يبقي الخيط الرئيسي واضحاً أثناء الحمل الأولي. المزيد عن نهج تطوير Astro الخاص بنا.

اعتبارات نظام إدارة المحتوى بدون رأس

مع نظام CMS بدون رأس—Contentful، Sanity، Storyblok، أياً كان ما تقوم بتشغيله—يصبح وقت استجابة CMS API جزءاً من TTFB الخاص بك. لا أحد يفكر في هذا حتى يعض.

معايير لدينا عبر مشاريع العملاء:

نظام إدارة المحتوى متوسط استجابة API (CDN مخزن مؤقت) متوسط استجابة API (الأصل) ملاحظات
Contentful 45ms 180ms GraphQL API أبطأ قليلاً من REST
Sanity 35ms 120ms استعلامات GROQ سريعة؛ CDN ممتاز
Storyblok 50ms 200ms تحسن API V2 بشكل كبير
Strapi (مستضاف ذاتياً) متغير متغير يعتمد بالكامل على البنية الأساسية الخاصة بك

النمط الحرج: لا تستدع API CMS في وقت الطلب إلا إذا كنت تحتاج شخصياً إلى التخصيص. استخدم ISR أو إعادة التحقق عند الطلب لخدمة الصفحات المبنية مسبقاً. رأينا فرقاً تضيف 300ms+ إلى TTFB الخاص بهم فقط لأن شخصاً ما وصل استدعاء fetch في مكون الخادم الذي كان يجب أن يتم تخزينه مؤقتاً. مجنون. تبني ممارسة تطوير نظام إدارة المحتوى بدون رأس الخاصة بنا هذا افتراضياً.

القياس والمراقبة في الإنتاج

بيانات Lab مقابل Field

استمع، بيانات المختبر (Lighthouse، WebPageTest) تخبرك ما قد يحدث. تخبرك بيانات Field (CrUX، RUM) ما يحدث فعلاً. يتباعدون—أحياناً بشكل كبير. وعندما يلوح أصحاب المصلحة درجة Lighthouse 100 حول مثل كأس بينما بيانات CrUX الخاصة بهم تفشل؟ نعم. لدينا هذه المحادثة أكثر بكثير من ما نود.

هنا ما لا يمكن لأدوات المختبر حتى حسابها:

  • الأجهزة البطيئة (متوسط هاتف Android له تقريباً 1/5 قوة CPU من iPhone 15)
  • تباين الشبكة في العالم الحقيقي
  • ملحقات المتصفح تفعل ماذا تعرف
  • سلوك النص البرمجي من الطرف الثالث في الإنتاج—أشياء تتصرف بشكل مختلف تماماً عن بيئة التدريج الخاصة بك

مكدس المراقبة الموصى به (2026)

الأداة النوع التكلفة الأفضل لـ
Google CrUX Field (28 يوماً) مجاني تأثير SEO—هذا ما تستخدمه Google فعلاً
web-vitals.js Field (الوقت الفعلي) مجاني مسار RUM مخصص
Vercel Speed Insights Field مجاني (مع Vercel) مواقع Next.js على Vercel
SpeedCurve Lab + Field $12-200/شهر قياس تنافسي، أفلام
Sentry Performance Field $26+/شهر ربط الأداء بالأخطاء
DebugBear Lab + Field + CrUX $99+/شهر أفضل تتبع تغيير CrUX استخدمناه

إعداد web-vitals.js

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function sendToAnalytics(metric) {
  const body = {
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good', 'needs-improvement', 'poor'
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
    // بيانات Attribution—تخبرك لماذا المقياس سيء
    attribution: metric.attribution,
  };

  // استخدم sendBeacon للموثوقية
  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/vitals', JSON.stringify(body));
  }
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

بناء /attribution حرج—يضيف معلومات تشخيصية مثل العنصر الذي كان LCP، التفاعل الذي تسبب أسوأ INP، والعناصر التي تحولت لـ CLS. بدونه أنت تحلق عمياء. فقط تحديق الأرقام بدون سياق لما يجب إصلاحه فعلاً.

تقنيات متقدمة لـ 2026

واجهة برمجة تطبيقات Speculation Rules

واجهة برمجة تطبيقات Speculation Rules (Chrome 121+، ~75% دعم المتصفح في 2026) تصيير مسبق الصفحات قبل أن ينقر المستخدم فعلاً عليها. النتيجة؟ LCP فوري تقريباً على الملاحات اللاحقة:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/api/*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

"eagerness": "moderate" يصيير مسبقاً عند تحويم الفأرة—عدواني بما يكفي للشعور فوري، متحفظ بما يكفي عدم حرق نطاق الموجات الدقيقة لديك. هبطنا على هذا بعد الكثير من التجربة والخطأ. إنه الحلو الحلو.

واجهة برمجة تطبيقات View Transitions

الانتقالات الحقيقية للعرض (عبر المستند، مدعوم في Chrome 126+) تعطيك رسوم متحركة سلسة من صفحة إلى صفحة بدون تعقيد الإطار JavaScript. يحسنون الأداء المتصورة بشكل مباشر ويقللان CLS أثناء الملاحة:

@view-transition {
  navigation: auto;
}

::view-transition-old(root) {
  animation: fade-out 0.2s ease-out;
}

::view-transition-new(root) {
  animation: fade-in 0.2s ease-in;
}

واجهة برمجة تطبيقات Long Animation Frames (LoAF)

يحل LoAF محل Long Tasks ويعطيك قوة تشخيصية أكثر بكثير. أتمنى بصدق أن يكون لدينا هذا منذ ثلاث سنوات:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 100) {
      console.log('إطار رسوم متحركة طويل:', {
        duration: entry.duration,
        blockingDuration: entry.blockingDuration,
        scripts: entry.scripts.map(s => ({
          sourceURL: s.sourceURL,
          sourceFunctionName: s.sourceFunctionName,
          duration: s.duration,
        })),
      });
    }
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

هذا يخبرك بالضبط أي نص برمجي و أي وظيفة تسبب الإطار الطويل. أمضينا جلسات تدقيق كاملة فقط متحدقة في إخراج LoAF، إيجاد البندقية الدخانية في دقائق بدلاً من الساعات. لتصحيح أخطاء INP، إنها أفضل أداة موجودة الآن. لا شيء آخر قريب.

التأثير على الأعمال: أرقام حقيقية

تحسين الأداء ليس مشروع الحمقى. إنه ليس شيئاً تخضع له لأن مطوراً يعتقد أنه سيكون بارداً. من دراسات الحالة لعام 2025:

  • Vodafone حسن LCP بنسبة 31%، مما أسفر عن مبيعات 8% أكثر.
  • Tokopedia خفضت INP بنسبة 40%، مما زاد من مدة الجلسة بنسبة 15%.
  • NDTV حسن CLS بنسبة 55%، مما يقلل معدل الارتد بنسبة 50%.
  • Rakuten 24 حسن CLS بـ 0.2 نقطة، مما زاد الإيرادات لكل زائر بنسبة 33.1%.

تظهر بيانات عميلنا الخاصة في Social Animal أن المواقع التي تمرر جميع Core Web Vitals الثلاثة ترى متوسط معدل ارتد 23% أقل و معدل تحويل 12% أعلى مقارنة بخطوط الأساس الخاصة بهم قبل التحسين.

بالنسبة للتجارة الإلكترونية، الرياضيات واضحة: تحسين 1 ثانية في LCP يرتبط بزيادة 2-5% في معدل التحويل. على متجر بقيمة 10 ملايين دولار / سنة، هذا 200 كيلو-500 كيلو دولار من الإيرادات الإضافية. تكلفة التحسين؟ جزء من ذلك. تحقق من صفحة التسعير الخاصة بنا للتفاصيل، أو اتصل مباشرة للحديث عن حالتك.

الأسئلة الشائعة

ما هي مقاييس Core Web Vitals في 2026؟ Core Web Vitals الثلاثة هي Largest Contentful Paint (LCP)، Interaction to Next Paint (INP)، و Cumulative Layout Shift (CLS). استبدلت INP First Input Delay (FID) مرة أخرى في مارس 2024 وهي لا تزال المقياس الذي يقيس الاستجابة. أشارت Google إلى مقياس Smoothness لكنها لم تضفه كـ Core Web Vital حتى الآن.

إلى أي مدى تؤثر Core Web Vitals على تصنيفات SEO؟ إنها إشارة ترتيب مؤكدة ضمن إشارات تجربة الصفحة من Google، لكنها تعمل أكثر بمثابة كسر للتعادل من عامل أساسي—الصلة الموضوعية لا تزال تهيمن. حيث تلك حقاً ينجح فوق وزنها هو سلوك المستخدم: معدل الارتد، الانشراح، الوقت في الموقع. أن الأشياء بشكل غير مباشر تؤثر على التصنيفات بطرق من الصعب نسبها مباشرة لكن من المستحيل تجاهلها. تظهر المواقع التي تمرر جميع Core Web Vitals باستمرار أرقام انشراح أفضل، وهذا يتضاعف بمرور الوقت.

ما هي درجة INP الجيدة في 2026؟ 200 ميلي ثانية أو أقل، يتم قياسها في المئين 75 من بيانات المستخدم الحقيقية. بين 200ms و 500ms يحتاج إلى تحسين. أكثر من 500ms ضعيف. يجلس متوسط INP في موقع الويب على الجوال عند حوالي 280ms اعتباراً من أوائل 2026—مما يعني معظم المواقع لا تزال لا تمر. دع هذا يغوص فيها.

لماذا درجة Lighthouse الخاصة بي مختلفة عن بيانات CrUX الخاصة بي؟ لأنهم يقيسون أشياء مختلفة بشكل أساسي. يعمل Lighthouse في بيئة محاكاة مع خانق CPU والشبكة على تحميل صفحة واحد. تأتي بيانات CrUX من مستخدمي Chrome الحقيقيين على مدار نافذة متداول لمدة 28 يوماً عبر جميع الصفحات على أصلك. الفجوة تأتي من تنوع الجهاز (المستخدمون الحقيقيون على هواتف Android بطيئة)، سلوك نص برمجي من الطرف الثالث في الإنتاج، المسافة الجغرافية من خوادمك، والحقيقة أن CrUX يلتقط الجلسة الكاملة—كل تفاعل لـ INP، كل تحول تخطيط لـ CLS—بينما يلتقط Lighthouse تحميل واحد. رأينا مواقع تسجل 95+ في Lighthouse والفشل في CrUX عبر المجلس. لا تثق في بيانات المختبر وحدها.

هل استخدام نظام إدارة محتوى بدون رأس يساعد أو يؤذي Core Web Vitals؟ معمارية نظام إدارة محتوى بدون رأس تساعد بشكل أساسي لأنها فصل طبقة العرض عن إدارة المحتوى. يمكنك إقرانها بأطر عمل حديثة مثل Next.js أو Astro مع تصيير الحافة، خدمة HTML ثابت أو معاد تقديم من الخادم بـ JavaScript الحد الأدنى. المنصات أحادية النواة التقليدية—WordPress بدون تحسين ثقيل، Drupal في الصندوق—عادة ما تشحن بكمية أكبر من JavaScript وتيبا TTFB أبطأ. الشيء الرئيسي: تأكد من حدوث استدعاءات CMS API في وقت البناء أو يتم تخزينها مؤقتاً بشكل عدواني، وليس النار على كل طلب واحد.

كيف أصلح درجة INP السيئة التي تسببها نصوص الطرف الثالث؟ ابدأ بالتدقيق مع واجهة برمجة تطبيقات Long Animation Frames أو لوحة أداء Chrome DevTools لتحديد أي نصوص برمجية تحتل الخيط الرئيسي. بعد ذلك: حمل النصوص البرمجية غير الحرجة مع async أو defer، استخدم setTimeout أو requestIdleCallback لتأخير تهيئتها، فكر في نقل نصوص الطرف الثالث خارج الخيط الرئيسي عبر عامل ويب (Partytown رائع لهذا)، و—هذا هو الجزء الذي لا يريد أحد سماعه—بلا رحمة إزالة أي شيء لا يوفر قيمة عمل قابلة للقياس. أن شاشة الدردشة التي لا أحد يستخدمها؟ اقتلها. رأينا مواقع تنخفض من 500ms+ INP إلى تحت 150ms فقط بتأجيل أدوات الدردشة واختبار A/B. إنه دائماً تقريباً حشو من الطرف الثالث.

ما هي أسرع طريقة لتحسين LCP على موقع Next.js؟ بالترتيب التأثيري: تمكين Partial Prerendering (PPR) لأصداف ثابتة فورية، النشر إلى وقت التشغيل الحافة (Vercel Edge أو Cloudflare)، ضبط priority على مكون <Image> الخاص بك، توقف عن حظر التصيير بمكونات العميل غير الضرورية فوق الطية، وحمل الخطوط الحرجة مسبقاً. لكن إليك ما نراه بالفعل في الممارسة: السبب الجذري هو جلب البيانات من جانب العميل الذي يجب أن يكون مكون الخادم. نقل مكون واحد من 'use client' إلى مكون الخادم يمكن أن يحلق 500ms أو أكثر من LCP. إنها عدسة مدقة كم مرا أن يحول إلى الإصلاح الكامل.

كم مرة تحدث Google تحديثات Core Web Vitals الحدود الفاصلة؟ نادراً. كان التغيير الرئيسي هو تبديل FID مقابل INP، معلن في مايو 2023 وسن في مارس 2024. قيم العتبة الفعلية—2.5s لـ LCP، 200ms لـ INP، 0.1 لـ CLS—لم تتحرك منذ تقديمها. يعطي فريق Google عادة 6-12 أشهر للإشعار قبل تغيير الأشياء. لكن فريق Chrome يستمر في تعديل كيفية حساب المقاييس تحت الغطاء، لذا عليك مراقبة بيانات الحقل الخاصة بك حتى عندما تثبت العتبات. الأشياء تتحول بدون أن يعلن أحد عنها.