الأمان والأداء

أساسيات أداء الواجهة الأمامية

18 دقيقة الدرس 15 من 35

مقدمة في أداء الواجهة الأمامية

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

في هذا الدرس الشامل، سنستكشف المفاهيم الأساسية لأداء الواجهة الأمامية، بما في ذلك مسار العرض الحرج، ومقاييس Core Web Vitals، وأدوات قياس الأداء، واستراتيجيات التحسين التي يجب على كل مطور ويب فهمها.

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

مسار العرض الحرج (Critical Rendering Path)

مسار العرض الحرج هو تسلسل الخطوات التي يتخذها المتصفح لتحويل HTML و CSS و JavaScript إلى بكسلات على الشاشة. فهم هذه العملية أمر أساسي لتحسين أداء الواجهة الأمامية.

خطوات مسار العرض الحرج

  1. بناء DOM: يقوم المتصفح بتحليل HTML وإنشاء شجرة نموذج كائن المستند (DOM)
  2. بناء CSSOM: يقوم المتصفح بتحليل CSS وإنشاء شجرة نموذج كائن CSS (CSSOM)
  3. إنشاء شجرة العرض: يجمع المتصفح بين DOM و CSSOM لإنشاء شجرة العرض
  4. التخطيط: يحسب المتصفح موضع وحجم كل عنصر
  5. الرسم: يحول المتصفح شجرة العرض إلى بكسلات على الشاشة

نموذج كائن المستند (DOM)

يمثل DOM بنية مستند HTML الخاص بك كشجرة من العقد. يصبح كل عنصر HTML عقدة في الشجرة، ولا يمكن للمتصفح عرض الصفحة حتى يتم بناء DOM بالكامل.

<!DOCTYPE html>\n<html>\n<head>\n <title>مثال DOM</title>\n</head>\n<body>\n <header>\n <h1>مرحبًا</h1>\n </header>\n <main>\n <p>المحتوى هنا</p>\n </main>\n</body>\n</html>

بناء DOM تدريجي - يمكن للمتصفح بدء التحليل والعرض قبل استلام مستند HTML بالكامل. ومع ذلك، يمكن لـ JavaScript حظر بناء DOM إذا قام بتعديل بنية المستند.

نموذج كائن CSS (CSSOM)

CSSOM مشابه لـ DOM ولكن لـ CSS. إنه يمثل جميع أنماط CSS للصفحة. على عكس DOM، فإن بناء CSSOM يحظر العرض - لا يمكن للمتصفح عرض الصفحة حتى يكتمل CSSOM لأنه يحتاج إلى معرفة جميع الأنماط قبل الرسم.

/* يمثل CSSOM هذه الأنماط كبنية شجرية */\nbody {\n font-size: 16px;\n color: #333;\n}\n\nheader {\n background: #f0f0f0;\n padding: 20px;\n}\n\nh1 {\n font-size: 2em;\n margin: 0;\n}
CSS يحظر العرض: لا يمكن للمتصفح عرض أي محتوى حتى يعالج جميع CSS. لهذا السبب يعد تحسين تسليم CSS أمرًا بالغ الأهمية للأداء. ضع CSS الحرج مضمنًا في <head> وأجل CSS غير الحرج.

شجرة العرض والتخطيط

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

تحسب مرحلة التخطيط (تسمى أيضًا إعادة التدفق) الموضع والحجم الدقيقين لكل عنصر. هذه عملية مكلفة حسابيًا، خاصةً للتخطيطات المعقدة مع العديد من العناصر.

مقاييس Core Web Vitals

Core Web Vitals هي مجموعة من المقاييس التي تستخدمها Google لقياس تجربة المستخدم. هذه المقاييس جزء من إشارات تجربة الصفحة من Google وتؤثر بشكل مباشر على تصنيفات تحسين محركات البحث.

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

يقيس LCP أداء التحميل. إنه يحدد الوقت الذي يصبح فيه أكبر عنصر محتوى (صورة أو فيديو أو كتلة نص) مرئيًا في منطقة العرض. درجات LCP الجيدة أقل من 2.5 ثانية.

تحسين LCP:
  • تحسين وضغط الصور
  • استخدام CDN لتسليم المحتوى بشكل أسرع
  • تقليل وقت استجابة الخادم
  • إزالة الموارد التي تحظر العرض
  • استخدام التحميل الكسول للصور أسفل الطية

تأخير الإدخال الأول (FID) / التفاعل إلى الرسم التالي (INP)

يقيس FID التفاعلية من خلال تتبع التأخير بين تفاعل المستخدم الأول واستجابة المتصفح. تنتقل Google إلى INP، الذي يقيس الاستجابة طوال دورة حياة الصفحة بأكملها. درجات FID الجيدة أقل من 100 مللي ثانية، بينما درجات INP الجيدة أقل من 200 مللي ثانية.

// مثال: Debouncing لتحسين الاستجابة\nfunction debounce(func, wait) {\n let timeout;\n return function executedFunction(...args) {\n const later = () => {\n clearTimeout(timeout);\n func(...args);\n };\n clearTimeout(timeout);\n timeout = setTimeout(later, wait);\n };\n}\n\n// استخدام debouncing لأحداث التمرير/تغيير الحجم\nwindow.addEventListener('scroll', debounce(() => {\n console.log('تم معالجة حدث التمرير');\n}, 150));

التحول التراكمي للتخطيط (CLS)

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

<!-- حدد دائمًا أبعاد الصورة لمنع تحول التخطيط -->\n<img \n src="image.jpg" \n width="800" \n height="600" \n alt="الوصف"\n loading="lazy"\n>\n\n<!-- احتفظ بمساحة للمحتوى الديناميكي -->\n<div style="min-height: 200px;">\n <!-- سيتم تحميل المحتوى هنا -->\n</div>
أسباب CLS الشائعة:
  • صور بدون سمات العرض/الارتفاع
  • إعلانات أو تضمينات بدون مساحة محجوزة
  • خطوط الويب التي تسبب إعادة تدفق النص (FOIT/FOUT)
  • محتوى محقون ديناميكيًا فوق المحتوى الموجود

عمليات تدقيق أداء Lighthouse

Lighthouse هي أداة آلية مدمجة في Chrome DevTools تدقق صفحات الويب من حيث الأداء وإمكانية الوصول وتحسين محركات البحث والمزيد. توفر درجة أداء (0-100) وتوصيات قابلة للتنفيذ.

تشغيل عمليات تدقيق Lighthouse

  1. افتح Chrome DevTools (F12 أو Cmd+Option+I)
  2. انتقل إلى علامة التبويب "Lighthouse"
  3. حدد فئة "الأداء"
  4. اختر نوع الجهاز (الجوال/سطح المكتب)
  5. انقر على "تحليل تحميل الصفحة"

مقاييس Lighthouse الرئيسية

  • أول رسم للمحتوى (FCP): الوقت الذي يظهر فيه المحتوى الأول (أقل من 1.8 ثانية جيد)
  • مؤشر السرعة: مدى سرعة ملء المحتوى بصريًا (أقل من 3.4 ثانية جيد)
  • الوقت إلى التفاعلية (TTI): الوقت حتى تصبح الصفحة تفاعلية بالكامل (أقل من 3.8 ثانية جيد)
  • إجمالي وقت الحظر (TBT): الوقت الذي تم فيه حظر الخيط الرئيسي (أقل من 200 مللي ثانية جيد)
أفضل ممارسات Lighthouse:
  • اختبر في وضع التصفح الخفي لتجنب تداخل الإضافات
  • اختبر عدة مرات واحسب متوسط النتائج
  • اختبر على الجوال وسطح المكتب
  • استخدم "Simulated Throttling" لنتائج متسقة
  • اختبر في ظروف شبكة مختلفة

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

ميزانية الأداء هي مجموعة من الحدود للمقاييس التي تؤثر على أداء الموقع. تساعد هذه الميزانيات الفرق على اتخاذ قرارات مستنيرة حول ما يجب تضمينه في الصفحة والحفاظ على أوقات تحميل سريعة بمرور الوقت.

أنواع ميزانيات الأداء

  1. ميزانيات قائمة على المقاييس: حدود للمقاييس مثل LCP و FID و CLS (مثل LCP يجب أن يكون أقل من 2.5 ثانية)
  2. ميزانيات قائمة على الموارد: حدود لأحجام الموارد (مثل JavaScript أقل من 200 كيلوبايت، الصور أقل من 1 ميغابايت)
  3. ميزانيات قائمة على القواعد: حدود لعدد الموارد (مثل حد أقصى 10 ملفات JavaScript، 5 ملفات CSS)
// مثال على تكوين ميزانية الأداء\n{\n "budgets": [\n {\n "resourceSizes": [\n {\n "resourceType": "script",\n "budget": 200\n },\n {\n "resourceType": "image",\n "budget": 300\n },\n {\n "resourceType": "stylesheet",\n "budget": 50\n }\n ],\n "timings": [\n {\n "metric": "first-contentful-paint",\n "budget": 2000\n },\n {\n "metric": "largest-contentful-paint",\n "budget": 2500\n }\n ]\n }\n ]\n}

تطبيق ميزانيات الأداء

يجب تطبيق ميزانيات الأداء في سير عمل التطوير الخاص بك باستخدام أدوات آلية:

  • Lighthouse CI: تشغيل Lighthouse في خط أنابيب CI/CD وفشل البناءات التي تتجاوز الميزانيات
  • Webpack Bundle Analyzer: تصور أحجام الحزم وتحديد الانتفاخ
  • bundlesize: حزمة npm للتحقق من أحجام الملفات مقابل الحدود
  • WebPageTest API: اختبار أداء آلي مع فرض الميزانية

لوحة الأداء في أدوات مطوري المتصفح

توفر لوحة الأداء في Chrome DevTools رؤى مفصلة حول أداء وقت التشغيل، مما يسمح لك بتحديد نقاط الاختناق وتحسين الكود الخاص بك.

استخدام لوحة الأداء

  1. افتح DevTools وانتقل إلى علامة التبويب "Performance"
  2. انقر على زر التسجيل (أو Cmd+E / Ctrl+E)
  3. تفاعل مع صفحتك أو دعها تحمل
  4. انقر على إيقاف لإنهاء التسجيل
  5. حلل مخطط اللهب والجدول الزمني

قراءة تسجيلات الأداء

يظهر تسجيل الأداء عدة أقسام رئيسية:

  • الجدول الزمني للشبكة: يظهر متى يتم طلب الموارد وتحميلها
  • نشاط الخيط الرئيسي: يظهر تنفيذ JavaScript وعمليات التخطيط والرسم
  • نشاط GPU: يظهر التركيب والتنقيط
  • لقطات الشاشة: الجدول الزمني المرئي لعرض الصفحة
نصائح لوحة الأداء:
  • ابحث عن المهام الطويلة (الكتل الصفراء/الحمراء التي تزيد عن 50 مللي ثانية)
  • حدد التخطيطات المتزامنة القسرية (تحذيرات أرجوانية)
  • تحقق من تنفيذ JavaScript المفرط
  • راقب استخدام الذاكرة للكشف عن التسريبات
  • استخدم عروض "Bottom-Up" و "Call Tree" للتحليل التفصيلي

تحديد مشاكل الأداء

الأنماط الشائعة للبحث عنها في لوحة الأداء:

// سيء: تخطيط متزامن قسري (thrashing التخطيط)\nfunction badLayout() {\n const boxes = document.querySelectorAll('.box');\n boxes.forEach(box => {\n // قراءة offsetHeight تطلق التخطيط\n const height = box.offsetHeight;\n // كتابة style تطلق تخطيطًا آخر\n box.style.height = height + 10 + 'px';\n });\n}\n\n// جيد: دفعة من القراءات والكتابات\nfunction goodLayout() {\n const boxes = document.querySelectorAll('.box');\n // اقرأ جميع الارتفاعات أولاً\n const heights = Array.from(boxes).map(box => box.offsetHeight);\n // ثم اكتب جميع الأنماط\n boxes.forEach((box, i) => {\n box.style.height = heights[i] + 10 + 'px';\n });\n}

قياس الأداء في الكود

يمكنك قياس الأداء برمجيًا باستخدام Performance API لتتبع تجارب المستخدم الحقيقية وتحديد نقاط الاختناق في الإنتاج.

Performance Timing API

// قياس الأداء الأساسي\nconst navigationTiming = performance.getEntriesByType('navigation')[0];\nconsole.log('بحث DNS:', navigationTiming.domainLookupEnd - navigationTiming.domainLookupStart);\nconsole.log('اتصال TCP:', navigationTiming.connectEnd - navigationTiming.connectStart);\nconsole.log('وقت الطلب:', navigationTiming.responseStart - navigationTiming.requestStart);\nconsole.log('وقت الاستجابة:', navigationTiming.responseEnd - navigationTiming.responseStart);\nconsole.log('معالجة DOM:', navigationTiming.domContentLoadedEventEnd - navigationTiming.domContentLoadedEventStart);\n\n// وقت تحميل الصفحة\nconst loadTime = navigationTiming.loadEventEnd - navigationTiming.fetchStart;\nconsole.log('إجمالي وقت تحميل الصفحة:', loadTime, 'مللي ثانية');

User Timing API

// قياس العمليات المخصصة\nperformance.mark('search-start');\n\n// ... تنفيذ عملية البحث\nconst results = performSearch(query);\n\nperformance.mark('search-end');\nperformance.measure('search-duration', 'search-start', 'search-end');\n\nconst measure = performance.getEntriesByName('search-duration')[0];\nconsole.log('استغرق البحث:', measure.duration, 'مللي ثانية');\n\n// إرسال إلى التحليلات\nsendAnalytics({\n eventName: 'search-performance',\n duration: measure.duration\n});

مكتبة Web Vitals

توفر Google مكتبة web-vitals لقياس Core Web Vitals بسهولة في الإنتاج:

// التثبيت: npm install web-vitals\nimport {getCLS, getFID, getFCP, getLCP, getTTFB} from 'web-vitals';\n\nfunction sendToAnalytics(metric) {\n // إرسال إلى خدمة التحليلات الخاصة بك\n console.log(metric.name, metric.value);\n \n // مثال: إرسال إلى Google Analytics\n gtag('event', metric.name, {\n value: Math.round(metric.value),\n event_category: 'Web Vitals',\n event_label: metric.id,\n non_interaction: true,\n });\n}\n\ngetCLS(sendToAnalytics);\ngetFID(sendToAnalytics);\ngetFCP(sendToAnalytics);\ngetLCP(sendToAnalytics);\ngetTTFB(sendToAnalytics);

استراتيجيات تحسين الأداء

بناءً على المقاييس والقياسات، إليك استراتيجيات التحسين الأساسية:

تحسين مسار العرض الحرج

  • تقليل الموارد الحرجة (تضمين CSS الحرج)
  • تقليل البايتات الحرجة (الضغط والتصغير)
  • تقليل طول المسار الحرج (تقليل التبعيات)
  • تأجيل CSS و JavaScript غير الحرجة

تحسين JavaScript

  • تقسيم الكود إلى حزم أصغر
  • استخدام tree shaking لإزالة الكود غير المستخدم
  • تأجيل أو تحميل البرامج النصية غير الحرجة بشكل غير متزامن
  • تقليل عمل الخيط الرئيسي
  • استخدام Web Workers للحسابات الثقيلة

تحسين الصور

  • استخدام التنسيقات الحديثة (WebP، AVIF)
  • تطبيق الصور المستجيبة باستخدام srcset
  • تحميل كسول للصور أسفل الطية
  • ضغط الصور بشكل مناسب
  • استخدام CDN لتسليم الصور
تمرين تطبيقي:
  1. اختر موقعًا قمت ببنائه أو أي موقع عام
  2. قم بتشغيل تدقيق Lighthouse وسجل درجة الأداء
  3. استخدم لوحة الأداء لتسجيل تحميل صفحة
  4. حدد أهم ثلاث مشكلات أداء
  5. احسب ميزانية أداء بناءً على المقاييس الحالية
  6. قم بتطبيق مكتبة web-vitals وسجل المقاييس في وحدة التحكم
  7. قارن LCP و FID و CLS عبر صفحات مختلفة

الملخص

يبدأ تحسين أداء الواجهة الأمامية بفهم مسار العرض الحرج وكيف تحول المتصفحات الكود إلى بكسلات. توفر Core Web Vitals أهدافًا قابلة للقياس لتجربة المستخدم، بينما تساعد أدوات مثل Lighthouse و Chrome DevTools في تحديد وتشخيص مشكلات الأداء.

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

النقاط الرئيسية:
  • فهم مسار العرض الحرج: DOM، CSSOM، شجرة العرض، التخطيط، الرسم
  • تحسين لـ Core Web Vitals: LCP أقل من 2.5 ثانية، FID/INP أقل من 100-200 مللي ثانية، CLS أقل من 0.1
  • استخدام Lighthouse لعمليات تدقيق أداء شاملة
  • تطبيق ميزانيات الأداء وفرضها في CI/CD
  • استخدام لوحة الأداء في Chrome DevTools لتحديد نقاط الاختناق
  • قياس أداء المستخدم الحقيقي باستخدام Performance API ومكتبة web-vitals
الدرس السابق التسجيل ومراقبة الأمان
الدرس التالي تحسين أداء JavaScript
العودة للدورة