مؤشرات الويب الأساسية: القياس والتحسين لأداء ويب أفضل

لقد قمت ببناء موقع ويب سريع، لكن المستخدمين لا يزالون يشتكون من البطء. أو ربما انخفضت ترتيباتك في SEO بعد تحديث جوجل. قد يكون السبب هو مؤشرات الويب الأساسية—مجموعة من المقاييس التي يستخدمها جوجل لقياس تجربة المستخدم الواقعية. تجاهلها يمكن أن يضر برضا المستخدم وظهورك في البحث.

في هذا الدليل، ستتعلم ما هي مؤشرات الويب الأساسية، وكيفية قياسها بدقة، وخطوات عملية لتحسين كل مقياس. سنركز على المقاييس الثلاثة الحالية: Largest Contentful Paint (LCP)، وInteraction to Next Paint (INP)، وCumulative Layout Shift (CLS).

ما هي مؤشرات الويب الأساسية؟

مؤشرات الويب الأساسية هي مجموعة فرعية من مؤشرات الويب التي يعتبرها جوجل ضرورية لتقديم تجربة مستخدم رائعة. وهي تحدد مدى سرعة تحميل المحتوى، ومدى استجابة الصفحة للتفاعلات، ومدى استقرارها البصري.

يستخدم جوجل هذه المقاييس كإشارة ترتيب، ولكن الأهم من ذلك، أنها تعكس نقاط الألم الحقيقية للمستخدمين. LCP البطيء يحبط المستخدمين المنتظرين للمحتوى؛ INP المرتفع يجعل الصفحة تبدو بطيئة؛ CLS المرتفع يسبب النقرات الخاطئة والإزعاج.

مؤشرات الويب الأساسية الثلاثة

• Largest Contentful Paint (LCP): يقيس أداء التحميل. يشير إلى الوقت الذي يصبح فيه أكبر عنصر محتوى (صورة، فيديو، أو كتلة نصية) مرئيًا. LCP الجيد هو 2.5 ثانية أو أقل.
• Interaction to Next Paint (INP): يقيس الاستجابة. يسجل زمن الوصول لجميع التفاعلات (النقرات، اللمسات، ضغطات المفاتيح) ويقدم قيمة واحدة. INP الجيد هو 200 مللي ثانية أو أقل.
• Cumulative Layout Shift (CLS): يقيس الاستقرار البصري. يحدد التحولات غير المتوقعة في التخطيط أثناء التحميل. CLS الجيد هو 0.1 أو أقل.

تستند هذه العتبات إلى بيانات ميدانية من مستخدمين حقيقيين، وليس اختبارات معملية. يقيّمها جوجل عند النسبة المئوية 75 لتحميلات الصفحات، مما يعني أن 75% من تجارب المستخدمين يجب أن تلبي عتبة "الجيد".

كيفية قياس مؤشرات الويب الأساسية

تحتاج إلى بيانات معملية وميدانية معًا. تحاكي الأدوات المعملية تحميل صفحة واحدة تحت ظروف محكومة، بينما تلتقط البيانات الميدانية (Real User Monitoring, RUM) تجارب المستخدمين الفعلية عبر الأجهزة والشبكات.

الأدوات المعملية

• Lighthouse: مدمج في Chrome DevTools، يقوم بتدقيق الأداء ويوفر درجات لـ LCP وCLS وtotal blocking time (TBT)، الذي يرتبط بـ INP. قم بتشغيله في وضع التخفي لتجنب تحريف الإضافات للنتائج.
• PageSpeed Insights: يجمع بين بيانات معملية (Lighthouse) وميدانية (CrUX). استخدمه لرؤية درجاتك المعملية ومقاييس المستخدمين الحقيقيين.
• WebPageTest: يوفر اختبارات متقدمة من مواقع وأجهزة متعددة. يوفر شرائط أفلام ومخططات انسيابية لتشخيص مشكلات التحميل.

الأدوات الميدانية

• Chrome User Experience Report (CrUX): مجموعة بيانات عامة لمقاييس المستخدمين الحقيقيين من Chrome. متاحة عبر PageSpeed Insights أو CrUX Dashboard أو BigQuery.
• Google Search Console: يعرض حالة مؤشرات الويب الأساسية لموقعك بناءً على بيانات CrUX. يجمع عناوين URL حسب الأداء.
• مكتبة web-vitals JavaScript: مكتبة صغيرة لقياس المقاييس في RUM الخاص بك. يمكنك إرسال البيانات إلى منصة التحليلات الخاصة بك.

إليك كيفية استخدام مكتبة web-vitals لتسجيل المقاييس في وحدة التحكم:

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

function sendToAnalytics(metric) {
  const body = JSON.stringify(metric);
  // Use navigator.sendBeacon() or fetch() to send data
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
  fetch('/analytics', {body, method: 'POST', keepalive: true});
}

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

لإجراء فحص سريع دون برمجة، يمكنك استخدام أدوات عبر الإنترنت تحلل بيانات الأداء. على سبيل المثال، إذا كانت لديك سجلات الخادم، فإن Nginx Log Analyzer يمكن أن يساعدك في تحديد الاستجابات البطيئة التي قد تؤثر على LCP.

تحسين Largest Contentful Paint (LCP)

غالبًا ما يكون LCP المقياس الأكثر تأثيرًا للتحسين. يتأثر بوقت استجابة الخادم، ووقت تحميل الموارد، والعرض من جانب العميل.

تحسين استجابة الخادم

• استخدم CDN لتقديم المحتوى من مواقع أقرب إلى المستخدمين.
• تمكين التخزين المؤقت (المتصفح وجانب الخادم) للأصول الثابتة.
• حسّن استعلامات قاعدة البيانات وكود جانب الخادم لتقليل TTFB (Time to First Byte).
• قم بالترقية إلى HTTP/2 أو HTTP/3 لتعدد الإرسال واتصالات أسرع.

تحسين الموارد

• تحميل الموارد الحرجة مسبقًا: استخدم <link rel="preload"> لصورة LCP أو الخط.
• ضغط الصور وتحديد أحجامها بشكل صحيح: استخدم تنسيقات حديثة مثل WebP أو AVIF، وقدم صورًا متجاوبة باستخدام srcset.
• تصغير CSS و JavaScript: إزالة الأحرف والتعليقات غير الضرورية.
• تأجيل JavaScript غير الحرج: استخدم سمات async أو defer.
• تضمين CSS الحرج: ضع الأنماط فوق الطية مباشرة في HTML لتجنب طلبات حجب العرض.

إزالة الموارد التي تحجب العرض

CSS و JavaScript في <head> يحجبان العرض. قم بتضمين CSS الحرج وتحميل الباقي بشكل غير متزامن. بالنسبة لـ JavaScript، استخدم defer أو async.

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

يقيس INP الوقت من تفاعل المستخدم إلى العرض التالي. يتأثر بتنفيذ JavaScript، ومعالجة الأحداث، وعمل العرض.

تقليل وقت تنفيذ JavaScript

• قسّم المهام الطويلة (أكثر من 50 مللي ثانية) باستخدام setTimeout أو requestIdleCallback.
• استخدم web workers للحسابات الثقيلة.
• استخدم debounce أو throttle لمعالجات الأحداث للتمرير وتغيير الحجم وأحداث الإدخال.
• تجنب البرامج النصية المتزامنة الكبيرة؛ قسّم الكود وحمّل الوحدات بشكل كسول.

تحسين معالجة الأحداث

• استخدم مستمعي الأحداث السلبية لأحداث اللمس والعجلة لتحسين أداء التمرير.
• قلل من التلاعب بـ DOM؛ اجمع التحديثات واستخدم requestAnimationFrame.
• قلل نطاق إعادة حساب الأنماط بتجنب المحددات المعقدة.

تحسين أداء العرض

• استخدم CSS will-change أو transform للرسوم المتحركة لتفعيل تسريع GPU.
• تجنب إرباك التخطيط بقراءة وكتابة الأنماط في مراحل منفصلة.

تحسين Cumulative Layout Shift (CLS)

يقيس CLS التحولات غير المتوقعة في التخطيط. يحدث بسبب تغيير العناصر لموقعها أثناء التحميل، غالبًا بسبب الصور بدون أبعاد، أو الإعلانات، أو المحتوى المحقون ديناميكيًا.

دائمًا قم بتضمين سمات الحجم

للصور والفيديوهات، قم بتعيين سمات width و height أو استخدم CSS aspect-ratio. هذا يحجز المساحة ويمنع التحولات.

<img src="#" width="800" height="600" alt="Hero">

احجز مساحة للمحتوى الديناميكي

• استخدم CSS min-height للحاويات التي تحمل محتوى بشكل غير متزامن (مثل الإعلانات، التضمينات).
• تجنب إدراج محتوى فوق المحتوى الموجود إلا إذا تم تشغيله بواسطة تفاعل المستخدم.

استخدم Font-Display Swap

يمكن أن تتسبب الخطوط المخصصة في نص غير مرئي (FOIT) أو تحولات في التخطيط عند تحميلها. استخدم font-display: swap لإظهار النص البديل فورًا، وقم بتحميل الخطوط مسبقًا لتقليل وقت التبديل.

وضع كل ذلك معًا: سير عمل عملي

1. القياس: ابدأ بـ PageSpeed Insights للحصول على بيانات معملية وميدانية. حدد المقياس الذي يحتاج إلى تحسين.
2. التشخيص: استخدم Lighthouse ولوحة Performance في Chrome DevTools للعثور على الاختناقات. انظر إلى المخطط الانسيابي، ونشاط الخيط الرئيسي، وتحولات التخطيط.
3. التحسين: طبق التقنيات المذكورة أعلاه، مع إعطاء الأولوية للتغييرات التي تؤثر على أسوأ مقياس.
4. الاختبار: أعد تشغيل الاختبارات المعملية لتأكيد التحسينات. انشر إلى بيئة تجريبية واستخدم RUM لمراقبة البيانات الميدانية.
5. المراقبة: قم بإعداد RUM مستمر باستخدام مكتبة web-vitals وتنبيه عند الانحدارات. استخدم Search Console لتتبع حالة مؤشرات الويب الأساسية.

تذكر أن التحسينات يمكن أن يكون لها مقايضات. على سبيل المثال، التحميل الكسول للصور يمكن أن يحسن التحميل الأولي ولكن قد يضر بـ LCP إذا تم تحميل صورة LCP بشكل كسول. اختبر دائمًا مع مستخدمين حقيقيين.

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

ما هي العتبات الحالية لمؤشرات الويب الأساسية؟

بالنسبة لـ LCP، الجيد هو ≤2.5 ثانية، يحتاج إلى تحسين هو ≤4.0 ثانية، والسيئ هو >4.0 ثانية. بالنسبة لـ INP، الجيد هو ≤200 مللي ثانية، يحتاج إلى تحسين هو ≤500 مللي ثانية، والسيئ هو >500 مللي ثانية. بالنسبة لـ CLS، الجيد هو ≤0.1، يحتاج إلى تحسين هو ≤0.25، والسيئ هو >0.25. يتم تقييم هذه العتبات عند النسبة المئوية 75 لتحميلات الصفحات.

كم مرة يجب أن أتحقق من مؤشرات الويب الأساسية؟

راقب البيانات الميدانية باستمرار باستخدام RUM. تحقق من Search Console شهريًا للاتجاهات العامة. قم بتشغيل الاختبارات المعملية بعد تغييرات الكود الرئيسية أو عمليات النشر. يمكن أن تتغير مؤشرات الويب الأساسية مع تحديثات موقعك أو البرامج النصية للجهات الخارجية.

هل يمكنني تحسين مؤشرات الويب الأساسية بدون مطور؟

بعض التحسينات ممكنة عبر الإضافات أو الإعدادات (مثل تمكين التخزين المؤقت، تحسين الصور). ومع ذلك، غالبًا ما تتطلب المكاسب الكبيرة تغييرات في الكود مثل تضمين CSS الحرج، أو تأجيل JavaScript، أو إعادة هيكلة كيفية تحميل الموارد. عادة ما تكون مساعدة المطور مطلوبة لتحسين INP وتحسينات LCP المتقدمة.

هل أنت مستعد لتحليل أداء خادمك؟ جرب Nginx Log Analyzer لتحديد الطلبات البطيئة التي قد تؤثر على مؤشرات الويب الأساسية لديك.