React: النشر و CI/CD

آخر تحديث: 2026-08-26

كانت مدونة توم تعمل بشكل جيد محليًّا، ولكن بعد نشرها على بيئة الإنتاج، واجه كل أنواع المشاكل: لم تكن الصور تُحمَّل، وكانت عناوين URL الخاصة بواجهة برمجة التطبيقات (API) مكتوبة بشكل ثابت في الكود على أنها localhost، وكان تحميل الكود يدويًّا عبر SSH بطيئًا وعرضة للأخطاء. كان بحاجة إلى مسار نشر آلي لتحويل العملية بدءًا من إرسال الكود إلى بيئة الإنتاج إلى سير عمل آلي بالكامل.

سيرشدك هذا الدرس خلال العملية بأكملها، بدءًا من «التطوير المحلي» وصولاً إلى «النشر في بيئة الإنتاج». ستتعلم كيفية النشر بنقرة واحدة باستخدام Vercel، وإعداد مسار عمل آلي باستخدام GitHub Actions، وإدارة متغيرات البيئات المتعددة، وتحسين مكونات البناء لتسريع أوقات تحميل الصفحات. وتُعد مهارات النشر هذه خطوة حاسمة لمهندسي الواجهة الأمامية في الانتقال من «كتابة الكود» إلى «تسليم المنتجات».

1. ما ستتعلمه

• النشر الآلي عبر Vercel (التكامل مع Git، وتكوين النطاق، والتعاون بين أعضاء الفريق)
• مقارنة بين خيارات النشر المختلفة: Netlify وDocker والخوادم التقليدية
• إعداد مسار عمل CI/CD على GitHub Actions
• إدارة متغيرات البيئة (عزل بيئات التطوير والمعاينة والإنتاج)
• وضع استراتيجيات التحسين (تحليل حجم الحزم، شبكة توزيع المحتوى (CDN)، الضغط، التخزين المؤقت)
• @next/bundle-analyzer طرق محددة لتصور حجم العبوة
• next/image كيف يقوم المكون بتحسين تحميل الصور تلقائيًا: المبادئ والإعدادات

2. الرسوم التخطيطية المفاهيمية

صمم توم مسارًا كاملاً للتكامل المستمر/التسليم المستمر (CI/CD): فعندما يقوم أحد المطورين بنشر الكود على GitHub، يتم تلقائيًا تشغيل عمليات البناء والاختبار؛ وبمجرد نجاح هاتين العمليتين، يتم نشر الكود تلقائيًا إلى بيئة الاختبار للمراجعة؛ وبعد الموافقة على المراجعة ودمج الكود في الفرع الرئيسي، يتم نشره تلقائيًا إلى بيئة الإنتاج.

يتمثل جوهر مسار العمل في الأتمتة والتوحيد القياسي. يتم تنفيذ جميع خطوات الفحص (التحقق من وجود الأخطاء البرمجية، والتحقق من أنواع البيانات، والاختبار) تلقائيًا في بيئة التكامل المستمر (CI) دون الحاجة إلى تدخل يدوي. وهذا يضمن اكتشاف أي مشكلات تتعلق بجودة الكود قبل الدمج، مما يضمن نشر الكود الذي تم التحقق من صحته فقط في بيئة الإنتاج. تعمل ميزة «Preview Deployment» من Vercel على إنشاء عنوان URL منفصل للمعاينة تلقائيًا لكل فرع، مما يتيح لمديري المنتجات والمختبرين عرض النتائج بنقرة واحدة.

flowchart LR
    A[Developer Push Code] --> B[GitHub Receive]
    B --> C[GitHub Actions Trigger]
    C --> D{Run CI Process}
    D --> E[Install Dependencies<br/>npm ci]
    E --> F[Code Review<br/>lint / type-check]
    F --> G[Run Test<br/>jest / playwright]
    G --> H[Build<br/>next build]
    H --> I{Deployment Objectives}
    I -->|Feature Branch| J[Vercel Preview<br/>Preview Environment]
    I -->|Main Branch| K[Vercel Production<br/>Production Environment]
    J --> L[Preview URL Automatically Generated]
    K --> M[CDN Distribution<br/>Global Acceleration]

flowchart LR
    A[Developer Push Code] --> B[GitHub Receive]
    B --> C[GitHub Actions Trigger]
    C --> D{Run CI Process}
    D --> E[Install Dependencies<br/>npm ci]
    E --> F[Code Review<br/>lint / type-check]
    F --> G[Run Test<br/>jest / playwright]
    G --> H[Build<br/>next build]
    H --> I{Deployment Objectives}
    I -->|Feature Branch| J[Vercel Preview<br/>Preview Environment]
    I -->|Main Branch| K[Vercel Production<br/>Production Environment]
    J --> L[Preview URL Automatically Generated]
    K --> M[CDN Distribution<br/>Global Acceleration]

3. سيناريو واقعي

تزداد قائمة المشاكل التي يواجهها توم في نشر مدونته طولاً باستمرار: ففي كل مرة يقوم فيها بتحديث منشور، يضطر إلى تسجيل الدخول إلى الخادم عبر SSH وتشغيل git pull وnpm run build وpm2 restart يدويًّا — وهي عملية تستغرق 10 دقائق على الأقل. وإذا نسي إجراء نسخ احتياطي لقاعدة البيانات، فإن خطأً واحداً قد يؤدي إلى محو كل شيء. والأمر الأكثر إحباطًا هو أن التغييرات التي يجريها أعضاء الفريق الآخرون غالبًا ما تحل محل كوده.

قرر اعتماد حل نشر حديث باستخدام Vercel و GitHub Actions. كانت الخطوة الأولى هي ترحيل الكود من FTP إلى مستودع GitHub؛ والخطوة الثانية كانت الاتصال بـ Vercel لتمكين النشر التلقائي؛ أما الخطوة الثالثة فكانت تكوين GitHub Actions لإضافة عمليات فحص الكود وسير عمل الاختبار. بعد اكتمال الترحيل، في كل مرة يتم فيها دفع الكود إلى الفرع main، يقوم Vercel تلقائيًا بإنشائه ونشره، وتستغرق العملية بأكملها أقل من دقيقتين.

كما قارن توم بين إيجابيات وسلبيات عدة خيارات للنشر: يُعد Vercel الخيار الأنسب لمشاريع Next.js ويوفر أبسط إعدادات التهيئة؛ كما يدعم Netlify Next.js أيضًا، لكن بعض الميزات المتقدمة (ISR، والبرمجيات الوسيطة) تتطلب إعدادات إضافية؛ ويُعد النشر عبر Docker مناسبًا للحالات التي تتطلب تحكمًا كاملاً في بيئة الخادم؛ أما النشر عبر الخادم التقليدي (Nginx + PM2) فيوفر أعلى درجة من المرونة، لكنه ينطوي على أعلى تكاليف تشغيلية. بالنسبة للمدونات الشخصية والمشاريع الصغيرة، يُعد Vercel بلا شك الخيار الأفضل.

(1) النشر التلقائي عبر Vercel

Vercel هي منصة نشر بدون خادم توفرها شركة Vercel، وهي الشركة المطورة لـ Next.js. وهي متكاملة بشكل وثيق مع Next.js وتدعم جميع ميزات Next.js، بما في ذلك الكشف التلقائي عن إطار العمل، ووظائف Serverless Functions، ووظائف Edge Functions، و ISR، والبرمجيات الوسيطة. تعتمد آلية النشر التلقائي في Vercel على التكامل مع Git — فبمجرد ربط مستودع GitHub أو GitLab أو Bitbucket الخاص بك، يؤدي كل «دفع» (push) تلقائيًا إلى بدء عملية البناء والنشر.

يوفر Vercel ثلاث بيئات: «الإنتاج» (بيئة الإنتاج، المرتبطة بنطاق مخصص)، و«المعاينة» (بيئة المعاينة، مع إنشاء عنوان URL منفصل تلقائيًا لكل فرع)، و«التطوير» (بيئة التطوير المحلية). وتُعد بيئة «المعاينة» مناسبة بشكل خاص للتعاون الجماعي — حيث يتم إنشاء عنوان URL للمعاينة تلقائيًا لكل طلب سحب، مما يسهل على المراجعين رؤية كيف تبدو التغييرات في بيئة حية.

خطوات النشر على Vercel (طريقة واجهة المستخدم الرسومية)

1. انقر على Add New -> Project في لوحة تحكم Vercel
2. حدد مستودع GitHub وامنح Vercel الإذن بالوصول إليه
3. يقوم Vercel بالكشف تلقائيًا عن إطار عمل Next.js ويستخدم الإعدادات الافتراضية
4. أضف متغيرات البيئة اللازمة في قسم «متغيرات البيئة»
5. انقر على «نشر» وانتظر حوالي 1–2 دقيقة حتى يكتمل عملية النشر.
6. بمجرد اكتمال عملية النشر، يقوم Vercel تلقائيًا بإنشاء اسم النطاق .vercel.app
7. أضف نطاقًا مخصصًا من خلال «الإعدادات» -> «النطاقات»

خطوات النشر على Vercel (طريقة CLI)

# 1. Global Installation Vercel CLI
npm install -g vercel

# 2. Log In Vercel Account
vercel login

# 3. Run the deployment from the project's root directory
# The first time you run it, you'll be guided through the project setup.
vercel

# 4. Deploy to the production environment
vercel --prod

▶ المثال 1: تكوين النشر على Vercel وواجهة سطر الأوامر (CLI)

# 1. Installation Vercel CLI
npm install -g vercel

# 2. Log in to the project root directory
vercel login

# 3. Deploy the project's root directory to the preview environment
vercel

# 4. Deploy to the production environment
vercel --prod

# 5. View the current deployment status
vercel ls

# 6. View the deployment log
vercel logs --all

// next.config.ts - Vercel Automatically read this configuration
import type { NextConfig } from 'next'

const config: NextConfig = {
  // Image Optimization Settings - Allow remote image domains
  images: {
    remotePatterns: [
      { protocol: 'https', hostname: 'images.example.com' },
      { protocol: 'https', hostname: '**.cloudfront.net' },
    ],
  },

  // HTTP Compression
  compress: true,

  // Remove X-Powered-By header (security)
  poweredByHeader: false,

  // Custom Build Directory（Optional）
  distDir: '.next',

  // Enable Strict Mode
  reactStrictMode: true,
}

export default config

// vercel.json - Vercel Project Configuration（Optional，Most projects do not require）
{
  "framework": "nextjs",
  "buildCommand": "npm run build",
  "outputDirectory": ".next",
  "regions": ["hnd1", "iad1"],
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "X-Frame-Options", "value": "DENY" }
      ]
    }
  ]
}

(2) GitHub Actions CI/CD

GitHub Actions هي خدمة CI/CD تقدمها GitHub وتستخدم ملفات التكوين YAML لتحديد سير العمل. يتم تشغيل تسلسل محدد من المهام تلقائيًا مع كل طلب دفع (push) أو سحب (pull). قام توم بتكوين ثلاث مهام: الأولى تُجري فحصًا لغويًّا (linting) وفحصًا للأنواع (type checking) كلما تم إجراء عملية دفع إلى أي فرع؛ والثانية تُجري اختبارًا كاملًا وبناءً عند إجراء عملية دفع إلى فرع main؛ والثالثة تنشر تلقائيًّا إلى بيئة المعاينة عند إصدار إصدار جديد.

يتم تخزين ملفات سير العمل في الدليل .github/workflows/، ويمكنك تسميتها كما تشاء. يمكن أن يحتوي كل سير عمل على مهام متعددة، ويمكنك تعيين تبعيات بين المهام. يوفر GitHub مجموعة متنوعة من الإجراءات المتوفرة في المتجر، مما يتيح لك إعادة استخدام الخطوات التي أنشأها المجتمع مباشرةً.

تشمل المفاهيم الأساسية لـ GitHub Actions ما يلي: on تحديد أحداث التشغيل (push، pull_request، schedule، إلخ)، jobs تحديد المهام المطلوب تنفيذها، steps تحديد خطوات التنفيذ لكل مهمة، وactions/ الوحدات النمطية القابلة لإعادة الاستخدام التي يساهم بها المجتمع. يستخدم سير عمل توم ثلاثة إجراءات من المجتمع: actions/checkout@v4 (استخراج الكود)، actions/setup-node@v4 (تكوين بيئة Node.js)، وactions/upload-artifact@v4 (تحميل مخرجات البناء).

▶ المثال 2: سير عمل كامل لـ GitHub Actions

# .github/workflows/ci-cd.yml
name: CI/CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  # Job 1：Code Quality and Type Checking
  quality:
    name: Code Quality Check
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: TypeScript type check
        run: npx tsc --noEmit

      - name: Lint check
        run: npm run lint

  # Job 2：Run Test + Build
  test-and-build:
    name: Test & Build
    needs: quality  # Dependency quality Mission Successful
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run unit tests
        run: npm test
        env:
          CI: true

      - name: Build project
        run: npm run build
        env:
          NEXT_PUBLIC_API_URL: ${{ secrets.NEXT_PUBLIC_API_URL }}

      - name: Upload build artifacts
        uses: actions/upload-artifact@v4
        with:
          name: next-build
          path: .next/

  # Job 3：Automatically deploy to Vercel
  deploy:
    name: Deploy to Vercel
    needs: test-and-build
    runs-on: ubuntu-latest
    # Only at main Branch Deployment
    if: github.ref == 'refs/heads/main'

    steps:
      - uses: actions/checkout@v4

      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          vercel-args: '--prod'

(3) وضع استراتيجيات التحسين

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

يستخدم تحليل حجم الحزمة المكون الإضافي @next/bundle-analyzer، الذي يتيح لك فحص حجم كل وحدة بشكل مرئي وتحديد التبعيات ذات الأحجام غير الطبيعية. اكتشف توم أن moment.js يشغل مساحة 85 كيلوبايت في مشروعه. وبعد التبديل إلى dayjs (6 كيلوبايت)، انخفض حجم JavaScript الذي يتم تحميله في الشاشة الأولى بنسبة 28%. كما عثر على مكون لم يُستخدم قط ولكنه تم استيراده بشكل عام، فقام بإزالته باستخدام تقنية Tree Shaking.

يتم تنفيذ تحسين الصور باستخدام المكون المدمج next/image في Next.js، والذي يقوم تلقائيًا بإنشاء صيغ WebP/AVIF وأحجام متوافقة مع الأجهزة المختلفة، بالإضافة إلى ميزة التحميل المؤجل. تحتوي مدونة توم على عدد كبير من الصور؛ وبعد استخدام next/image، انخفض متوسط وقت تحميل الصورة من 1.2 ثانية إلى 0.3 ثانية.

يتم تنفيذ استراتيجية التخزين المؤقت من خلال تكوين رأس «Cache-Control» في شبكة توزيع المحتوى (CDN). يتم تعيين الموارد الثابتة (JS، CSS، الصور) على مدة تخزين مؤقت تبلغ سنة واحدة (max-age=31536000)، بينما يتم تعيين صفحات HTML على مدة تخزين مؤقت أقصر (max-age=60) بالاقتران مع التحديثات التلقائية لـ ISR. وبهذه الطريقة، بعد الزيارة الأولى للمستخدم، يتم تحميل الموارد الثابتة اللاحقة مباشرةً من ذاكرة التخزين المؤقت للمتصفح دون الحاجة إلى طلب جديد.

مرجع سريع لخيارات النشر الأخرى

▶ المثال 3: إنشاء تكوين مُحسَّن

// next.config.ts - Complete Optimization Configuration
import type { NextConfig } from 'next'

// Package Volume Analysis（Enable on Demand）
const withBundleAnalyzer = process.env.ANALYZE === 'true'
  ? require('@next/bundle-analyzer')({ enabled: true })
  : (config: any) => config

const config: NextConfig = {
  // === Image Optimization ===
  images: {
    // Allowed Remote Image Domains
    remotePatterns: [
      { protocol: 'https', hostname: 'images.example.com' },
      { protocol: 'https', hostname: 'cdn.example.com' },
    ],
    // Image Format（Supported by default WebP）
    formats: ['image/avif', 'image/webp'],
    // Equipment Breakpoint（Configure according to the design draft）
    deviceSizes: [640, 768, 1024, 1280, 1536],
  },

  // === Safety and Performance ===
  compress: true,
  poweredByHeader: false,
  reactStrictMode: true,

  // === CDN Layout ===
  // If you use a custom CDN，Settings assetPrefix
  // assetPrefix: 'https://cdn.example.com',

  // === Experimental Features ===
  experimental: {
    // Optimization CSS Volume
    optimizePackageImports: ['antd', '@ant-design/icons', 'lodash-es'],
  },
}

export default withBundleAnalyzer(config)

// vercel.json - Caching and Security Header Configuration
// {
//   "headers": [
//     {
//       "source": "/static/(.*)",
//       "headers": [
//         { "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }
//       ]
//     },
//     {
//       "source": "/_next/image(.*)",
//       "headers": [
//         { "key": "Cache-Control", "value": "public, max-age=86400, stale-while-revalidate=2592000" }
//       ]
//     }
//   ]
// }

# Commands for Package Volume Analysis
ANALYZE=true npm run build

# This command generates two HTML Report：
# - .next/analyze/client.html (Client-Side Code Analysis)
# - .next/analyze/server.html (Server-Side Code Analysis)

# After opening your browser to view the report,，You can identify and optimize dependencies that are too large.
# Common Optimization Techniques：
# 1. Dynamic Import: const HeavyComponent = dynamic(() => import('./HeavyComponent'))
# 2. Replacing a Large Database: moment → dayjs（Minimize 95%）
# 3. Tree Shaking: import { Button } from 'antd' in place of import { Button } from 'antd/es/button'

مثال على التحسين قبل وبعد

▶ المثال 4: تكوين مسار العمل المستمر (CI) في GitHub Actions

# .github/workflows/ci.yml
name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20]
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test -- --coverage
      - name: Upload coverage
        if: matrix.node-version == 20
        uses: actions/upload-artifact@v4
        with:
          name: coverage
          path: coverage/

  build:
    needs: lint-and-test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - name: Check bundle size
        run: |
          SIZE=$(du -sk .next/static | cut -f1)
          echo "Bundle size: ${SIZE}KB"
          if [ "$SIZE" -gt 500 ]; then
            echo "⚠️ Bundle exceeds 500KB threshold"
          fi

▶ المثال 5: شامل — التهيئة الكاملة لنشر Next.js في بيئة الإنتاج

# .github/workflows/deploy.yml
name: Deploy to Production

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Type check
        run: npx tsc --noEmit

      - name: Run tests
        run: npm test

      - name: Build application
        run: npm run build
        env:
          NEXT_PUBLIC_API_URL: ${{ vars.NEXT_PUBLIC_API_URL }}
          DATABASE_URL: ${{ secrets.DATABASE_URL }}

      - name: Run Lighthouse audit
        uses: treosh/lighthouse-ci-action@v12
        with:
          urls: |
            http://localhost:3000
          uploadArtifacts: true
          budgetPath: ./lighthouse-budget.json

      - name: Deploy to Vercel
        uses: amondnet/vercel-action@v25
        with:
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
          vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
          vercel-args: '--prod'
          working-directory: ./

      - name: Notify deployment
        if: always()
        run: |
          STATUS="${{ job.status }}"
          curl -X POST "${{ secrets.SLACK_WEBHOOK }}" \
            -H 'Content-type: application/json' \
            -d "{\"text\":\"Deploy $STATUS on $(date -u +%Y-%m-%dT%H:%MZ)\"}"

// lighthouse-budget.json
[
  {
    "path": "/*",
    "options": { "first-contentful-paint": { "maxNumericValue": 2000 } },
    "budgets": [
      { "resourceSizes": [{ "resourceType": "script", "budget": 200 }, { "resourceType": "stylesheet", "budget": 50 }, { "resourceType": "image", "budget": 300 }, { "resourceType": "total", "budget": 600 }] }
    ]
  }
]

❓ أسئلة شائعة

📖 ملخص

• تُعد Vercel أفضل منصة نشر لـ Next.js، حيث تدعم النشر التلقائي عبر التكامل مع Git، وبيئات المعاينة، والوظائف الخالية من الخوادم، وشبكة توزيع المحتوى العالمية (CDN)
• يتم تعريف سير عمل GitHub Actions في .github/workflows/*.yml، وهي تدعم تنسيق المهام المتعددة والتبعيات (needs يتحكم في ترتيب التنفيذ)
• عملية CI/CD القياسية: مراجعة الكود → التحقق من أنواع البيانات → تشغيل الاختبارات → التجميع → النشر (يمكن تنفيذ كل مرحلة بشكل متوازٍ أو متسلسل)
• يتم عزل متغيرات بيئة Vercel حسب البيئة (الإنتاج، والمعاينة، والتطوير)؛ ويمكن تكوين المتغيرات الحساسة عبر لوحة التحكم أو واجهة سطر الأوامر.
• مجموعة أدوات التحسين المكونة من ثلاثة أجزاء: تحليل حجم الحزم (@next/bundle-analyzer)، وتحسين الصور (next/image)، والتخزين المؤقت عبر شبكة توزيع المحتوى (CDN) (Cache-Control)
• dynamic الاستيراد الديناميكي وoptimizePackageImports يمكنهما تقليل حجم جافا سكريبت بشكل فعال عند ظهور الشاشة الأولى
• يوفر «النشر المسبق» رابطًا فريدًا لكل طلب سحب (PR)، مما يسهل على الفريق التعاون في عملية المراجعة
• next.config.ts وcompress وpoweredByHeader وimages والتكوينات الأخرى تؤثر على الأمان والأداء
• خيارات النشر: يُعد Vercel الأنسب لـ Next.js، وNetlify الأنسب للمواقع الثابتة، وDocker الأنسب لمشاريع الفرق، أما النشر التقليدي فهو الأنسب لسيناريوهات المؤسسات
• القيمة الأساسية لـ CI/CD: عمليات فحص آلية لجودة الكود لضمان عدم نشر سوى الكود الذي تم التحقق من صحته في بيئة الإنتاج
• يتم تحديد نطاق متغيرات البيئة حسب البادئة: بدون بادئة (من جانب الخادم)، NEXT_PUBLIC_ (من جانب المتصفح)، NEXT_PRIVATE_ (مُعلنة صراحةً من جانب الخادم)
• next/image مكون يعمل تلقائيًا على تحسين عملية تحميل الصور: تحويل الصور إلى صيغ WebP/AVIF، وتكييف حجم الصور وفقًا لحجم الشاشة، والتحميل المؤجل، والتخزين المؤقت عبر شبكة توزيع المحتوى (CDN)
• يُعد كل من وقت الاستجابة الأولي (TTFB) ودرجة Lighthouse وحجم كود جافا سكريبت الذي يتم تحميله على الشاشة الأولى مؤشرات أساسية لتقييم جودة النشر

📝 تمارين

1. انقل مشروع Next.js الخاص بك إلى مستودع GitHub، ثم قم باستيراده إلى Vercel (استيراد مستودع Git). راقب عملية النشر التلقائية وتأكد من صحة عنوان URL للمعاينة وعنوان URL للإنتاج بعد النشر. راجع سجلات النشر في لوحة تحكم Vercel لفهم كل خطوة من خطوات عملية البناء. قم بتكوين نطاق مخصص (اختياري) وقم بتمكين HTTPS.
2. أنشئ .github/workflows/ci.yml في المشروع وقم بتكوين سير عمل CI: عندما يتم دفع (push) عملية التزام (commit) إلى أي فرع، يتم تلقائيًا تشغيل npm ci -> npm run lint -> npm test -> npm run build. قم بإدخال خطأ في lint أو فشل في الاختبار عن قصد، ثم قم بدفع التغييرات لترى ما إذا كان CI سيفشل ويعرض رسالة خطأ. بعد ذلك، قم بإصلاح الخطأ وتأكد من نجاح عملية التكامل المستمر (CI).
3. تهيئة تحسين عملية البناء للمشروع: استخدم @next/bundle-analyzer لتحليل حجم حزمة المشروع الحالي وتحديد أكبر 3 تبعيات. قم بتنفيذ الاستيراد الديناميكي لأحد هذه المكونات الكبيرة (dynamic(() => import(...)))، وقارن التغير في حجم JavaScript قبل التحسين وبعده. في next.config.ts، قم بتمكين تحسين الصور (قم بتكوين remotePatterns) وإعدادات الضغط. وأخيرًا، استخدم أداة Lighthouse في Chrome DevTools لاختبار درجات الأداء قبل التحسين وبعده، وسجل التحسن في حجم JavaScript للشاشة الأولى ودرجات الأداء.

فريق Web-Tutorial التقني

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

من نحن