تحسين الأداء مع تحليل الذكاء الاصطناعي

عملية تحليل الأداء

مساعدو الذكاء الاصطناعي يمكنهم تحليل الأداء من زوايا متعددة:

• عدم الكفاءة على مستوى الكود
• تحسين استعلامات قاعدة البيانات
• اختناقات الشبكة والـ I/O
• مشاكل عرض الواجهة الأمامية

تحليل الأداء على مستوى الكود

مراجعة التعقيد الخوارزمي

claude "راجع هذه الدالة لمشاكل الأداء.
حدد التعقيد الخوارزمي واقترح تحسينات.
[الصق الدالة]"

الذكاء الاصطناعي يحدد المشاكل:

// الأصلي: تعقيد O(n²)
function findDuplicates(items: Item[]): Item[] {
  const duplicates: Item[] = [];
  for (let i = 0; i < items.length; i++) {
    for (let j = i + 1; j < items.length; j++) {
      if (items[i].id === items[j].id) {
        duplicates.push(items[i]);
      }
    }
  }
  return duplicates;
}

// مُحسَّن: تعقيد O(n)
function findDuplicates(items: Item[]): Item[] {
  const seen = new Map<string, Item>();
  const duplicates: Item[] = [];

  for (const item of items) {
    if (seen.has(item.id)) {
      duplicates.push(item);
    } else {
      seen.set(item.id, item);
    }
  }

  return duplicates;
}

// تحسين الأداء: أسرع 100 مرة لـ 1000 عنصر
// قبل: ~500ms | بعد: ~5ms

تحليل حجم الحزمة

claude "حلل حزمتنا لمشاكل الحجم.
هذا مخرج webpack-bundle-analyzer.
اقترح فرص تقسيم الكود والاعتماديات الثقيلة
التي يمكن استبدالها."

## تحليل الحزمة

### الحالة الحالية
- إجمالي الحزمة: 2.4 MB (مضغوط: 680 KB)
- أكبر الأجزاء:
  1. vendor.js: 1.2 MB (moment.js: 400 KB!)
  2. main.js: 800 KB
  3. charts.js: 400 KB

### التوصيات

1. **استبدل moment.js بـ date-fns**
   - التوفير: 350 KB
   - قابل لـ tree-shaking
   - نفس الوظائف

2. **حمّل وحدة الرسوم البيانية بشكل كسول**
   ```typescript
   // قبل
   import { Charts } from './charts';

   // بعد
   const Charts = lazy(() => import('./charts'));

• توفير التحميل الأولي: 400 KB

3. أزل دوال lodash غير المستخدمة
   • حاليًا يستورد كل lodash
   • انتقل إلى lodash-es مع tree shaking
   • التوفير: ~200 KB

النتائج المتوقعة

• إجمالي الحزمة: 1.4 MB (مضغوط: 380 KB)
• تخفيض 42% في حجم الحزمة
• تحميل أولي أسرع بـ 1.2 ثانية على 3G

## تحسين استعلامات قاعدة البيانات

### اكتشاف استعلام N+1

```bash
claude "حلل هذا الكود لمشاكل استعلام N+1.
[الصق كود جلب البيانات]"

// المشكلة: استعلام N+1
async function getOrdersWithItems(userId: string) {
  const orders = await prisma.order.findMany({
    where: { userId }
  });

  // N استعلامات إضافية!
  for (const order of orders) {
    order.items = await prisma.orderItem.findMany({
      where: { orderId: order.id }
    });
  }

  return orders;
}

// الحل: استعلام واحد مع include
async function getOrdersWithItems(userId: string) {
  return prisma.order.findMany({
    where: { userId },
    include: {
      items: {
        include: {
          product: true  // أيضًا ضمّن تفاصيل المنتج
        }
      }
    }
  });
}

// الأداء: 50 استعلام ← استعلام واحد
// وقت الاستجابة: 450ms ← 35ms

تحليل خطة الاستعلام

claude "اشرح خطة استعلام PostgreSQL هذه واقترح
فهارس لتحسين الأداء.
[الصق مخرج EXPLAIN ANALYZE]"

-- الاستعلام الأصلي (2.3 ثانية)
SELECT * FROM orders
JOIN order_items ON orders.id = order_items.order_id
WHERE orders.user_id = 'abc123'
  AND orders.created_at > '2025-01-01';

-- التحليل:
-- مسح تسلسلي على orders (1.2M صف)
-- لا يوجد فهرس على user_id أو created_at

-- الفهارس الموصى بها:
CREATE INDEX idx_orders_user_id ON orders(user_id);
CREATE INDEX idx_orders_created_at ON orders(created_at);
-- أو مركب:
CREATE INDEX idx_orders_user_created ON orders(user_id, created_at);

-- بعد الفهرسة: 45ms (تحسين 50 ضعف)

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

تحسين عرض React

claude "هذا المكون يُعاد عرضه كثيرًا جدًا.
حلل سلوك العرض واقترح تحسينات.
[الصق كود المكون]"

// المشكلة: إعادات عرض غير ضرورية
function OrderList({ orders, onSelect }) {
  // دالة جديدة تُنشأ كل عرض
  const handleClick = (id) => () => onSelect(id);

  // مصفوفة جديدة تُنشأ كل عرض
  const sortedOrders = orders.sort((a, b) =>
    b.date.getTime() - a.date.getTime()
  );

  return (
    <div>
      {sortedOrders.map(order => (
        <OrderCard
          key={order.id}
          order={order}
          onClick={handleClick(order.id)}  // دالة جديدة لكل عنصر!
        />
      ))}
    </div>
  );
}

// مُحسَّن
const OrderList = memo(function OrderList({ orders, onSelect }) {
  // حفظ callback في الذاكرة
  const handleClick = useCallback((id: string) => {
    onSelect(id);
  }, [onSelect]);

  // حفظ الطلبات المرتبة في الذاكرة
  const sortedOrders = useMemo(() =>
    [...orders].sort((a, b) => b.date.getTime() - a.date.getTime()),
    [orders]
  );

  return (
    <div>
      {sortedOrders.map(order => (
        <OrderCard
          key={order.id}
          order={order}
          onSelect={handleClick}  // مرجع مستقر
        />
      ))}
    </div>
  );
});

// المكون الفرعي أيضًا محفوظ في الذاكرة
const OrderCard = memo(function OrderCard({ order, onSelect }) {
  return (
    <div onClick={() => onSelect(order.id)}>
      {order.name}
    </div>
  );
});

تحليل Core Web Vitals

claude "درجة Lighthouse لدينا انخفضت إلى 65.
حلل هذه المقاييس وقدم إصلاحات محددة:
LCP: 4.2s (يجب أن تكون <2.5s)
FID: 180ms (يجب أن تكون <100ms)
CLS: 0.25 (يجب أن تكون <0.1)"

## خطة إصلاح Core Web Vitals

### LCP (4.2s ← <2.5s)
**المشكلة**: صورة البطل الكبيرة غير محسنة
**الإصلاحات**:
1. استخدم next/image مع priority للصور فوق الطي
2. أضف تلميح preload: `<link rel="preload" as="image">`
3. قدم WebP مع fallback
4. نفذ blur placeholder

### FID (180ms ← <100ms)
**المشكلة**: JavaScript ثقيل يحجب الخيط الرئيسي
**الإصلاحات**:
1. قسّم كود JavaScript غير الحرج
2. أجّل التحليلات وعناصر الدردشة
3. استخدم web workers لمعالجة البيانات
4. قسّم المهام الطويلة مع `scheduler.yield()`

### CLS (0.25 ← <0.1)
**المشكلة**: صور وإعلانات بدون أبعاد
**الإصلاحات**:
1. أضف width/height لجميع الصور
2. احجز مساحة للمحتوى الديناميكي
3. استخدم CSS aspect-ratio للصور المتجاوبة
4. حمّل الخطوط مسبقًا لتجنب FOIT/FOUT

### أولوية التنفيذ
1. تحسين الصور (أكبر تأثير على LCP)
2. تأجيل السكريبتات (تحسين FID + LCP)
3. استقرار التخطيط (إصلاح CLS)

أداء API

تحليل وقت الاستجابة

claude "زمن انتقال p95 لـ API لدينا هو 2.3 ثانية. حلل تدفق
الطلب وحدد أين يُقضى الوقت."

## تفصيل وقت الطلب

نقطة النهاية: POST /api/orders

| المرحلة | الوقت | % الإجمالي | المشكلة |
|-------|------|---------|-------|
| middleware المصادقة | 15ms | 0.7% | OK |
| تحليل الطلب | 5ms | 0.2% | OK |
| فحص المخزون | 850ms | 37% | استعلامات N+1 |
| معالجة الدفع | 400ms | 17% | API خارجي |
| إنشاء الطلب | 200ms | 9% | OK |
| وضع البريد بالقائمة | 750ms | 33% | متزامن! |
| تسلسل الاستجابة | 80ms | 3% | حمولة كبيرة |

### التحسينات

1. **فحص المخزون (850ms ← 50ms)**
   - دفعة استعلامات المنتجات
   - أضف Redis cache لمستويات المخزون

2. **وضع البريد بالقائمة (750ms ← 5ms)**
   - انقل إلى قائمة مهام خلفية
   - لا تنتظر استجابة خدمة البريد

3. **تسلسل الاستجابة (80ms ← 20ms)**
   - أرجع الحقول الضرورية فقط
   - استخدم projection في استعلام قاعدة البيانات

### النتيجة المتوقعة
- الحالي: 2300ms p95
- بعد: 680ms p95 (تحسين 70%)

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

claude "أنشئ ميزانية أداء لتطبيق التجارة الإلكترونية لدينا
بناءً على تحليل المنافسين وتوقعات المستخدمين."

# .performance-budget.yaml

metrics:
  # Core Web Vitals
  LCP: 2000ms
  FID: 100ms
  CLS: 0.1

  # أحجام الحزم
  javascript:
    initial: 200KB
    total: 500KB
  css:
    initial: 50KB
    total: 100KB

  # أوقات استجابة API
  api:
    p50: 200ms
    p95: 500ms
    p99: 1000ms

  # خاص بالصفحات
  pages:
    home:
      firstContentfulPaint: 1200ms
      timeToInteractive: 2500ms
    product:
      firstContentfulPaint: 1000ms
      timeToInteractive: 2000ms
    checkout:
      timeToInteractive: 1500ms

alerts:
  slack: "#performance"
  threshold: 10%  # تنبيه إذا تجاوزت الميزانية 10%

الدرس التالي

سنغطي تقنيات إعادة الهيكلة واسعة النطاق—كيف تحوّل قواعد الكود بأمان بمساعدة الذكاء الاصطناعي. :::