1. مقدمة متعمقة: لماذا الأداء هو عملة العصر الرقمي؟

في المشهد الرقمي المعاصر، لم يعد أداء تطبيقات الويب مجرد ميزة تنافسية، بل أصبح ضرورة وجودية. تشير بيانات شركة Google إلى أن 70% من المستهلكين يعترفون بأن سرعة تحميل الصفحة تؤثر على رغبتهم في الشراء من متجر إلكتروني معين. الأكثر إثارة للقلق، أن 79% من المتسوقين الذين يواجهون أداءً بطيئاً لن يعودوا للشراء من نفس الموقع مرة أخرى. هذه الأرقام ليست مجرد إحصائيات، بل تعكس تحولاً جذرياً في سلوك المستخدمين وتوقعاتهم.

تأثير الأداء يمتد ليشمل محركات البحث أيضاً. فمنذ تحديث Google's Page Experience في 2021، أصبحت مؤشرات الأداء الأساسية (Core Web Vitals) جزءاً لا يتجزأ من خوارزميات الترتيب. المواقع التي تقدم تجربة مستخدم سلسة وسريعة تحظى بميزة تنافسية واضحة في نتائج البحث. هذا يعني أن تحسين الأداء لم يعد مجرد تحسين لتجربة المستخدم، بل هو استثمار في تحسين الظهور في محركات البحث وزيادة الحركة العضوية.

1.1 تطور مفاهيم أداء الويب - رحلة عبر الزمن

شهد مجال أداء الويب تطوراً كبيراً خلال العقد الماضي. ففي السابق، كان التركيز ينصب بشكل أساسي على زمن تحميل الصفحة بالكامل (Page Load Time). لكن هذا المقياس أثبت عدم كفاءته، إذ يمكن للصفحة أن تظهر للمستخدم بشكل تدريجي. لذلك، ظهرت مقاييس أكثر دقة تعكس تجربة المستخدم الحقيقية:

• First Paint (FP): اللحظة التي يبدأ فيها المتصفح برسم أي عنصر على الشاشة. هذا المقياس يعكس سرعة استجابة المتصفح لطلب المستخدم، لكنه لا يعني بالضرورة أن المستخدم يرى محتوى ذا معنى.
• First Contentful Paint (FCP): وقت ظهور أول عنصر محتوى (نص، صورة، canvas). هذا هو أول لحظة يدرك فيها المستخدم أن الصفحة تتحمل بالفعل.
• Largest Contentful Paint (LCP): وقت ظهور أكبر عنصر محتوى في منفذ العرض (عادةً ما يكون صورة أو نصاً كبيراً). هذا المقياس يعكس متى يصبح المحتوى الرئيسي للصفحة مرئياً. القيمة المثالية يجب أن تكون أقل من 2.5 ثانية.
• First Input Delay (FID): الوقت بين أول تفاعل للمستخدم (نقرة، لمسة، ضغط زر) واستجابة المتصفح لذلك التفاعل. هذا المقياس يعكس استجابة الصفحة. القيمة المثالية أقل من 100ms.
• Cumulative Layout Shift (CLS): مقياس للاستقرار البصري، يقيس مقدار حركة العناصر غير المتوقعة أثناء التحميل. القيمة المثالية أقل من 0.1.
• Time to Interactive (TTI): الوقت الذي تصبح فيه الصفحة قابلة للتفاعل بشكل كامل. هذا المقياس يعكس متى يمكن للمستخدم البدء في استخدام التطبيق دون إحباط.
• Total Blocking Time (TBT): مجموع الوقت الذي يكون فيه المعالج الرئيسي محجوباً بمهام طويلة تمنع استجابة الصفحة. هذا المقياس معملي يرتبط ارتباطاً وثيقاً بـ FID الحقلي.

1.1.1 التحول من المقاييس المعملية إلى المقاييس الحقلية (From Lab to Field)

من التطورات المهمة أيضاً التحول من الاعتماد على المقاييس المعملية (Lab Metrics) التي تقاس في بيئة محكومة، إلى المقاييس الحقلية (Field Metrics) التي تعتمد على بيانات حقيقية من المستخدمين (RUM - Real User Monitoring). هذا التحول وفر صورة أكثر دقة عن الأداء الفعلي الذي يختبره المستخدمون في ظروف مختلفة: شبكات بطيئة (2G, 3G)، أجهزة محدودة الإمكانيات (هواتف متوسطة المدى)، وظروف تصفح متنوعة (وجود إضافات في المتصفح، تطبيقات خلفية تستهلك الموارد).

على سبيل المثال، قد يظهر اختبار معملي على جهاز مكتبي متطور أن الموقع سريع جداً (LCP = 1.8 ثانية)، لكن البيانات الحقلية من مستخدمي الهواتف في مناطق ذات تغطية ضعيفة قد تظهر أن LCP الفعلي يتجاوز 6 ثوانٍ. هذا الفرق هائل ويغير أولويات التحسين تماماً.

1.2 علم نفس المستخدم: كيف يؤخر الأداء إدراك المستخدم للعلامة التجارية؟

هناك بعد آخر لا يقل أهمية عن الأرقام: البعد النفسي. الأبحاث في علم النفس المعرفي تشير إلى أن تأخر استجابة التطبيق لأكثر من ثانية واحدة يقطع تدفق التفكير (Flow State) للمستخدم. عند تجاوز 3 ثوانٍ، يبدأ المستخدم في الشعور بالإحباط ويبدأ إفراز هرمونات التوتر (الكورتيزول). عند تجاوز 10 ثوانٍ، يصل المستخدم إلى نقطة الغليان ويتخلى عن المهمة تماماً، بل وقد تتكون لديه صورة ذهنية سلبية عن العلامة التجارية تستمر لفترة طويلة.

2. الإطار النظري المتقدم: كيف تعمل المتصفحات ولماذا يتباطأ الأداء؟

لفهم تقنيات تحسين الأداء، يجب أولاً فهم آلية عمل المتصفحات وكيفية تحويلها للكود إلى صفحات مرئية. تتبع المتصفحات الحديثة مساراً محدداً لمعالجة الصفحات، يُعرف بـ "المسار الحرج لعرض الصفحة" (Critical Rendering Path). هذا المسار هو تسلسل الخطوات التي يجب على المتصفح تنفيذها قبل أن يتمكن من عرض أول بكسل على الشاشة.

2.1 المسار الحرج لعرض الصفحة بالتفصيل الممل

عندما يطلب المستخدم صفحة ويب (عبر كتابة URL أو النقر على رابط)، تمر العملية بالمراحل التالية بالترتيب:

1. معالجة HTML (HTML Parsing): يقوم المتصفح بقراءة مستند HTML بايت ببايت. عندما يواجه علامة (tag)، يقوم بإنشاء "عقدة" (Node) في شجرة DOM. هذه العملية تسمى "Tokenization". في النهاية، نحصل على شجرة DOM (Document Object Model) التي تمثل هيكل الصفحة.
2. معالجة CSS (CSS Parsing): أثناء بناء شجرة DOM، قد يواجه المتصفح روابط لملفات CSS خارجية أو وسوم <style>. يقوم المتصفح بتحميل هذه الموارد (قد تكون محجوبة) ثم يحللها لبناء شجرة CSSOM (CSS Object Model). CSSOM تحدد الأنماط المطبقة على كل عنصر.
3. إنشاء شجرة العرض (Render Tree Creation): يتم دمج شجرة DOM مع شجرة CSSOM لإنشاء شجرة جديدة تحتوي فقط على العناصر التي ستظهر فعلياً على الشاشة. العناصر المخفية (باستخدام display: none) لا تضاف إلى Render Tree.
4. التخطيط (Layout/Reflow): بعد معرفة العناصر المرئية وأنماطها، يجب على المتصفح حساب أبعاد ومواقع كل عنصر بدقة. هذا يتطلب قراءة CSS المعقدة مثل width: 50% أو position: absolute وتحويلها إلى أرقام مطلقة بالبكسلات بناءً على حجم منفذ العرض الحالي.
5. الرسم (Paint): الآن وقد عرفنا مكان كل عنصر وحجمه، نبدأ بتحويل كل عنصر إلى بكسلات فعلية. يتم ملء الألوان، رسم الحدود، النصوص، الظلال... إلخ. هذه العملية تتم على "طبقات" (Layers).
6. التركيب (Composite): بعد رسم كل طبقة على حدة، يقوم المتصفح بدمج (تركيب) هذه الطبقات في صورة نهائية واحدة وعرضها على الشاشة. هذه العملية سريعة جداً وتدار بواسطة GPU غالباً.

أي تأخير في أي من هذه الخطوات يؤخر ظهور الصفحة للمستخدم. فهم هذا المسار يساعدنا في تحديد أين نركز جهود التحسين.

2.2 لماذا تتباطأ تطبيقات الويب الحديثة؟ تحليل معمق للأسباب الجذرية

تعاني تطبيقات الويب المعاصرة من مشكلات أداء متعددة ومتشابكة. دعنا نحلل الأسباب الجذرية (Root Causes) بعمق:

2.2.1 تضخم حجم JavaScript - وباء العصر الحديث

تشير بيانات HTTP Archive إلى أن متوسط حجم JavaScript على المواقع تجاوز 400 كيلوبايت (بعد الضغط) في 2023، وهذا الرقم في تزايد مستمر. بعض المواقع تصل إلى 5-10 ميجابايت من JavaScript! المشكلة لا تكمن فقط في حجم الملفات (وقت التحميل عبر الشبكة)، بل في ثلاثة أبعاد أخرى أكثر خطورة:

• زمن المعالجة (Parse/Compile): المتصفح يحتاج وقتاً لتحليل (Parsing) وتجميع (Compiling) كود JavaScript. هذا الوقت يتناسب طردياً مع حجم الكود وتعقيده. على جهاز محدود (مثل هاتف Android متوسط)، قد تستغرق معالجة 1 ميجابايت من JavaScript عدة ثوانٍ كاملة. هذه الثواني تجعل المعالج الرئيسي مشغولاً ولا يستجيب للمستخدم.
• زمن التنفيذ (Execution): كود JavaScript يستهلك موارد المعالج الرئيسي (Main Thread) أثناء تنفيذه. أي كود يتم تشغيله عند تحميل الصفحة يمنع المتصفح من الاستجابة لأي تفاعلات مستخدم. هذا يسبب FID مرتفع.
• التكلفة على الأجهزة المحدودة: الهواتف الذكية متوسطة المدى تعاني أكثر من الحواسيب المكتبية عند تنفيذ JavaScript كثيف. معالج الهاتف أبطأ، والذاكرة أقل، والبطارية مورد محدود. ما يستغرق 100ms على حاسوب مكتبي قد يستغرق 500ms أو أكثر على هاتف ذكي.

"إن أعظم تهديد لأداء الويب الحديث ليس حجم الشبكة، بل مقدار JavaScript الذي نرسله إلى المتصفح. فمعالجة 1 ميجابايت من JavaScript على هاتف محدود قد تستغرق وقتاً أطول من تحميل 10 ميجابايت من الصور." - أدي عثمان، مهندس أداء في Google (مؤلف كتاب "Using WebPageTest")

2.2.2 الصور غير المحسّنة - القاتل الصامت

الصور تشكل في المتوسط 50% من وزن الصفحة. المشكلات الشائعة تشمل:

• استخدام صور بدقة أعلى من المطلوب (عرض 4000 بكسل لعرض 400 بكسل فقط). هذا يضخم الحجم بلا داعٍ.
• عدم استخدام الصيغ الحديثة مثل WebP أو AVIF التي تقدم ضغطاً أفضل من JPEG وPNG (بنسبة توفير تصل إلى 50% مقارنة بـ JPEG).
• غياب التحميل الكسول (Lazy Loading) للصور خارج منفذ العرض، مما يسبب تحميل كل الصور دفعة واحدة.
• عدم تحديد أبعاد الصورة (width/height) في HTML، مما يسبب CLS عندما تظهر الصورة فجأة وتدفع المحتوى لأسفل.

2.2.3 استراتيجيات التخزين المؤقت السيئة

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

2.2.4 كود الطرف الثالث (Third-Party Code) غير المحسّن

إضافات الطرف الثالث مثل Google Analytics، Facebook Pixel، أدوات الدردشة، والإعلانات هي سبب رئيسي لبطء المواقع. كل أداة من هذه الأدوات تضيف طلبات شبكة إضافية، وكود JavaScript خاص بها، وغالباً ما يتم تحميلها بطريقة محجوبة (blocking) مما يؤثر سلباً على FID وLCP.

2.2.5 عدم تحسين المسار الحرج

العديد من المواقع تضع جميع موارد CSS و JavaScript في <head> دون استخدام async/defer أو تقنية CSS النقدي، مما يعني أن المتصفح لا يبدأ في عرض أي شيء حتى يتم تحميل كل هذه الموارد.

3. إتقان Core Web Vitals: دليل عملي شامل

مؤشرات Core Web Vitals هي مجموعة من المقاييس التي تركز على ثلاثة جوانب من تجربة المستخدم: التحميل (LCP)، التفاعل (FID)، والاستقرار البصري (CLS). منذ مايو 2021، أصبحت هذه المقاييس جزءاً من خوارزمية ترتيب Google. في هذا القسم، سنتعمق في كل مؤشر على حدة ونقدم تقنيات عملية لتحسينه.

3.1 تحسين LCP (Largest Contentful Paint) - سباق التحميل

يقيس LCP الوقت الذي يستغرقه تحميل أكبر عنصر مرئي في منفذ العرض. هذا العنصر عادة ما يكون صورة كبيرة، أو صورة خلفية، أو نصاً في عنصر كبير (مثل العنوان الرئيسي). القيمة المثالية: أقل من 2.5 ثانية.

3.1.1 ما الذي يؤثر على LCP؟

LCP يتأثر بأربعة عوامل رئيسية:

1. زمن استجابة الخادم (TTFB - Time to First Byte): الوقت من بدء الطلب حتى وصول أول بايت من الاستجابة من الخادم. إذا كان الخادم بطيئاً، فكل شيء يتأخر.
2. حجب الموارد (Render-Blocking Resources): ملفات CSS و JavaScript التي تمنع المتصفح من عرض الصفحة حتى يتم تحميلها.
3. زمن تحميل المورد نفسه (Resource Load Time): الوقت المستغرق لتحميل عنصر LCP نفسه (مثل الصورة).
4. عرض العميل (Client-Side Rendering): في تطبيقات SPA، قد يتأخر LCP حتى يتم تنزيل وتنفيذ JavaScript الذي يقوم بإنشاء عنصر LCP.

3.1.2 تقنيات تحسين LCP المتقدمة

3.1.2.1 تحسين TTFB

• استخدم CDN: شبكات توصيل المحتوى تقلل المسافة بين المستخدم والخادم، مما يقلل TTFB بشكل كبير.
• تحسين أداء الخادم: استخدام التخزين المؤقت للاستعلامات (Query Caching)، تحسين قواعد البيانات، واستخدام خوادم أسرع.
• استخدم التخزين المؤقت على الحافة (Edge Caching): قم بتخزين الصفحات الكاملة على حافة CDN (مثل Cloudflare Workers أو Vercel Edge) لتقديمها فوراً دون الحاجة للوصول إلى الخادم الأصلي (Origin).

3.1.2.2 التحميل المسبق (Preload) لمورد LCP

أخبر المتصفح عن عنصر LCP في أقرب وقت ممكن باستخدام <link rel=preload>. ضع هذا الرابط في <head> ليبدأ التحميل فوراً، حتى قبل أن يكتشف المتصفح العنصر في HTML.

<!-- مثال: تحميل مسبق لصورة LCP -->
<link rel="preload" as="image" href="hero-image.webp">

<!-- أو إذا كانت الصورة عبارة عن background-image في CSS -->
<link rel="preload" as="image" href="background-hero.jpg">

3.1.2.3 تحسين الصورة نفسها

• استخدم صيغ حديثة: AVIF > WebP > JPEG.
• اضغط الصورة بأدوات مثل Squoosh أو ImageOptim.
• استخدم خدمة تحسين الصور (Image CDN) مثل Cloudinary أو Imgix التي تقدم صوراً محسنة تلقائياً حسب الجهاز.
• حدد أبعاد الصورة (width/height) لمنع CLS، مما يساعد المتصفح على حجز المساحة الصحيحة.

3.1.2.4 تجنب حجب الموارد

أي CSS أو JavaScript غير ضروري للعرض الأول يجب ألا يحجب LCP. استخدم تقنيات:

• استخراج CSS النقدي (Critical CSS) ووضعه في <style> في <head>.
• تحميل باقي CSS بشكل غير متزامن.
• استخدام async/defer لملفات JavaScript غير الحرجة.
• تقليل استخدام كود الطرف الثالث أو تحميله بعد LCP.

3.1.2.5 استخدم Server-Side Rendering (SSR) أو Static Site Generation (SSG)

في تطبيقات React أو Vue، تجنب Client-Side Rendering الخالص للمحتوى الرئيسي. استخدم Next.js أو Nuxt.js لتوليد HTML على الخادم، مما يجعل عنصر LCP متاحاً فور تحميل HTML دون انتظار JavaScript.

3.2 تحسين FID (First Input Delay) - سرعة الاستجابة

يقيس FID الوقت بين أول تفاعل للمستخدم (نقرة على رابط، ضغط زر) والوقت الذي يستجيب فيه المتصفح لذلك التفاعل. القيمة المثالية: أقل من 100ms.

3.2.1 أسباب ارتفاع FID

السبب الرئيسي هو أن المعالج الرئيسي (Main Thread) مشغول بتنفيذ مهام أخرى (غالباً JavaScript) ولا يستطيع الاستجابة للمستخدم. المهام الطويلة (Long Tasks) التي تستغرق أكثر من 50ms هي العدو الأول لـ FID.

3.2.2 تقنيات تحسين FID

3.2.2.1 تقسيم المهام الطويلة (Break Up Long Tasks)

إذا كان لديك كود JavaScript كبير يجب تشغيله عند التحميل، قم بتقسيمه إلى مهام أصغر باستخدام setTimeout() أو requestIdleCallback() أو scheduler.postTask(). هذا يسمح للمتصفح بالتقاط تفاعلات المستخدم بين هذه المهام.

// بدلاً من تشغيل حلقة كبيرة تستهلك 200ms
function processLargeArray(array) {
  // تقطيع العمل إلى أجزاء صغيرة
  let index = 0;
  
  function processChunk() {
    const chunkSize = 10;
    const end = Math.min(index + chunkSize, array.length);
    
    for (let i = index; i < end; i++) {
      // معالجة العنصر
      heavyProcess(array[i]);
    }
    
    index = end;
    
    if (index < array.length) {
      // جدولة الجزء التالي عندما يكون المتصفح خالياً
      setTimeout(processChunk, 0); // أو requestIdleCallback
    }
  }
  
  processChunk();
}

3.2.2.2 تقليل حجم JavaScript وتحسين وقت التنفيذ

• استخدم Tree Shaking للتخلص من الكود الميت.
• قسم الكود (Code Splitting) بحيث يتم تحميل الكود الضروري فقط للصفحة الحالية.
• تجنب المكتبات الثقيلة. مثلاً، استخدم Day.js بدلاً من Moment.js (أخف بـ 20 مرة).
• قم بتحميل الكود غير الضروري بعد FID (Lazy Load).

3.2.2.3 تحسين كود الطرف الثالث

• قم بتحميل أدوات الطرف الثالث باستخدام async أو defer.
• إذا أمكن، قم بتحميلها بعد FID باستخدام Intersection Observer أو setTimeout.
• استخدم بدائل أخف: مثلاً، استخدم Version 4 من Google Analytics (أخف وأسرع).
• فكر في استخدام خدمة "إدارة الوسوم" (Tag Manager) ولكن بحذر، لأنها قد تضيف تأخيراً أيضاً.

3.2.2.4 تجنب التفاعلات المعقدة عند التحميل

لا تقم بتشغيل معالجات أحداث معقدة أو مؤثرات حركية ثقيلة عند تحميل الصفحة. أخرها إلى ما بعد أن تصبح الصفحة جاهزة للتفاعل.

3.3 تحسين CLS (Cumulative Layout Shift) - الاستقرار البصري

يقيس CLS مقدار الحركة غير المتوقعة لعناصر الصفحة أثناء التحميل. القيمة المثالية: أقل من 0.1.

3.3.1 أسباب CLS الشائعة

• الصور أو الفيديوهات أو iframe بدون أبعاد محددة.
• الإعلانات أو العناصر المضمنة (embeds) التي تظهر متأخرة وتدفع المحتوى.
• الخطوط التي تسبب ظهور/اختفاء النص (FOIT/FOUT).
• تحديث DOM ديناميكياً بعد التحميل.

3.3.2 تقنيات تحسين CLS

3.3.2.1 حدد أبعاد الصور والفيديوهات دائماً

هذه هي القاعدة الذهبية. استخدم خاصيتي width و height في HTML، حتى لو كنت ستغيرها لاحقاً بـ CSS. المتصفح سيحسب نسبة العرض إلى الارتفاع ويحجز المساحة المناسبة.

<!-- هذا يمنع CLS -->
<img src="image.jpg" width="800" height="600" alt="description">

<!-- حتى لو أردتها عرض كامل (full-width) في CSS، الأبعاد تحجز المساحة -->
<style>
  img { width: 100%; height: auto; }
</style>

3.3.2.2 احجز مساحة للإعلانات والمكونات الديناميكية

إذا كنت تستخدم إعلانات، احجز مساحة (placeholder) بنفس الأبعاد المتوقعة للإعلان. يمكنك استخدام CSS لتحديد minimum height.

<!-- احجز مساحة للإعلان -->
<div class="ad-container" style="min-height: 250px; width: 300px;">
  <!-- الإعلان سيتم حقنه هنا لاحقاً -->
</div>

3.3.2.3 استخدم font-display: swap

عند استخدام خطوط ويب، استخدم font-display: swap في @font-face. هذا يضمن عرض النص بخط احتياطي فوراً، ثم استبداله بالخط المخصص عندما يتحمّل. هذا يمنع اختفاء النص (FOIT) ويقلل CLS.

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

3.3.2.4 تجنب إدراج محتوى فوق محتوى موجود

تجنب إدراج عناصر جديدة (مثل banners أو notifications) في أعلى الصفحة بعد أن بدأ المستخدم في القراءة. إذا كان لا بد من ذلك، احجز مساحة لها من البداية.

3.3.2.5 استخدم transform للحركات (animations)

عند تطبيق حركات، استخدم خاصية transform بدلاً من الخصائص التي تسبب إعادة تخطيط (layout/reflow) مثل top, left, width, height. الحركات باستخدام transform لا تسبب CLS.

4. تقنيات متقدمة لتحسين زمن التحميل وتجربة المستخدم

بعد فهم النظرية وإتقان Core Web Vitals، ننتقل إلى تقنيات أكثر تقدماً وتعقيداً. هذه التقنيات تتطلب فهماً أعمق لآليات عمل المتصفح وأدوات البناء.

4.1 تحسين CSS وجعله غير محجوب (CSS Optimization)

4.1.1 تقنية CSS النقدي (Critical CSS) - التنفيذ اليدوي والأدوات

الفكرة بسيطة: استخرج CSS اللازم لعرض الجزء المرئي من الصفحة (Above the Fold) وضعه مباشرة في <style> داخل <head>. بينما يتم تحميل باقي CSS بشكل غير متزامن. هذا يسمح للمتصفح برسم المحتوى المرئي فوراً دون انتظار تحميل جميع ملفات CSS.

كيف تستخرج CSS النقدي؟

• يدوياً: افحص الصفحة في DevTools وحدد الأنماط المطبقة على العناصر المرئية. هذه الطريقة غير عملية للتطبيقات الكبيرة.
• بأدوات: استخدم أدوات مثل Critical (أداة Node.js) أو Penthouse. هذه الأدوات تفتح الصفحة في متصفح خفي (headless browser)، وتحدد العناصر المرئية، وتستخرج CSS المرتبط بها.

<!-- مثال على الناتج النهائي -->
<!-- Critical CSS مضمن مباشرة -->
<style>
  /* CSS للهيدر، البطل (hero section)، القائمة الرئيسية، والعناصر المرئية الأخرى */
  header { background: #333; color: white; padding: 1rem; }
  .hero { height: 500px; background: url('hero-small.jpg'); display: flex; ... }
  nav ul { display: flex; list-style: none; ... }
  /* حوالي 2-5 كيلوبايت من CSS */
</style>

<!-- باقي CSS يتم تحميله بشكل غير متزامن -->
<link rel="preload" href="non-critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="non-critical.css"></noscript>

4.1.2 تجنب استخدام @import

استخدام @import داخل ملفات CSS يؤدي إلى تحميل تسلسلي، حيث لا يبدأ تحميل الملف المستورد إلا بعد تحميل وبدء معالجة الملف الأصلي. هذا يخلق تسلسلاً هرمياً بطيئاً. البديل هو استخدام عدة وسوم <link> التي تسمح بالتحميل المتوازي (parallel loading).

4.1.3 تقليل CSS غير المستخدم (Unused CSS)

مع مرور الوقت، تتراكم في مشاريع CSS الكبيرة أنماط لم تعد مستخدمة. يمكن استخدام أدوات مثل PurgeCSS أو UnCSS لتحليل HTML/JavaScript وحذف أي CSS لا يتطابق مع عناصر في الصفحة. هذا يقلل حجم ملفات CSS بشكل كبير.

4.1.4 دمج وتحسين (Minify) ملفات CSS

استخدم أدوات مثل cssnano أو clean-css لإزالة المسافات البيضاء، التعليقات، وتقصير أسماء الألوان والخصائص. هذا يقلل الحجم بنسبة 20-30%.

4.2 استراتيجيات متقدمة لتحسين JavaScript

4.2.1 تقنيات التحميل الذكي (Smart Loading Strategies)

تحديث: بدلاً من async وdefer التقليدية، يمكن استخدام تقنيات أكثر تقدماً تستند إلى سلوك المستخدم الفعلي:

• تحميل بناءً على التفاعل (Interaction-Driven Loading): تحميل الكود فقط عندما يحتاجه المستخدم فعلياً. مثال: كود التعليقات لا يُحمّل إلا عندما يقوم المستخدم بالتمرير إلى قسم التعليقات. مثال آخر: كود نموذج الاتصال لا يُحمّل إلا عندما يحوم المستخدم فوق زر "اتصل بنا".
• تحميل بناءً على الوقت الخامل (Idle Until Urgent): استخدم requestIdleCallback لتحميل الموارد غير الحرجة عندما يكون المعالج الرئيسي خاملاً (أي ليس لديه مهام ذات أولوية أعلى).
• تحميل بناءً على السرعة المتوقعة (Predictive Loading): باستخدام Machine Learning، يمكن التنبؤ بالصفحة التالية التي من المرجح أن ينتقل إليها المستخدم (بناءً على تحركات الماوس أو تاريخ التصفح) وتحميل مسبق لمواردها في الخلفية.

// مثال متقدم: تحميل كود بناءً على hover (يعني المستوى متجه للتفاعل)
const button = document.getElementById('complex-button');

button.addEventListener('mouseenter', () => {
  // المستخدم يبدي اهتماماً، نبدأ التحميل
  const loader = import('./complex-feature.js');
  
  button.addEventListener('click', async () => {
    // عند النقر، نكون قد حمّلنا بالفعل أو في طور التحميل
    const module = await loader;
    module.initComplexFeature();
  }, { once: true });
});

4.2.2 تقليل حجم الحزمة (Bundle Optimization) - أدوات وتقنيات

باستخدام أدوات مثل Webpack أو Vite أو Rollup، يمكن تطبيق تقنيات متقدمة:

• Tree Shaking - المستوى المتقدم: تأكد من أنك تستخدم وحدات ES6 (import/export) لأن Tree Shaking يعمل بشكل أفضل معها. تجنب التحميل الديناميكي الذي يربك المحلل.
• Code Splitting - استراتيجيات متعددة:
  • تقسيم حسب الصفحة (Page-based): كل صفحة تحصل على حزمة منفصلة.
  • تقسيم حسب المكون (Component-based): المكونات الثقيلة (مثل محرر نصوص، رسم بياني) تُحمّل عند الحاجة فقط.
  • تقسيم حسب المسار (Route-based): في تطبيقات SPA، يتم تحميل كود المسار الجديد فقط عند الانتقال إليه.
• تحليل الحزمة (Bundle Analysis): استخدم أدوات مثل Webpack Bundle Analyzer أو Vite Bundle Visualizer لاكتشاف المكتبات الكبيرة غير الضرورية أو الازدواجية (duplication). قد تكتشف أنك تستخدم نسختين من نفس المكتبة!
• Module Concatenation: في Webpack، يسمح "Scope Hoisting" بدمج الوحدات في نطاق واحد، مما يقلل من عدد الدوال ويحسن وقت التنفيذ.

4.3 تحسين الصور والوسائط المتعددة بشكل احترافي

4.3.1 الصيغ الحديثة والتحويل التلقائي - AVIF و WebP و JPEG XL

استخدم عنصر <picture> مع صيغ متعددة لتوفير أفضل صيغة يدعمها المتصفح. الترتيب مهم: ضع الصيغ الأحدث أولاً.

<picture>
  <source srcset="image.avif" type="image/avif"> <!-- الأفضل، يدعمه Chrome و Firefox حديثاً -->
  <source srcset="image.webp" type="image/webp"> <!-- دعم واسع -->
  <img src="image.jpg" alt="وصف" loading="lazy" width="800" height="600"> <!-- خيار احتياطي -->
</picture>

مقارنة الصيغ:

• JPEG: قديم، حجم كبير نسبياً.
• PNG: للصور ذات الشفافية، حجم كبير جداً.
• WebP: يقدم ضغطاً أفضل من JPEG بنسبة 25-35% مع جودة مماثلة. يدعم الشفافية والرسوم المتحركة.
• AVIF: الصيغة الأحدث، يقدم ضغطاً أفضل من WebP بنسبة 20-30% إضافية. جودة فائقة بحجم أصغر. لكن دعمه ليس كاملاً بعد.
• JPEG XL: صيغة واعدة جداً، تتفوق على AVIF في بعض الجوانب، لكن دعمها محدود حالياً.

4.3.2 الاستجابة والتحميل الذكي (Responsive Images with srcset and sizes)

استخدم سمة srcset لتوفير أحجام مختلفة من الصورة حسب دقة الشاشة، وسمة sizes لإخبار المتصفح بالمساحة التي ستشغلها الصورة في تخطيطات مختلفة. هذا يسمح للمتصفح بتحميل الحجم المناسب فقط.

<img 
  srcset="image-320w.jpg 320w,
          image-640w.jpg 640w,
          image-1280w.jpg 1280w,
          image-2560w.jpg 2560w"
  sizes="(max-width: 320px) 280px,
         (max-width: 640px) 600px,
         (max-width: 1200px) 1100px,
         1920px"
  src="image-1280w.jpg"
  alt="وصف">

كيف يعمل؟ المتصفح يعرف عرض منفذ العرض (viewport width) وكثافة البكسلات (DPR). يستخدم هذه المعلومات مع قواعد sizes ليقرر أي صورة من srcset هي الأنسب ويحمّلها.

4.3.3 تقنيات متقدمة للصور

• تحميل كسول باستخدام Intersection Observer (بدلاً من loading="lazy"): بينما سمة loading="lazy" أسهل، فإن Intersection Observer يمنح تحكماً أكبر. يمكنك تحديد مسافة إضافية (rootMargin) لبدء التحميل قبل أن تصبح الصورة مرئية، مما يخلق تجربة أكثر سلاسة.

// تحميل كسول متقدم
const images = document.querySelectorAll('img[data-src]');
const imageObserver = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src; // تعيين المصدر الحقيقي
      img.onload = () => img.classList.add('loaded'); // إضافة تأثير عند التحميل
      imageObserver.unobserve(img);
    }
  });
}, {
  rootMargin: '200px 0px' // ابدأ التحميل قبل 200 بكسل من الظهور
});

images.forEach(img => imageObserver.observe(img));

• استخدام placeholders وتقنية LQIP (Low Quality Image Placeholders): عرض نسخة منخفضة الجودة جداً (مشوشة، أو لون خالص) أثناء تحميل الصورة الرئيسية. هذا يحسن الإدراك البصري ويقلل من الشعور بالانتظار.
• تقنية SQIP (SVG-based LQIP): توليد نسخة SVG مبسطة جداً من الصورة. SVG حجمه صغير جداً ويبدو أفضل من الصور المشوشة.
• تأجيل تحميل الصور غير المرئية (Offscreen Images): في الصفحات الطويلة (infinite scroll)، لا تقم بتحميل الصور إلا عندما تكون على وشك الظهور.

4.4 تحسين الخطوط (Font Optimization)

الخطوط يمكن أن تكون مصدراً رئيسياً لـ CLS و FOUT/FOIT. إليك أفضل الممارسات:

4.4.1 استخدم font-display: swap (كما ذكرنا)

هذا أهم شيء. يضمن ظهور النص بخط احتياطي فوراً.

4.4.2 استخدم تنسيق WOFF2

WOFF2 يقدم أفضل ضغط للخطوط. تجاهل التنسيقات القديمة (TTF, OTF) إلا للتوافق مع متصفحات قديمة جداً.

4.4.3 قم بتضمين الخطوط الحرجة فقط (Subsetting)

إذا كنت تستخدم خطاً عربياً أو إنجليزياً، فأنت غالباً لا تحتاج إلى جميع الرموز (glyphs) في الخط. استخدم أدوات مثل `glyphhanger` أو خدمة Google Fonts مع تحديد `&text=` لتضمين الأحرف التي تستخدمها فقط. هذا يقلل حجم ملف الخط بشكل كبير (قد يصل إلى 90%).

<!-- مثال من Google Fonts مع subset للأحرف اللاتينية فقط -->
<link href="https://fonts.googleapis.com/css2?family=Roboto&text=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" rel="stylesheet">

4.4.4 استخدم preload للخطوط الحرجة

إذا كان الخط ضرورياً للنصوص المرئية فوراً، استخدم preload.

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

ملاحظة: خاصية crossorigin مطلوبة حتى مع الخطوط من نفس النطاق إذا تم تحميلها عبر preload.

4.4.5 تجنب استخدام @import لخطوط Google

استخدم <link> بدلاً من @import لأن <link> لا يحجب الـ render tree بالطريقة نفسها.

5. استراتيجيات التخزين المؤقت المتقدمة - من المتصفح إلى الحافة

التخزين المؤقت (Caching) هو أحد أقوى أدوات تحسين الأداء، لكن تطبيقه يتطلب فهماً دقيقاً لخيارات المتصفح والخادم وCDN المختلفة. التخزين المؤقت الجيد يمكن أن يجعل الزيارات المتكررة فورية تقريباً.

5.1 أعمدة التخزين المؤقت الثلاثة (The Three Pillars of Caching)

5.1.1 التخزين المؤقت في المتصفح (Browser Cache) - إتقان رؤوس HTTP

من خلال رؤوس HTTP، يمكن توجيه المتصفح لتخزين الموارد محلياً على جهاز المستخدم. هذا هو أسرع أنواع التخزين المؤقت (زمن وصول = 0).

• Cache-Control: max-age=31536000: للموارد الثابتة (الصور، CSS، JS) التي لا تتغير أبداً أو نادراً. استخدم "Cache Busting" (تغيير اسم الملف عند التحديث) لضمان حصول المستخدمين على الإصدار الجديد عندما يتغير المحتوى.
• Cache-Control: no-cache: لمستندات HTML. هذا لا يعني "عدم التخزين"، بل يعني "التحقق من الخادم قبل استخدام النسخة المخزنة" (revalidation).
• Cache-Control: must-revalidate: يمكن استخدامها مع max-age لضمان إعادة التحقق بعد انتهاء الصلاحية.
• ETag (Entity Tag): هو معرف فريد (بصمة) للمورد. عندما يعيد المستخدم زيارة الصفحة، يرسل المتصفح ETag المخزن في طلب `If-None-Match`. إذا كان ETag على الخادم مطابقاً، يرد الخادم بـ `304 Not Modified` (بدون إرسال المورد مرة أخرى)، مما يوفر الوقت. ETag أكثر دقة من Last-Modified.
• Last-Modified: تاريخ آخر تعديل. يرسل المتصفح `If-Modified-Since`. أقل دقة من ETag.

استراتيجية متقدمة: يمكن الجمع بين الاستراتيجيات:

# لملفات CSS/JS/Images
Cache-Control: public, max-age=31536000, immutable

# لملف HTML
Cache-Control: public, no-cache, must-revalidate

5.1.2 Service Workers و Cache API - برمجة التخزين المؤقت

تسمح Service Workers بتحكم برمجي كامل في التخزين المؤقت، مما يمكن من:

• استراتيجيات متعددة للتخزين المؤقت:
  • Cache First (أو Cache Only): للموارد الثابتة تماماً. تخدم من cache، وإذا لم توجد، تجلب من الشبكة (أو تفشل).
  • Network First (أو Network Only): للبيانات الحساسة (مثل رصيد البنك). تحاول الشبكة أولاً، وإذا فشلت (offline)، تلجأ للكاش.
  • Stale-While-Revalidate (الأكثر شيوعاً للتطبيقات): عرض المورد المخزن فوراً (حتى لو كان قديماً)، وفي نفس الوقت، ترسل طلباً للشبكة لتحديث الكاش للزيارة القادمة. هذا يعطي سرعة فورية مع ضمان تحديث المحتوى في الخلفية.
  • Cache & Network Race: ترسل طلباً للكاش والشبكة في نفس الوقت، وتستخدم أيهما يستجيب أولاً.
• التخزين المؤقت للصفحات الكاملة (Offline First): باستخدام Service Worker، يمكن تخزين كل موارد التطبيق (App Shell) وحتى البيانات، مما يجعل التطبيق يعمل دون اتصال بالإنترنت بشكل كامل أو جزئي (مثل تطبيقات Google Docs).
• مزامنة البيانات في الخلفية (Background Sync): يمكن لـ Service Worker انتظار اتصال الإنترنت لإرسال البيانات التي تم إنشاؤها دون اتصال. مثلاً، إرسال رسالة أو تحديث بيانات عندما يعود الاتصال.

// مثال على استراتيجية Stale-While-Revalidate في Service Worker
self.addEventListener('fetch', event => {
  event.respondWith(
    caches.open('my-dynamic-cache').then(cache => {
      return cache.match(event.request).then(cachedResponse => {
        // وعد (Promise) بالتحديث في الخلفية
        const fetchPromise = fetch(event.request).then(networkResponse => {
          // تخزين الرد الجديد للاستخدام المستقبلي
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        }).catch(error => {
          console.log('فشل تحديث الشبكة:', error);
          // يمكن إعادة cachedResponse هنا إذا فشلت الشبكة
        });
        
        // نعيد الرد المخزن فوراً (أو ننتظر fetch إذا لم يكن مخزناً)
        return cachedResponse || fetchPromise;
      });
    })
  );
});

5.1.3 CDN والتخزين المؤقت على الحافة (Edge Caching) - المستوى العالمي

شبكات توصيل المحتوى (CDN) لا تقلل فقط زمن الوصول (Latency) بتوزيع المحتوى جغرافيا (نسخ الملفات على خوادم حول العالم)، بل توفر أيضاً طبقة تخزين مؤقت قوية على "الحافة" (Edge) - أي أقرب خادم للمستخدم.

• كيف يعمل: عندما يطلب مستخدم ملفاً من موقع يستخدم CDN، يتم توجيه الطلب إلى أقرب خادم "حافة". إذا كان الملف مخزناً مؤقتاً على ذلك الخادم (cache hit)، يتم إرساله فوراً. إذا لم يكن (cache miss)، يتوجه الخادم إلى "الخادم الأصلي" (Origin Server) الخاص بك، ويخزن نسخة منه للمستقبل.
• Purge APIs: توفر CDNs واجهات برمجية لمسح المحتوى المحدث فوراً (Cache Invalidation) عند نشر تحديثات.
• Edge Side Includes (ESI): لغة ترميز تسمح بتخزين أجزاء من الصفحة بشكل منفصل على الـ CDN. مثلاً: يمكن تخزين الهيدر والفوتر (وهما ثابتان) لكل الصفحات، بينما يتم دمج المحتوى الديناميكي (المقال) من الخادم الأصلي. هذا يقلل الحمل على الخادم ويسرع التوصيل.
• Dynamic content caching: حتى استجابات APIs الديناميكية يمكن تخزينها مؤقتاً على CDN إذا كان ذلك مقبولاً. يمكن ضبط TTL (Time To Live) مناسب (مثلاً، 60 ثانية) لتقليل الضغط على الخادم.

5.2 استراتيجيات متقدمة لتحسين الشبكة (Network Optimization)

5.2.1 HTTP/2 و HTTP/3 - القفزة النوعية

الانتقال إلى HTTP/2 يقدم فوائد هائلة مقارنة بـ HTTP/1.1:

• مضاعفة الطلبات (Multiplexing): في HTTP/1.1، المتصفح يفتح عدة اتصالات TCP بالتوازي (عادة 6) لتحميل الموارد. HTTP/2 يسمح بإرسال واستقبال طلبات متعددة عبر اتصال TCP واحد. هذا يحل مشكلة "Head-of-Line Blocking" ويحسن الأداء خاصة مع المواقع التي لديها العديد من الموارد.
• ضغط الهيدرات (Header Compression): HTTP/2 يضغط رؤوس HTTP (التي قد تكون كبيرة) باستخدام خوارزمية HPACK، مما يقلل حجم البيانات المرسلة.
• دفع الخادم (Server Push): تسمح للخادم بإرسال الموارد التي يعرف أن المتصفح سيحتاجها (مثل CSS و JavaScript المرتبطة بصفحة HTML) قبل أن يطلبها المتصفح صراحة. لكن يجب استخدامها بحذر شديد لأنها قد تسبب إهداراً للنطاق الترددي إذا لم يحتجها المتصفح فعلاً.

أما HTTP/3 فيضيف تحسينات إضافية جذرية باستخدام بروتوكول QUIC (الذي يعتمد على UDP بدلاً من TCP). فوائده:

• تسريع إنشاء الاتصال (0-RTT): في بعض الحالات، يمكن إنشاء الاتصال دون أي تأخير (zero round trip).
• تحسين الأداء في الشبكات الضعيفة: QUIC يتعامل بشكل أفضل مع فقدان الحزم ولا يسبب حجباً لبقية البيانات كما في TCP.
• التحكم في التدفق لكل تيار (Stream): إذا فقدت حزمة في تيار واحد، لا يؤثر ذلك على بقية التيارات.

5.2.2 تقنيات Preload و Preconnect و Prefetch و Prerender - دليل الاستخدام

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

<!-- 1. Preconnect: يخبر المتصفح بأننا سنتصل بهذا الخادم قريباً. يقوم بحل DNS وإنشاء اتصال TCP/TLS مسبقاً. -->
<link rel="preconnect" href="https://fonts.googleapis.com">

<!-- 2. dns-prefetch: مشابه لـ preconnect لكن فقط لحل DNS. أقل تكلفة، مفيد للنطاقات التي سنتواصل معها ولكن لسنا متأكدين. -->
<link rel="dns-prefetch" href="https://analytics.google.com">

<!-- 3. Preload: يحمل المورد الضروري للصفحة الحالية بأعلى أولوية. مثالي لـ LCP images, fonts, critical scripts/styles. -->
<link rel="preload" href="critical-style.css" as="style">
<link rel="preload" href="hero-image.webp" as="image">
<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

<!-- 4. Prefetch: يحمل موارد للصفحة التالية التي من المحتمل أن يذهب إليها المستخدم. بأولوية منخفضة، في وقت الخمول. -->
<link rel="prefetch" href="/next-page" as="document">
<link rel="prefetch" href="/next-page-style.css" as="style">

<!-- 5. Prerender: (استخدم بحذر شديد) يطلب من المتصفح عرض الصفحة التالية بالكامل في الخلفية. مكلف جداً للموارد. -->
<link rel="prerender" href="/next-page">

متى تستخدم كل منها؟

• preconnect/dns-prefetch: للنطاقات التي تعرف أنك ستستخدمها (مثل CDN للصور، API خارجي).
• preload: للموارد الحرجة التي تكتشف متأخراً في HTML (مثل الصورة البطل، الخطوط، CSS المهم). لا تفرط في استخدامه.
• prefetch: للصفحات التالية بناءً على تحليلات (مثلاً، بعد قراءة المقال، من المحتمل أن يذهب المستخدم لصفحة "اتصل بنا").
• prerender: فقط إذا كنت متأكداً بنسبة 100% من الصفحة التالية (مثل معالج الدفع متعدد الخطوات).

6. أدوات القياس والتشخيص المتقدمة - معمل الأداء الخاص بك

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

6.1 أدوات Google Core Web Vitals - رزمة الأدوات الرسمية

6.1.1 PageSpeed Insights (PSI) - البوابة الرئيسية

أداة تجمع بين البيانات المعملية (من Lighthouse) والبيانات الحقلية (من CrUX - Chrome User Experience Report). تقدم توصيات محددة وقابلة للتنفيذ لكل مشكلة. استخدمها كأداة أولية لتقييم أي صفحة.

مهم: انظر إلى قسم "Field Data" أولاً. إذا كانت البيانات الحقلية سيئة، فهذه مشكلة حقيقية يواجهها مستخدمون حقيقيون. استخدم "Lab Data" لمساعدتك في تشخيص الأسباب.

6.1.2 Google Search Console - تقارير Core Web Vitals

تقدم تقارير Core Web Vitals مصنفة حسب مجموعات الصفحات (صفحات المقالات، صفحات المنتجات، إلخ). تحدد المشكلات الرئيسية وتعطيك أمثلة على عناوين URL المتأثرة. هذا يساعدك في تحديد أولويات التحسين (أي مجموعة صفحات هي الأسوأ).

6.1.3 Web Vitals JavaScript Library (لجمع البيانات الخاصة بك)

مكتبة صغيرة (أقل من 2KB) تتيح قياس مؤشرات الأداء الأساسية في تطبيقك مباشرة وإرسالها إلى تحليلاتك الخاصة (مثل Google Analytics أو أي نظام RUM). هذا يعطيك صورة مستمرة عن أداء تطبيقك عبر جميع المستخدمين.

// مثال متقدم: إرسال المقاييس إلى Google Analytics 4
import {onLCP, onFID, onCLS, onINP} from 'web-vitals';

function sendToAnalytics(metric) {
  // يمكنك إرسال المقياس كحدث إلى GA4
  gtag('event', metric.name, {
    value: metric.value,
    rating: metric.rating, // 'good', 'needs-improvement', 'poor'
    id: metric.id,
    navigationType: metric.navigationType,
    // يمكن إضافة أبعاد مخصصة: صفحة، جهاز، بلد...
  });
}

onLCP(sendToAnalytics);
onFID(sendToAnalytics);
onCLS(sendToAnalytics);
onINP(sendToAnalytics); // المقياس الجديد

6.2 أدوات متقدمة للتشخيص العميق (Deep Diagnostics)

6.2.1 WebPageTest - صندوق الأدوات المتكامل

أداة متقدمة ومجانية (مع خيارات مدفوعة) تسمح باختبار الأداء من مواقع مختلفة حول العالم، مع إمكانية محاكاة سرعات شبكة مختلفة (3G بطيء، 4G)، وأجهزة متنوعة (هاتف Moto G4 محاكى). تقدم تحليلاً مفصلاً لا يضاهى:

• Filmstrip View: يظهر لك كيف تظهر الصفحة للمستخدم لحظة بلحظة (بالثواني).
• Waterfall View: تحليل متقدم لجميع الطلبات، يظهر لك بوضوح ما الذي يحجب ماذا، وتأثير كل مورد.
• Connection View: يظهر لك كيف تم إنشاء اتصالات TCP و TLS.
• Main Thread Breakdown: يظهر لك كيف استهلك المعالج الرئيسي وقته (Style & Layout, Parse HTML, Evaluate Script...).
• Lighthouse Audit: مدمج معه.

6.2.2 Chrome DevTools - الأدوات المتكاملة (Performance, Coverage, Network)

أدوات لا غنى عنها لتحليل الأداء بدقة. تعلمها بعمق:

• Performance Tab: سجل جلسة تفاعل كاملة. تعلم قراءة "Flame Chart" لتحديد المهام الطويلة (Long Tasks) التي تستهلك الوقت. انظر إلى أقسام "Summary" لفهم أين ذهب الوقت (Loading, Scripting, Rendering, Painting). استخدم "Bottom-Up" أو "Call Tree" لمعرفة الدوال الأكثر استهلاكاً للوقت.
• Network Tab: راقب تسلسل تحميل الموارد، وأولوياتها، ووقت كل منها. استخدم "Capture Screenshots" لرؤية كيف تظهر الصفحة مع الوقت. انظر إلى "Waterfall" لفهم تأثير كل طلب.
• Coverage Tab: شغّل التسجيل وأعد تحميل الصفحة. سترى أي أجزاء من CSS و JavaScript تم استخدامها فعلياً، وأيها لم يستخدم (unused code). هذا مفيد جداً لتحسين Tree Shaking.
• Memory Tab: لتحليل تسربات الذاكرة (Memory Leaks) التي قد تؤدي لبطء تدريجي مع مرور الوقت.
• Lighthouse Tab: مدمج مباشرة.

6.2.3 أدوات متخصصة أخرى

• Bundle Analyzers (Webpack Bundle Analyzer, Vite Bundle Visualizer): لتحليل حزم JavaScript ومعرفة مكوناتها.
• Sitespeed.io: أداة مفتوحة المصدر لتشغيل اختبارات أداء آلية ومستمرة، مع توليد تقارير وتخزين تاريخي للبيانات.
• Calibre / SpeedCurve: خدمات مدفوعة لمراقبة الأداء بشكل مستمر (RUM + Lab) مع إنذارات وتقارير.

7. دراسة حالة متعمقة: تحويل أداء تطبيق تجارة إلكترونية (150 صفحة)

لنطبق كل المفاهيم التي تعلمناها على دراسة حالة حقيقية وموسعة. تخيل أننا أمام متجر إلكتروني متوسط الحجم (150 صفحة منتج، 30 صفحة فئة، نظام عربة تسوق، دفع) يعاني من أداء ضعيف جداً: مؤشر LCP = 4.8 ثوانٍ، FID = 320ms، CLS = 0.35. هذا يؤثر بشدة على المبيعات (معدل تحويل 2.1% فقط).

7.1 مرحلة التشخيص الأولي - جمع الأدلة

باستخدام مزيج من PageSpeed Insights و WebPageTest و Chrome DevTools، تم اكتشاف المشكلات التالية بالتفصيل:

7.1.1 نتائج القياس الأولية

• LCP: 4.8 ثانية. العنصر الأكبر كان صورة المنتج الرئيسية (صفحة المنتج) وصورة البطل (الصفحة الرئيسية).
• FID: 320ms (بيانات حقلية من CrUX).
• CLS: 0.35. بسبب صور بدون أبعاد محددة وإعلانات تظهر متأخرة.
• TTFB: 1.2 ثانية (مرتفع جداً).
• Total Blocking Time (TBT): 850ms.

7.1.2 التشخيص التفصيلي - قائمة المشكلات

• JavaScript:
  • إجمالي حجم JS: 3.2 ميجابايت (بعد الضغط).
  • استخدام مكتبات قديمة وثقيلة: jQuery UI (غير مستخدم بالكامل)، Moment.js (يمكن استبداله بـ Day.js).
  • عدم استخدام Code Splitting: كل التطبيق في حزمة واحدة (single bundle).
  • كود الطرف الثالث: 8 أدوات مختلفة (تحليلات، إعلانات، دردشة، مراجعات) كلها تُحمّل بطريقة محجوبة.
• CSS:
  • ملف CSS واحد كبير (250 كيلوبايت) يحجب العرض.
  • استخدام `@import` داخل ملف CSS.
  • وجود الكثير من CSS غير المستخدم (Coverage tab أظهر 65% unused).
• الصور:
  • صور المنتج بدقة 4000x3000 بكسل يتم تصغيرها عبر CSS فقط. حجمها حوالي 2-3 ميجابايت للصورة.
  • صيغة JPEG فقط، لا WebP ولا AVIF.
  • لا تحميل كسول (Lazy Loading) للصور أسفل الصفحة.
  • لا أبعاد محددة (width/height) في HTML، مما يسبب CLS شديد.
• الخادم والشبكة:
  • لا استخدام لـ CDN.
  • لا تخزين مؤقت فعال (رؤوس Cache-Control غير مضبوطة).
  • HTTP/1.1 قيد الاستخدام.
  • TTFB مرتفع بسبب خادم بطيء واستعلامات قاعدة بيانات غير محسنة.
• الخطوط:
  • ثلاث خطوط ويب مختلفة.
  • لا استخدام لـ font-display: swap.
  • تحميل جميع الخطوط حتى لو لم تكن مستخدمة.

7.2 الخطة العلاجية - مشروع التحسين (Performance Project Plan)

تم تشكيل فريق صغير (مهندسا أداء، مطور واجهات) لوضع خطة عمل على 3 مراحل (كل مرحلة أسبوعان) مع تحديد الأولويات (High Impact First).

7.2.1 المرحلة الأولى: التحسينات السريعة عالية التأثير (Quick Wins)

الأهداف: تحسين LCP و CLS بسرعة.

• تحسين الصور (فوري):
  • تحويل جميع صور المنتج والصفحة الرئيسية إلى WebP (بجودة 85%) مع الاحتفاظ بـ JPEG كخيار احتياطي. استخدام <picture>. النتيجة: انخفاض وزن الصور من متوسط 2 ميجابايت إلى 400 كيلوبايت.
  • إضافة أبعاد (width="800" height="800") لجميع الصور في HTML.
  • تفعيل التحميل الكسول (loading="lazy") للصور خارج الشاشة.
  • إضافة preload لصورة LCP (البطل أو أول صورة منتج).
• تحسين الخطوط (سريع):
  • إضافة `font-display: swap` لجميع تعريفات الخطوط.
  • استخدام preload للخط الرئيسي.
• تحسين CSS (سريع):
  • استخراج CSS النقدي (حوالي 5 كيلوبايت) للصفحة الرئيسية وصفحة المنتج باستخدام أداة Critical، ووضعه في <style> في <head>.
  • تحميل باقي CSS بشكل غير متزامن.
  • إزالة `@import` واستبداله بـ <link>.
• نتائج المرحلة الأولى: LCP انخفض إلى 3.2 ثانية، CLS إلى 0.15. تحسن ملحوظ.

7.2.2 المرحلة الثانية: إعادة هيكلة JavaScript وتقليل الحجم

الأهداف: تحسين FID و TTI بشكل جذري.

• تحليل وتقليل الحزمة:
  • استخدام Webpack Bundle Analyzer. اكتشاف أن 20% من الحزمة هي Moment.js (المستخدمة فقط لتنسيق تاريخ بسيط). استبدالها بـ Day.js (توفير 200 كيلوبايت).
  • إزالة jQuery UI (غير مستخدم) بالكامل.
  • تطبيق Tree Shaking الصارم.
• تقسيم الكود (Code Splitting):
  • تقسيم حسب الصفحة (page-based): كل صفحة (رئيسية، منتج، فئة، عربة) تحصل على حزمة منفصلة. هذا يقلل حجم JS المحمل للصفحة الواحدة إلى 300-400 كيلوبايت بدلاً من 3.2 ميجابايت.
  • تقسيم حسب المكون: مكونات مثل "معرض الصور" و "نظام المراجعات" و "الدردشة" تُحمّل بشكل كسول (lazy) فقط عندما تظهر أو عندما يتفاعل المستخدم معها.
• تحسين كود الطرف الثالث:
  • تأجيل تحميل جميع أدوات الطرف الثالث حتى بعد LCP (باستخدام setTimeout أو requestIdleCallback).
  • استخدام async/defer حيثما أمكن.
  • تحميل أداة الدردشة فقط عندما يقوم المستخدم بالتمرير إلى أسفل الصفحة أو يحوم فوق زر الدردشة.
• تقسيم المهام الطويلة: تحسين الكود الذي يعالج قوائم المنتجات الكبيرة ليتم على أجزاء باستخدام تقنية التقطيع (chunking).
• نتائج المرحلة الثانية: FID انخفض من 320ms إلى 95ms. TTI من 5.6 ثانية إلى 2.8 ثانية. LCP تحسن أكثر إلى 2.4 ثانية.

7.2.3 المرحلة الثالثة: تحسين البنية التحتية والخادم (Infrastructure & Caching)

الأهداف: تحسين TTFB والاستفادة من التخزين المؤقت.

• تفعيل CDN: استخدام Cloudflare (أو أي CDN) مع تخزين مؤقت للموارد الثابتة (صور، CSS، JS) على الحافة.
• تحسين الخادم:
  • إضافة التخزين المؤقت لاستعلامات قاعدة البيانات.
  • تحسين استعلامات SQL البطيئة.
  • الترقية إلى خادم أسرع أو زيادة الموارد.
• ضبط رؤوس التخزين المؤقت:
  • للموارد الثابتة: `Cache-Control: public, max-age=31536000, immutable` مع تغيير أسماء الملفات عند التحديث (Cache Busting).
  • لـ HTML: `Cache-Control: public, no-cache, must-revalidate` مع استخدام ETag.
• تفعيل HTTP/2 (والاستعداد لـ HTTP/3): على الخادم و CDN.
• تنفيذ Service Worker:
  • تخزين App Shell (الهيدر، الفوتر، CSS الأساسي) للاستخدام دون اتصال.
  • استخدام استراتيجية Stale-While-Revalidate لصفحات المنتج لتسريع الزيارات المتكررة.
  • تخزين صور المنتج التي تمت مشاهدتها مؤقتاً.
• نتائج المرحلة الثالثة: TTFB انخفض من 1.2 ثانية إلى 300ms. تحسن عام في جميع المقاييس. الزيارات المتكررة أصبحت فورية تقريباً.

7.3 النتائج النهائية - التحليل الكمي

بعد تنفيذ المراحل الثلاث، تم إعادة القياس بنفس الظروف (نفس الأداة، نفس الموقع الجغرافي، نفس سرعة الشبكة المحاكاة). النتائج كانت مذهلة:

7.4 التأثير على الأعمال (Business Impact)

التحسينات التقنية ترجمت مباشرة إلى نتائج أعمال ملموسة بعد شهر من التطبيق الكامل:

• معدل التحويل (Conversion Rate): ارتفع من 2.1% إلى 3.4% (▲ 62%). هذا يعني إيرادات إضافية تقدر بـ 1.3 مليون دولار سنوياً لمتجر بهذا الحجم.
• معدل الارتداد (Bounce Rate): انخفض من 45% إلى 32% (▲ 29%).
• متوسط مدة الجلسة: زاد من دقيقة و45 ثانية إلى 3 دقائق و10 ثوانٍ (▲ 81%).
• رضا العملاء (CSAT): تحسنت درجات رضا العملاء المتعلقة بسرعة الموقع بشكل ملحوظ.
• SEO: تحسن ترتيب الكلمات المفتاحية الرئيسية في Google، وزادت الزيارات العضوية بنسبة 15% خلال 3 أشهر.

هذه الأرقام تؤكد أن الاستثمار في تحسين الأداء ليس تكلفة، بل هو استثمار استراتيجي ذو عائد مضمون (ROI مرتفع جداً). في هذا المثال، تحسن معدل التحويل بنسبة 62%، مما يعني إيرادات إضافية بمئات الآلاف من الدولارات سنوياً لمتجر بهذا الحجم.

8. الاتجاهات المستقبلية وأفق 2025 وما بعدها

يتطور مجال أداء الويب بسرعة مذهلة. إليك أبرز الاتجاهات التي ستشكل المستقبل القريب والبعيد:

8.1 الأطر المحسّنة افتراضياً (Performance by Default Frameworks)

أطر العمل الحديثة مثل Next.js (مع App Router)، Nuxt.js، SvelteKit، و Remix تتبنى مبدأ "التحسين الافتراضي". فبدلاً من أن تكون مسؤولاً عن تطبيق تقنيات الأداء يدوياً، تقوم هذه الأطر بتطبيق أفضل الممارسات تلقائياً:

• تقسيم الكود تلقائي (Automatic Code Splitting).
• تحسين الصور التلقائي (مع مكونات `` في Next.js).
• التحميل المسبق للصفحات المتوقعة (بناءً على روابط في منفذ العرض).
• Server Components في React: تتيح عرض المكونات على الخادم دون إرسال JavaScript الخاص بها إلى العميل، مما يقلل حجم الحزمة بشكل جذري.

8.2 تقنية Islands Architecture (جزيرة التفاعل)

نهج جديد في بناء تطبيقات الويب (روجته أطر مثل Astro و Qwik) يقوم على تقديم HTML ثابتاً تماماً (static) مع "جزر" تفاعلية صغيرة (small islands of interactivity). هذه الجزر تُحمّل بشكل مستقل ويمكن أن تعمل دون التأثير على بقية الصفحة. هذا يقلل حجم JavaScript المرسل إلى الحد الأدنى ويحسن مؤشر TTI بشكل كبير. تخيل صفحة مقالة: النص ثابت (HTML)، والقائمة المنسدلة (dropdown) هي جزيرة تفاعلية صغيرة، والتعليقات (comments) جزيرة أخرى. هذا النهج يهاجم المشكلة من جذورها: عدم إرسال JavaScript إلا للعناصر التي تحتاجه فعلاً.

8.3 WebAssembly (Wasm) في تحسين الأداء

يسمح WebAssembly بتنفيذ كود مكتوب بلغات أخرى (C++, Rust, Go) في المتصفح بسرعة قريبة من السرعة الأصلية (near-native speed). هذا يمكن من:

• نقل المهام الثقيلة حسابياً (معالجة الفيديو، الألعاب، التشفير، النمذجة ثلاثية الأبعاد) إلى Wasm، مما يخفف الحمل عن JavaScript ويكون أسرع بكثير.
• إعادة استخدام مكتبات ضخمة مكتوبة بلغات أخرى في تطبيقات الويب.
• تطبيقات مثل Google Earth و Figma تستخدم Wasm بالفعل.

8.4 الحوسبة على الحافة (Edge Computing) - الأداء فائق السرعة

بدلاً من تشغيل الكود على خادم مركزي واحد، يتم تشغيله على شبكة الحافة (خوادم CDN المنتشرة حول العالم). هذا يقرب المنطق البرمجي (logic) من المستخدم، مما يقلل زمن الوصول (latency) إلى الحد الأدنى. أمثلة:

• Edge Functions (Cloudflare Workers, Vercel Edge Functions, Deno Deploy): تسمح بتشغيل كود JavaScript/TypeScript على الحافة. يمكن استخدامها لتخصيص المحتوى، إعادة كتابة الطلبات، المصادقة، كل ذلك دون تأخير كبير.
• Edge Caching المتقدم: تخزين استجابات APIs ديناميكية جزئياً على الحافة.
• Edge Rendering: عرض الصفحات (Server-Side Rendering) على الحافة، مما يوفر وقت الرحلة من/إلى الخادم الأصلي.

8.5 مؤشرات أداء جديدة (New Web Vitals)

تعمل Google ومنظمة W3C باستمرار على تطوير مؤشرات أداء جديدة لتغطية جوانب أكثر دقة من تجربة المستخدم:

• Interaction to Next Paint (INP): (هام) سيحل محل FID كمؤشر أساسي (Core Web Vital) في مارس 2024. INP يقيس زمن استجابة جميع التفاعلات (نقرات، لمسات، ضغطات أزرار) خلال زيارة المستخدم، وليس فقط أول تفاعل. هذا يعطي صورة أشمل عن استجابة التطبيق طوال الجلسة. تحسين INP يتطلب تحسين معالجة الأحداث وتجنب المهام الطويلة.
• Time to First Byte (TTFB) محسّن: معايير أكثر صراحة لزمن استجابة الخادم، مع التركيز على وقت بدء تحميل المحتوى.
• Responsiveness Metrics: قياس دقيق لمدى استجابة التطبيق خلال التفاعلات المتعددة والمتزامنة.
• Smoothness Metrics: قياس سلاسة الحركات (animations) والتمرير (scrolling).

8.6 الذكاء الاصطناعي والتعلم الآلي في تحسين الأداء (AI/ML for Performance)

الذكاء الاصطناعي بدأ يلعب دوراً متزايداً في هذا المجال:

• التخمين المسبق (Speculative Loading): يمكن لنماذج التعلم الآلي تحليل سلوك المستخدم (حركة الماوس، المسار الشائع) للتنبؤ بالصفحة التالية بدقة عالية، والبدء في تحميلها (prefetch) أو حتى عرضها (prerender) في الخلفية.
• تحسين الصور الذكي: خدمات مثل Cloudinary تستخدم الذكاء الاصطناعي لاختيار أفضل درجة ضغط وجودة لكل صورة بناءً على المحتوى (وجه، منظر طبيعي، منتج) دون التضحية بالجودة المدركة.
• تحديد أولويات الموارد ديناميكياً: يمكن للذكاء الاصطناعي، بناءً على اتصال المستخدم وقوة جهازه، تحديد أولويات تحميل الموارد بشكل ديناميكي.
• اكتشاف حالات الشذوذ (Anomaly Detection): أنظمة مراقبة الأداء تستخدم الذكاء الاصطناعي للكشف التلقائي عن أي تراجع غير طبيعي في الأداء قبل أن يؤثر على أعداد كبيرة من المستخدمين.

9. خاتمة موسعة وتوصيات استراتيجية

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

الخلاصة الشاملة (The Big Picture)

تحسين الأداء هو رحلة مستمرة، دورة حياة متكاملة (Performance Lifecycle)، وليس وجهة نهائية يمكن الوصول إليها ثم نسيانها. مع كل تحديث للمتصفح، مع كل ميزة جديدة نضيفها، مع كل مكتبة نستخدمها، يمكن للأداء أن يتراجع. لذلك، يجب أن يكون جزءاً لا يتجزأ من ثقافة فريق التطوير وعملية التطوير ذاتها (Shift Left).

التوصيات النهائية - منهج عمل متكامل (Actionable Framework)

إليك إطار عمل عملي يمكن لأي فريق تطوير اتباعه لضمان أداء عالٍ ومستدام:

1. التأسيس: قياس ووضع خط الأساس (Baseline):
   • حدد مؤشرات الأداء الرئيسية (KPIs) التي تهمك: Core Web Vitals هي الأهم، ولكن أضف مقاييس أعمال (معدل التحويل، معدل الارتداد).
   • قم بقياس الأداء الحالي من مصادر متعددة: بيانات حقلية (CrUX، تحليلاتك الخاصة) وبيانات معملية (Lighthouse، WebPageTest). سجل هذه البيانات كخط أساس.
   • حدد ميزانية أداء (Performance Budget) لكل نوع من الصفحات. مثلاً: حجم JS ≤ 300KB، LCP ≤ 2.5s، إلخ. التزم بهذه الميزانية.
2. أثناء التطوير: دمج الأداء في سير العمل (Integrate):
   • استخدم أدوات الفحص الآلي (Linting) للكشف عن مشكلات الأداء الشائعة (مثل الصور بدون أبعاد).
   • قم بتشغيل Lighthouse تلقائياً في طلبات السحب (Pull Requests) باستخدام Lighthouse CI أو أدوات مشابهة. ارفض الطلب إذا تجاوز الميزانية أو انخفضت النتائج.
   • درب فريقك على مبادئ الأداء وأهمية كتابة كود مراعي للأداء.
3. قبل الإطلاق: اختبار شامل (Pre-Launch Testing):
   • قم باختبار شامل باستخدام WebPageTest من مواقع جغرافية متعددة وعلى أجهزة مختلفة.
   • حاكِ شبكات بطيئة (Slow 3G, 4G) لترى كيف سيكون الأداء للمستخدمين في المناطق النائية.
   • افحص تأثير كود الطرف الثالث.
4. بعد الإطلاق: مراقبة مستمرة (Continuous Monitoring):
   • استخدم نظام مراقبة أداء حقيقي (RUM) مثل Google Analytics مع مكتبة web-vitals، أو خدمة متخصصة (SpeedCurve, Calibre).
   • راقب البيانات الحقلية بشكل يومي. أنشئ إنذارات (Alerts) لأي تراجع مفاجئ في الأداء.
   • اربط بيانات الأداء ببيانات الأعمال (المبيعات، التفاعل) لتتمكن من حساب عائد الاستثمار (ROI) لجهود التحسين.
5. دورة التحسين المستمر: (Iterate & Improve):
   • حلل البيانات بانتظام لتحديد فرص التحسين الجديدة.
   • خصص وقتاً في كل سباق (Sprint) لمعالجة ديون الأداء (Performance Debt).
   • ابق على اطلاع بأحدث التقنيات والتوجهات (مثل INP، HTTP/3، Edge Computing).

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

كلمة أخيرة

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

10. المراجع والمصادر (قائمة شاملة)

• Google Developers. (2024). "Web Vitals: Essential metrics for a healthy site". web.dev
• MDN Web Docs. (2024). "Performance: Critical Rendering Path". MDN
• HTTP Archive. (2024). "State of the Web: Performance Report". httparchive.org
• W3C. (2024). "Navigation Timing Level 2 Specification". w3.org
• Smashing Magazine. (2024). "The Fastest Web: Advanced Performance Techniques". Smashing Magazine
• Osmann, A. (2023). "Using WebPageTest". O'Reilly Media.
• Grigorik, I. (2013). "High Performance Browser Networking". O'Reilly Media. (كلاسيكي ولكن لا يزال أساسياً).
• Davies, A. (2023). "The Performance Budget Planner". CSS Tricks
• Google Chrome Developers. (2024). "Interaction to Next Paint (INP)". web.dev
• Cloudflare. (2024). "What is Edge Computing?". cloudflare.com
• WebAssembly.org. (2024). "WebAssembly Use Cases".
• Astro.build. (2024). "Islands Architecture".

11. ملحق: قائمة مراجعة الأداء النهائية (Performance Checklist)

هذه قائمة مراجعة سريعة يمكنك استخدامها لتقييم أي مشروع ويب:

الخادم والشبكة (Server & Network)

• استخدام CDN للموارد الثابتة.
• تمكين HTTP/2 (أو HTTP/3).
• ضبط رؤوس التخزين المؤقت (Cache-Control) بشكل صحيح.
• تمكين ضغط Gzip أو Brotli على الخادم.
• تحسين TTFB (< 600ms).

HTML

• وضع وسم <meta charset> في أول 1024 بايت.
• وضع الروابط إلى CSS الحرجة في <head>.
• وضع وسوم <script> في نهاية <body> أو باستخدام defer/async.
• تحديد أبعاد (width/height) للصور والفيديوهات.
• استخدام rel="preconnect" و rel="preload" للموارد الحرجة.

CSS

• دمج وتحسين (minify) ملفات CSS.
• استخراج CSS النقدي ووضعه في <style>.
• تحميل CSS غير الحرجة بشكل غير متزامن.
• إزالة CSS غير المستخدم (Unused CSS).
• تجنب استخدام @import.

JavaScript

• دمج وتحسين (minify) ملفات JavaScript.
• استخدام Tree Shaking لإزالة الكود الميت.
• تقسيم الكود (Code Splitting) حسب الصفحة/المكون.
• تحميل كسول (Lazy Load) للمكونات غير الظاهرة.
• تأجيل (defer) أو تحميل غير متزامن (async) لملفات JS غير الحرجة.
• تحليل وتقليل تأثير كود الطرف الثالث.
• تجنب المهام الطويلة (Long Tasks) التي تزيد عن 50ms.

الصور والوسائط

• تحسين جميع الصور (ضغط، تغيير الحجم).
• استخدام الصيغ الحديثة (WebP, AVIF) مع <picture>.
• استخدام srcset و sizes للصور المتجاوبة.
• تفعيل التحميل الكسول (loading="lazy" أو Intersection Observer).
• تحديد أبعاد الصور (width/height) لمنع CLS.
• استخدام CDN متخصص للصور (مثل Cloudinary).

الخطوط (Fonts)

• استخدام font-display: swap.
• استخدام تنسيق WOFF2.
• تقليل حجم الخطوط عبر Subsetting.
• استخدام preload للخطوط الحرجة.

Core Web Vitals

• LCP < 2.5s
• FID < 100ms (والاستعداد لـ INP)
• CLS < 0.1

المراقبة والصيانة

• إعداد مراقبة الأداء الحقيقي (RUM).
• دمج Lighthouse في CI/CD.
• وضع ميزانية أداء (Performance Budget).
• مراجعة الأداء بشكل دوري.