كيفية تحسين سرعة صفحة الويب لموقع إلكتروني أسرع

ملخص

ركز على مؤشرات أداء الويب الأساسية (Core Web Vitals): LCP (سرعة رسم أكبر محتوى في أقل من 2.5 ثانية)، INP (التفاعل مع الرسم التالي في أقل من 200 مللي ثانية)، و CLS (تراكم تغيرات تخطيط الصفحة في أقل من 0.1). استخدم صور AVIF، و Speculation Rules API للتنقل الفوري، و HTTP/3، و Lighthouse للقياس. السرعة تؤثر بشكل مباشر على تصنيفات SEO ومعدلات التحويل.

سرعة الصفحة ليست مجرد رفاهية. خوارزمية ترتيب جوجل تكافئ المواقع السريعة. يغادر المستخدمون المواقع البطيئة (معدل ارتداد 50% في الصفحات التي تستغرق أكثر من 3 ثوانٍ). وبالنسبة لعملك، فإن كل تحسن بمقدار 100 مللي ثانية في وقت التحميل يمكن أن يزيد التحويلات بنسبة 1-7%.

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

فهم مؤشرات أداء الويب الأساسية (Core Web Vitals)

مؤشرات أداء الويب الأساسية هي ثلاثة مقاييس تستخدمها جوجل للترتيب. وهي تقيس تجربة المستخدم الحقيقية:

سرعة رسم أكبر محتوى (LCP)

يقيس LCP مدى سرعة ظهور المحتوى الرئيسي. وتحديداً، أكبر عنصر مرئي على الشاشة.

الهدف: أقل من 2.5 ثانية

0s ─────────────────────── 4s
   ├─── Good (LCP <2.5s)
        ├─── Fair (2.5s-4s)
             ├─── Poor (>4s)

ما الذي يعتبر "محتوى"؟

• الصور
• العناوين ونصوص الفقرات
• صور غلاف الفيديو (Video poster images)
• العناصر ذات صور الخلفية

ما الذي لا يحتسب؟

• عناصر SVG
• عناصر Canvas
• محتوى Iframe

كيفية تحسين LCP:

1. استخدام التحميل الكسول (Lazy load) للصور الموجودة أسفل الجزء المرئي (لا تقم أبداً بذلك لعنصر LCP نفسه — استخدام loading="lazy" على صورة البطل (hero image) سيضر بدرجة LCP الخاصة بك):

<!-- Above the fold (LCP candidate): eager + fetchpriority -->
<img src="hero.avif" fetchpriority="high" alt="Hero image" />

<!-- Below the fold: defer until scrolled into view -->
<img src="gallery-1.avif" loading="lazy" alt="Gallery image" />

2. تحسين المسار الحرج: قلل من ملفات CSS و JavaScript التي تمنع العرض (render-blocking).

// Before: render-blocking CSS
<link rel="stylesheet" href="styles.css" />

// After: critical CSS inline, defer the rest
<style>{criticalCSS}</style>
<link rel="stylesheet" href="styles.css" media="print" onload="this.media='all'" />

3. التحميل المسبق لعنصر LCP:

<link rel="preload" as="image" href="hero.avif" />

التفاعل مع الرسم التالي (INP)

يقيس INP مدى استجابة موقعك لتفاعلات المستخدم. عندما ينقر المستخدم، أو يمرر، أو يكتب، كم من الوقت يستغرق حتى الرسم التالي؟ حل هذا المقياس محل تأخير الإدخال الأول (FID) في مارس 2024.

الهدف: أقل من 200 مللي ثانية

لماذا هذا مهم؟ الاستجابة البطيئة تجعل موقعك يبدو معطلاً، حتى لو تم تحميله في النهاية.

0ms ──────────────────── 500ms
   ├─── Good (INP <200ms)
        ├─── Fair (200-500ms)
             ├─── Poor (>500ms)

كيفية تحسين INP:

1. تقسيم مهام JavaScript الطويلة (أي مهمة أطول من 50 مللي ثانية تصبح ملحوظة):

// Bad: blocks for 100ms
function processLargeDataset(data) {
  const result = data
    .map(item => expensiveCalculation(item))
    .filter(item => item.isValid);
  updateUI(result);
}

// Good: break into chunks
async function processLargeDataset(data) {
  const chunkSize = 100;
  for (let i = 0; i < data.length; i += chunkSize) {
    const chunk = data.slice(i, i + chunkSize);
    const result = chunk
      .map(item => expensiveCalculation(item))
      .filter(item => item.isValid);
    updateUI(result);

    // Yield to browser to handle other tasks
    await new Promise(resolve => setTimeout(resolve, 0));
  }
}

2. استخدام web workers للحسابات المكلفة:

// main.js
const worker = new Worker('worker.js');
worker.postMessage({ data: largeDataset });
worker.onmessage = (event) => updateUI(event.data);

// worker.js
self.onmessage = (event) => {
  const result = complexCalculation(event.data);
  self.postMessage(result);
};

3. تأجيل JavaScript غير الضروري:

<!-- Critical for interactivity -->
<script src="interactive.js"></script>

<!-- Deferred: analytics, non-essential features -->
<script defer src="analytics.js"></script>

تراكم تغيرات تخطيط الصفحة (CLS)

يقيس CLS التغيرات غير المتوقعة في التخطيط. عندما يتحرك المحتوى فجأة بينما يحاول المستخدمون التفاعل، تكون هذه تجربة سيئة.

الهدف: أقل من 0.1

مثال: أنت على وشك النقر فوق زر، ولكن يتم تحميل إعلان ويدفع الزر لأسفل. فتنقر على الإعلان بالخطأ. هذا هو تغير التخطيط.

كيفية تحسين CLS:

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

<!-- Bad: ad can cause shift -->
<div id="ad"></div>

<!-- Good: reserve space -->
<div style="width: 300px; height: 250px;">
  <div id="ad"></div>
</div>

2. استخدام content-visibility لمنع التغير:

/* Prevent cumulative layout shift on images */
img {
  content-visibility: auto;
}

3. تجنب إدراج محتوى فوق المحتوى الموجود:

// Bad: prepend new items (shifts everything down)
setItems([...newItems, ...items]);

// Good: append new items (no shift)
setItems([...items, ...newItems]);

تحسين الصور

تمثل الصور عادةً 50-80% من حجم الصفحة. تحسينها له التأثير الأكبر.

AVIF: تنسيق الجيل القادم

تنسيق AVIF أصغر من WebP، وهو بدوره أصغر من JPEG. في عام 2026، أصبح دعم AVIF واسع النطاق (جميع المتصفحات الحديثة).

<picture>
  <source srcset="image.avif" type="image/avif" />
  <source srcset="image.webp" type="image/webp" />
  <img src="image.jpg" alt="Description" />
</picture>

أحجام الملفات النموذجية لنفس الصورة:

• JPEG: 100 كيلوبايت
• WebP: 60 كيلوبايت
• AVIF: 40 كيلوبايت

استخدم ImageOptim أو TinyPNG أو Squoosh للضغط.

الصور المتجاوبة

قدم أحجاماً مختلفة بناءً على عرض الجهاز:

<img
  src="image-400w.avif"
  srcset="
    image-400w.avif 400w,
    image-800w.avif 800w,
    image-1200w.avif 1200w
  "
  sizes="(max-width: 600px) 90vw, (max-width: 1200px) 70vw, 1200px"
  alt="Product image"
/>

هذا يخبر المتصفح:

• على الشاشات التي يبلغ عرضها 600 بكسل أو أقل، قم بتحميل صورة بنسبة 90% من عرض مساحة العرض (viewport)
• على الشاشات التي يتراوح عرضها بين 600-1200 بكسل، قم بتحميل صورة بنسبة 70% من عرض مساحة العرض
• للشاشات الأكبر، قم بتحميل صورة ثابتة بعرض 1200 بكسل

تحسين الشبكة

قواعد التخمين (Speculation Rules) API

تسمح قواعد التخمين للمتصفح بجلب الصفحات مسبقاً (prefetch) أو عرضها مسبقاً (prerender) والتي من المرجح أن يزورها المستخدم بعد ذلك.

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/checkout", "/confirmation"]
    }
  ]
}
</script>

بهذه الطريقة، إذا نقر المستخدم على "المتابعة لإتمام الشراء"، تكون الصفحة محملة بالفعل في علامة تبويب مخفية.

HTTP/3 و Early Hints

بروتوكول HTTP/3 أسرع من HTTP/2. إذا كانت استضافتك تدعمه، فقم بتفعيله.

تخبر ميزة HTTP 103 Early Hints المتصفح بالبدء في جلب الموارد الحرجة قبل أن يصبح ملف HTML الرئيسي جاهزاً:

HTTP/1.1 103 Early Hints
Link: </css/styles.css>; rel=preload; as=style
Link: </js/app.js>; rel=preload; as=script

HTTP/1.1 200 OK
<!-- HTML content -->

تدعم معظم شبكات توصيل المحتوى (CDNs) مثل Cloudflare و Fastly هذه الميزة. تحقق من استضافتك.

القياس باستخدام Lighthouse

يعد Lighthouse هو المعيار الصناعي لقياس الأداء.

# Using Lighthouse CLI
npm install -g @google/lighthouse
lighthouse https://example.com --view

أو استخدم أدوات مطوري Chrome: F12 ← علامة تبويب Lighthouse ← "Analyze page load".

ما الذي يجب البحث عنه:

1. الفرص (Opportunities): مرتبة حسب التأثير المحتمل (مثل: "تخلص من الموارد التي تمنع العرض: توفير 2.4 ثانية")
2. التشخيصات (Diagnostics): تفاصيل حول ما هو بطيء
3. عمليات التدقيق الناجحة (Passed audits): ما الذي يعمل بشكل جيد

حدد درجة مستهدفة لكل فئة:

• الأداء: +90
• إمكانية الوصول: +95
• أفضل الممارسات: +95
• SEO: 100

مراقبة المستخدم الحقيقي (RUM)

تختبر الأدوات المعملية مثل Lighthouse موقعك في بيئة محكومة. أما مراقبة المستخدم الحقيقي (RUM) فتقيس تجربة المستخدم الفعلية.

مكتبة Web Vitals

تستخدم مكتبة v3+ API وظائف on* (تم إهمال وظائف get* القديمة، وتم إيقاف FID في سبتمبر 2024 لصالح INP):

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

onCLS(console.log); // Cumulative Layout Shift
onINP(console.log); // Interaction to Next Paint
onFCP(console.log); // First Contentful Paint
onLCP(console.log); // Largest Contentful Paint
onTTFB(console.log); // Time to First Byte

// Send to analytics
onLCP((metric) => {
  analytics.track('Core Web Vitals', {
    metric: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good', 'needs-improvement', 'poor'
  });
});

تعرض خدمات مثل Vercel Analytics أو Google Analytics 4 أو Datadog مؤشرات أداء الويب الأساسية من مستخدمين حقيقيين.

ميزانية الأداء

حدد أهدافاً لموارد معينة:

// Budget in lighthouse config
{
  "budgets": [
    {
      "type": "bundle",
      "name": "main",
      "baseline": 150000,
      "maxSize": 170000
    },
    {
      "type": "font",
      "name": "Inter",
      "maxSize": 50000
    }
  ]
}

قم بتشغيل Lighthouse CI في عملية CI/CD الخاصة بك لإيقاف عمليات البناء التي تتجاوز الميزانية.

الأخطاء الشائعة

الكثير من سكربتات الطرف الثالث: التحليلات، الإعلانات، أدوات الدردشة — كل منها يضيف حملاً إضافياً. قم بتحميلها بشكل غير متزامن (asynchronously).

خطوط الويب غير المحسنة: يتم تحميل خطوط النظام فوراً. تسبب خطوط الويب وميضاً للنص غير المرئي (FOIT). استخدم استراتيجيات font-display:

@font-face {
  font-family: 'Inter';
  src: url('inter.woff2') format('woff2');
  font-display: swap; /* Show fallback until font loads */
}

الحزم الكبيرة (Large bundles): قم بإزالة الكود غير المستخدم (Tree-shake)، وتقسيم الكود حسب المسار (route)، وتحميل المكونات بشكل كسول:

// Before: entire library bundled
import { datePicker, dropdown, modal } from 'ui-lib';

// After: lazy load what you need
const datePicker = lazy(() => import('ui-lib/DatePicker'));

الاستجابات غير المضغوطة: تأكد من تفعيل ضغط gzip/brotli على خادمك.

أهم النقاط المستفادة

تحسين السرعة عملية مستمرة:

1. القياس أولاً: استخدم Lighthouse و Google Analytics لتحديد نقاط الاختناق
2. التركيز على مؤشرات أداء الويب الأساسية: LCP و INP و CLS — هذه تؤثر بشكل مباشر على الترتيب
3. تحسين الصور: يحقق استخدام AVIF + الصور المتجاوبة أكبر المكاسب
4. تقسيم JavaScript: المهام الطويلة تدمر درجات INP
5. قياس المستخدمين الحقيقيين: الأدوات المعملية تفتقد لظروف العالم الحقيقي
6. المراقبة المستمرة: حدد ميزانيات الأداء وفرضها في عملية CI

تحسين وقت التحميل بمقدار ثانية واحدة يمكن أن يعني آلاف الدولارات من الإيرادات الإضافية للتجارة الإلكترونية. السرعة ليست اختيارية.