تقسيم الكود للمتوسط: نزّل أول تحميل JavaScript لـ 210KB

// قبل: كل المسارات في bundle واحد
import Dashboard from './pages/Dashboard';
import Reports from './pages/Reports';
import Editor from './pages/Editor';

// بعد: كل مسار في chunk منفصل يتحمّل عند الطلب
import { lazy, Suspense } from 'react';

const Dashboard = lazy(() => import('./pages/Dashboard'));
const Reports   = lazy(() => import('./pages/Reports'));
const Editor    = lazy(() => import('./pages/Editor'));

export default function App() {
  return (
    <Suspense fallback={<PageSpinner />}>
      <Routes>
        <Route path="/"        element={<Dashboard />} />
        <Route path="/reports" element={<Reports />} />
        <Route path="/editor"  element={<Editor />} />
      </Routes>
    </Suspense>
  );
}

بعد الـ build، قِس النتيجة بدل ما تخمّن:

النتيجة بالأرقام

خد لوحة تحكم SaaS فيها 24 شاشة. قبل التقسيم كان الـ bundle الأساسي 1.83 ميجابايت، والمتصفح بياخد 6.4 ثانية على شبكة الجيل الرابع قبل ما الصفحة تبقى قابلة للاستخدام فعلاً.

بعد تقسيم على مستوى المسارات، أول تحميل (main.js) نزل لـ 210 كيلوبايت — انخفاض 88%. باقي الكود اتوزّع على chunks بتتحمّل لما المستخدم يفتح الصفحة المعنية. زمن التفاعل نزل من 6.4 ثانية لـ 1.9 ثانية — أسرع 70% — وتقييم Lighthouse للأداء طلع من 41 لـ 88. الافتراض هنا مهم: التطبيق فيه مسارات متعددة وكل مسار له كود خاص ملموس. لو تطبيقك صفحة واحدة، المكسب هيكون أقل بكتير.

الـ trade-offs اللي لازم تعرفها

• كل import() ديناميكي = طلب شبكة إضافي. لو قسّمت بزيادة على مستوى كل مكوّن صغير، هتعمل سلسلة طلبات (waterfall) بتأخّر التنقّل. بتكسب bundle أصغر، بتخسر بساطة طلب واحد. الوازنة: قسّم على مستوى المسار، مش كل زرار.
• الـ fallback بيظهر لحظة التنقّل. لو الـ chunk كبير والشبكة بطيئة، المستخدم هيشوف spinner ثانية أو اتنين. الحل: استعمل prefetch للمسار المتوقّع عن طريق <link rel="prefetch"> أو حمّل الـ chunk وقت ما المستخدم يعدّي الماوس على اللينك.
• بتكسب أول تحميل أسرع، بتخسر سرعة أول دخول لكل صفحة. أول مرة يفتح المستخدم صفحة بيستنى تحميل الـ chunk بتاعها — جزء من الثانية عادةً. ده مقبول لأن وقت قراءته للصفحة أطول بكتير من وقت الانتظار ده.
• كود مشترك ممكن يتكرر. لو كذا chunk بيستخدموا نفس المكتبة، أداة البناء بتطلّع المشترك في chunk vendor تلقائيًا — بس راجع ده بـ bundle visualizer علشان تتأكد إنه مش بيتكرّر فعلاً.

متى متستخدمش تقسيم الكود

تقسيم الكود مش مجاني. لو التطبيق كله أقل من 150 كيلوبايت JavaScript، التقسيم بيضيف طلبات شبكة وتعقيد من غير فايدة محسوسة — سيبه bundle واحد. وكمان landing page بصفحة واحدة، أو موقع محتوى ثابت، مش محتاجين تقسيم على مستوى المسارات أصلاً. التقسيم بيلمع لما يكون عندك تطبيق كبير، بمسارات كتير ومكتبات تقيلة — محرّر نصوص، خرائط، رسوم بيانية — مش كل المستخدمين بيستخدموها.

الخطوة التالية

افتح مشروعك وشغّل npx vite build. بُصّ لأكبر chunk في القائمة. لو لقيت مسار تقيل مش بيظهر أول لحظة — صفحة إعدادات أو تقارير أو محرّر — لفّه بـ lazy() زي المثال فوق، اعمل build تاني، وقارن حجم أول تحميل. لو نزل بشكل ملحوظ، كمّل على باقي المسارات. لو ماتغيّرش، يبقى الكود التقيل موجود في الـ chunk الأساسي نفسه — وده يحتاج تحليل بـ bundle visualizer.

مصادر

• توثيق React الرسمي — lazy و Suspense: react.dev/reference/react/lazy
• توثيق Vite — Features و Build (Dynamic Import): vitejs.dev/guide/features
• MDN — التعبير import() الديناميكي: developer.mozilla.org
• web.dev — Reduce JavaScript payloads with code splitting: web.dev
• توثيق webpack — Code Splitting: webpack.js.org/guides/code-splitting