انتقال مقياس التفاعل إلى اللوحة التالية (Interaction to Next Paint - INP) ليصبح مقياساً أساسياً في Core Web Vitals وضع حداً لعصر الاعتماد على قياسات التفاعل اللحظية البسيطة مثل FID. لا يقيس INP أول تفاعل فقط، بل يراقب أسوأ زمن استجابة لجميع التفاعلات (نقرات، ضغطات مفاتيح، لمسات شاشة) طوال دورة حياة الصفحة. لتحقيق تصنيف "جيد" (أقل من 200 مللي ثانية)، يجب فهم البنية الداخلية لـ Event Loop في المتصفح والتحكم الدقيق في مسارات المعالجة والـ Rendering Pipeline.

التشريح الداخلي لزمن استجابة التفاعل (INP Breakdown)

يتألف مقياس INP من ثلاثة أطوار متتالية يجب عزلها وتحليلها لتحديد سبب الاختناق بدقة:

1. تأخير الإدخال (Input Delay)

هو الوقت المنقضي بين قيام المستخدم بالتفاعل ولحظة بدء المتصفح في تنفيذ دوال الاستماع للحدث (Event Handlers). سببه الرئيسي هو انشغال الخيط الرئيسي (Main Thread) بمهمة طويلة (Long Task) تم تشغيلها مسبقاً (مثل تحليل سكريبت طرف ثالث أو تهيئة Hydration معقدة).

2. وقت المعالجة (Processing Duration)

هو الزمن المستغرق لتنفيذ الشيفرات البرمجية داخل دوال معالجة الأحداث المتصلة بالتفاعل (Call Stack Execution). هذا يشمل معالجة البيانات، تحديث الذاكرة، وتعديل شجرة الـ DOM.

3. تأخير العرض (Presentation Delay)

الوقت الذي يحتاجه المتصفح لحساب الـ Layout والـ Styles وإجراء الـ Paint والـ Compositing لعرض الإطار الجديد (Next Frame) على الشاشة بعد تعديل الـ DOM.

استراتيجية التنازل عن الخيط الرئيسي (Yielding to the Main Thread)

الخطأ الأكثر شيوعاً في الواجهات الأمية هو تشغيل حلقات تكرار متصلة لمعالجة آلاف العناصر أو البيانات، مما يجمد المتصفح لمدة تتجاوز 50 مللي ثانية. الحل الجذري هو "تقطيع المهام" (Task Slicing) باستخدام استراتيجية التنازل غير المتزامن.

بينما كانت الحلول القديمة تعتمد على setTimeout(fn, 0)، توفر واجهة scheduler.yield() الحديثة (مع Fallback متين) أفضل طريقة للتنازل دون خسارة ترتيب الأولوية في طابور المهام الدقيقة (Microtasks).

/**
 * أداة متقدمة للتنازل عن الخيط الرئيسي مع دعم بيئات المتصفحات المختلفة
 */
const yieldToMain = () => {
  // استخدام scheduler.yield الأصلي إن وُجد
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return window.scheduler.yield();
  }
  
  // Fallback عالي الأداء باستخدام MessageChannel لتجنب قيود setTimeout
  return new Promise((resolve) => {
    const { port1, port2 } = new MessageChannel();
    port1.onmessage = () => resolve();
    port2.postMessage(null);
  });
};

/**
 * معالجة مصفوفة ضخمة من البيانات مع الحفاظ على استجابة الـ UI
 */
async function processLargeDataset(items, chunkProcessor, deadline = 8) {
  let start = performance.now();
  
  for (let i = 0; i < items.length; i++) {
    chunkProcessor(items[i], i);
    
    // التحقق من تجاوز الميزانية الزمنية المحددة للكتلة (Frame Budget)
    if (performance.now() - start > deadline) {
      await yieldToMain();
      start = performance.now(); // إعادة تعيين المؤقت بعد استئناف العمل
    }
  }
}

فصل التحديث البصري عن منطق الحسابات (Decoupling State Updates)

لتقليل كل من Processing Duration و Presentation Delay، يجب تقديم تغذية راجعة بصرية فورية (Immediate Visual Feedback) في الإطار الأول، ثم تأجيل معالجة العمليات الثقيلة إلى إطار لاحق عبر requestAnimationFrame أو الترحيل إلى Web Workers.

// تحسين تفاعل نموذج بحث مرشحات ضخم
const searchInput = document.querySelector('#complex-filter-input');
const feedbackSpinner = document.querySelector('#ui-indicator');

searchInput.addEventListener('input', (event) => {
  const query = event.target.value;
  
  // 1. الاستجابة الفورية للمستخدم (أقل من 16ms)
  feedbackSpinner.classList.add('is-active');
  
  // 2. تأجيل المعالجة الثقيلة للإطار التالي لمنح المتصفح فرصة رسم الإطار الأول
  requestAnimationFrame(() => {
    // تشغيل الحسابات المعقدة عبر Web Worker
    worker.postMessage({ action: 'FILTER_DATA', query });
  });
});

// استقبال نتائج المعالجة دون تعطيل الخيط الرئيسي
worker.onmessage = (event) => {
  const { filteredResults } = event.data;
  renderVirtualList(filteredResults);
  feedbackSpinner.classList.remove('is-active');
};

إلغاء التفاعلات السابقة باستخدام AbortController

عندما يكتب المستخدم بسرعة داخل حقل نصي، تظل معالجات الأحداث السابقة عالقة في الـ Event Loop وتقوم بعمليات معالجة ورسم لبيانات أصبحت غير ذات صلة، مما يراكم Presentation Delay هائلاً.

class SearchController {
  constructor(apiEndpoint) {
    this.endpoint = apiEndpoint;
    this.abortController = null;
  }

  async handleSearch(query) {
    // إلغاء أي عملية معالجة أو طلب شبكي قيد التنفيذ فوراً
    if (this.abortController) {
      this.abortController.abort();
    }
    
    this.abortController = new AbortController();
    const { signal } = this.abortController;

    try {
      const response = await fetch(`${this.endpoint}?q=${encodeURIComponent(query)}`, { signal });
      const data = await response.json();
      
      if (!signal.aborted) {
        this.renderResults(data);
      }
    } catch (error) {
      if (error.name !== 'AbortError') {
        console.error('Fetch error:', error);
      }
    }
  }

  renderResults(data) {
    // تقنية DOM Patching السريع عبر DocumentFragment لتجنب Multiple Reflows
    const fragment = document.createDocumentFragment();
    data.forEach(item => {
      const el = document.createElement('div');
      el.className = 'result-item';
      el.textContent = item.name;
      fragment.appendChild(el);
    });
    
    const container = document.getElementById('results-container');
    container.replaceChildren(fragment); // استبدال مباشر عالي الأداء
  }
}

تحسين Presentation Delay وتفادي Forced Synchronous Layout

يحدث تأخير العرض غالباً عندما تجبر الشيفرة المتصفح على حساب الأبعاد والأنماط (Recalculate Styles / Layout Thrashing) بالتزامن مع قراءة وتعديل خصائص الـ DOM. لحل هذه المشكلة، يجب قراءة الأبعاد دفعة واحدة، ثم تطبيق التعديلات دفعة واحدة، مع استغلال خواص الـ CSS الحديثة لعزل كلفة إعادة الرسم.

/* عزل شجرة العرض لتقليل نطاق الـ Recalculate Styles والـ Paint */
.data-table-container {
  contain: layout paint style;
  content-visibility: auto;
  contain-intrinsic-size: 0 500px;
}

.interactive-card {
  will-change: transform;
  transform: translateZ(0); /* فرض طبقة Compositing منفصلة لتسريع الرندرة */
}

// نمط القراءة ثم الكتابة لتفادي Layout Thrashing
function updateComponentPositions(cards) {
  // الطور الأول: قراءة الأبعاد دفعة واحدة (Batch Reads)
  const measurements = cards.map(card => ({
    element: card,
    height: card.getBoundingClientRect().height
  }));

  // الطور الثاني: الكتابة وتطبيق التغييرات دفعة واحدة (Batch Writes)
  requestAnimationFrame(() => {
    measurements.forEach(({ element, height }) => {
      element.style.transform = `translateY(${height * 0.1}px)`;
    });
  });
}

المراقبة الحية لـ INP في بيئة الإنتاج (Real User Monitoring)

تحليل الأداء داخل DevTools يعطي صورة تقريبية، لكن قياس INP الحقيقي يتطلب رصد تفاعلات المستخدمين الفعلية على اختلاف أجهزتهم. نستخدم مكتبة web-vitals الرسمية مع إرسال البيانات التحليلية لربط بطء التفاعل بالـ Element Selector المسبب له:

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

onINP((metric) => {
  const { name, value, attribution } = metric;
  
  // استخراج المكون المسبب لأعلى تأخير
  const payload = {
    metric: name,
    durationMs: value,
    interactionType: attribution.interactionType, // 'pointer' | 'keyboard'
    targetElement: attribution.interactionTarget,
    inputDelay: attribution.inputDelay,
    processingDuration: attribution.processingDuration,
    presentationDelay: attribution.presentationDelay,
    loadState: attribution.loadState
  };

  // إرسال البيانات لنظام التحليلات دون إعاقة الخيط الرئيسي
  navigator.sendBeacon('/analytics/vitals', JSON.stringify(payload));
});

يتطلب الوصول بمؤشر INP إلى النطاق الأخضر تحولاً في العقلية البرمجية: الانتقال من المعالجة المركزية المتزامنة إلى معمارية غير متزامنة تماماً تفصل العمليات الحسابية عن خيط العرض، وتستخدم واجهات التنازل، وتحد من تعقيد شجرة الـ DOM وتأثير الـ Layout Thrashing.