تحسين أداء Next.js: دليل شامل لعام 2026

لقد قضيت السنوات الأربع الماضية في تحسين تطبيقات Next.js لعملاء يتراوح نشاطهم من متاجر التجارة الإلكترونية التي تحقق مبيعات سنوية بقيمة 50 مليون دولار إلى لوحات معلومات SaaS بأكثر من 100 ألف مستخدم نشط يومي. بعض ما تعلمته يطابق التوثيق تماماً. لكن الكثير منه لا يفعل. هذا هو الدليل الذي تمنيت أن يعطيه لي شخص ما عندما بدأت -- محدث لـ Next.js 15 والأنماط التي تهم فعلاً في عام 2026.

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

دعنا ندخل إلى الموضوع.

جدول المحتويات

تحسين أداء Next.js: دليل شامل لعام 2026

فهم أساسيات أداء Next.js 15

جاء Next.js 15 (مستقر منذ أواخر 2025) ببعض التغييرات الكبيرة على كيفية عمل الأداء تحت الغطاء. إن bundler Turbopack هو الآن الافتراضي لكل من إنشاءات التطوير والإنتاج. App Router نضج بالكامل. وسلوك التخزين المؤقت -- الذي أربك الجميع تقريباً في Next.js 14 -- تم ترشيده.

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

نموذج الأداء العقلي

فكر في أداء Next.js في ثلاث طبقات:

  1. قرارات وقت الإنشاء -- ما يتم إنشاؤه مسبقاً، ما هو ديناميكي، كيف ينقسم الكود
  2. تنفيذ وقت الخادم -- مدى سرعة استجابة الخادم، التخزين المؤقت، edge مقابل origin
  3. تجربة وقت العميل -- حجم الحزمة، تكلفة hydration، جاهزية التفاعل

كل طبقة تضرب الآخرين. استجابة خادم سريعة لا تعني شيئاً إذا كنت تشحن 500 كيلوبايت من JavaScript يستغرق 3 ثوان للترطيب على هاتف Android متوسط المدى.

قياس ما يهم فعلاً

قبل تحسين أي شيء، تحتاج إلى قياس. وتحتاج إلى قياس الأشياء الصحيحة.

Core Web Vitals لا تزال إشارات ترتيب Google في عام 2026، لكن العتبات أصبحت أكثر صرامة. إليك كيف تقف الأمور:

المقياس جيد يحتاج تحسين سيء
LCP (Largest Contentful Paint) ≤ 2.0s 2.0s – 3.5s > 3.5s
INP (Interaction to Next Paint) ≤ 150ms 150ms – 300ms > 300ms
CLS (Cumulative Layout Shift) ≤ 0.1 0.1 – 0.25 > 0.25
TTFB (Time to First Byte) ≤ 400ms 400ms – 800ms > 800ms

الأدوات التي أستخدمها فعلاً

  • Vercel Speed Insights -- إذا كنت على Vercel، فهذا خيار لا يحتاج إلى تفكير. بيانات مستخدم حقيقية، وليس اصطناعية.
  • next/bundle-analyzer -- قم بتشغيل هذا أسبوعياً. يزحف حجم الحزمة عندما لا تنظر.
  • Chrome DevTools Performance tab -- لا تزال المعيار الذهبي لتصحيح مشاكل hydration.
  • WebPageTest -- للاختبار على أجهزة حقيقية من مواقع حقيقية. عرض الشرائط لا يُقدّر بثمن.
  • Sentry Performance Monitoring -- لتتبع أوقات استجابة API الحقيقية ومدد عرض مكونات الخادم في الإنتاج.
# أضف محلل الحزم إلى مشروعك
npm install @next/bundle-analyzer

// next.config.mjs
import withBundleAnalyzer from '@next/bundle-analyzer';

const config = withBundleAnalyzer({
  enabled: process.env.ANALYZE === 'true',
})({
  // your config here
});

export default config;

قم بتشغيل ANALYZE=true npm run build والنظر فعلاً إلى الإخراج. أضمن أنك ستجد مكتبة واحدة على الأقل أكبر بكثير مما كنت تتوقع.

مكونات الخادم: أكبر فوز ربما تستخدمه بشكل ناقص

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

لكن إليك حيث يخطئ الناس: يضيفون 'use client' بحماس شديد. لقد راجعت قاعدات أكواد حيث كانت 80% من المكونات عبارة عن مكونات عميل لأن المطورين اعتادوا على نموذج الفكر Pages Router القديم. كل توجيه 'use client' هو حدود hydration. كل حد hydration هو جافا سكريبت يجب على المتصفح تنزيله وتحليله وتنفيذه.

القاعدة التي أتبعها

احتفظ بالمكونات كمكونات خادم افتراضياً. أضف فقط 'use client' عندما تحتاج إليها حقاً:

  • معالجات الأحداث (onClick, onChange, إلخ)
  • useState, useEffect, useRef
  • واجهات برمجية خاصة بالمتصفح (localStorage, window, إلخ)
  • مكتبات جهات خارجية للعميل تستخدم hooks

نمط التكوين

عندما تحتاج إلى تفاعل في جزء صغير من مكون أكبر، لا تجعل الكل مكون عميل. بدلاً من ذلك:

// app/product/[id]/page.tsx (Server Component)
import { getProduct } from '@/lib/products';
import { AddToCartButton } from '@/components/AddToCartButton';
import { ProductReviews } from '@/components/ProductReviews';

export default async function ProductPage({ params }: { params: { id: string } }) {
  const product = await getProduct(params.id);

  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      {/* Only this small button is a client component */}
      <AddToCartButton productId={product.id} price={product.price} />
      {/* This entire review section stays on the server */}
      <ProductReviews productId={product.id} />
    </div>
  );
}

// components/AddToCartButton.tsx
'use client';

export function AddToCartButton({ productId, price }: { productId: string; price: number }) {
  const handleClick = () => {
    // cart logic
  };

  return <button onClick={handleClick}>Add to Cart -- ${price}</button>;
}

وحده هذا النمط قد قلل 40-60% من أحجام الحزم في المشاريع التي عملنا عليها من خلال ممارسة تطوير Next.js.

تحسين أداء Next.js: دليل شامل لعام 2026 - البنية المعمارية

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

يتعامل Turbopack في Next.js 15 مع tree-shaking بشكل أفضل مما فعل webpack، لكنه لا يمكن أن يإنقاذك من الواردات السيئة.

الواردات المسماة مهمة

// سيء -- يستورد المكتبة بأكملها
import _ from 'lodash';
const sorted = _.sortBy(items, 'name');

// جيد -- يستورد فقط ما تحتاجه
import sortBy from 'lodash/sortBy';
const sorted = sortBy(items, 'name');

// الأفضل -- هل تحتاج حتى إلى lodash؟
const sorted = items.toSorted((a, b) => a.name.localeCompare(b.name));

منتفخات الحزم الشائعة في عام 2026

المكتبة الحجم النموذجي (gzipped) البديل توفير الحجم
moment.js 72KB date-fns (tree-shakeable) ~60KB
lodash (كامل) 71KB Native JS / lodash-es ~65KB
chart.js 65KB lightweight-charts ~45KB
react-icons (الكل) 40KB+ حزم الرموز الفردية ~35KB
framer-motion 44KB motion (lite) أو CSS ~30KB

الواردات الديناميكية للمكونات الثقيلة

import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('@/components/Chart'), {
  loading: () => <div className="h-64 animate-pulse bg-gray-100 rounded" />,
  ssr: false, // Don't render on server if it's browser-only
});

أستخدم الواردات الديناميكية لأي شيء يزيد عن 20KB وليس فوق الثنية. المخططات البيانية، محررات النص الغنية، الخرائط، الناوافذ المنبثقة المعقدة -- كل شيء يتم تحميله بكسول.

تحسين الصور والوسائط

تحسنت مكون next/image بشكل كبير في Next.js 15. يدعم الآن AVIF افتراضياً (جنباً إلى جنب مع WebP)، وكشف الحجم التلقائي أكثر موثوقية.

تحسين الصور الحرجة

import Image from 'next/image';

// صورة البطل -- فوق الثنية، تحتاج إلى الأولوية
<Image
  src="/hero.jpg"
  alt="Product showcase"
  width={1200}
  height={630}
  priority // Preloads this image
  sizes="100vw"
  quality={80} // 80 is usually the sweet spot
/>

// صورة تحت الثنية -- تم تحميلها بكسول افتراضياً
<Image
  src="/feature.jpg"
  alt="Feature detail"
  width={600}
  height={400}
  sizes="(max-width: 768px) 100vw, 50vw"
  placeholder="blur"
  blurDataURL={feature.blurHash}
/>

صفة `sizes` ليست اختيارية

أرى هذا يُتخطى باستمرار. بدون صفة sizes صحيحة، ينزل المتصفح أكبر متغير صورة بغض النظر عن viewport. على الهاتف المحمول، هذا يحتمل تحميل صورة بحجم 2400px لشاشة 375px. حدد أحجامك. في كل وقت.

تحسين الفيديو

بالنسبة للفيديو، لا تستخدم علامة <video> مع ملف MP4 ضخم. في عام 2026، الخطوة هي:

  1. قم بترجمة الإخراج إلى جودات متعددة باستخدام FFmpeg أو خدمة مثل Mux
  2. استخدم بث HLS لأي شيء أطول من 10 ثوان
  3. بالنسبة للرسوم المتحركة القصيرة، فكر في WebM أو حتى AVIF متحركة
  4. تحميل الفيديوهات بكسول تحت الثنية باستخدام IntersectionObserver

استراتيجيات جلب البيانات والتخزين المؤقت

بسط Next.js 15 التخزين المؤقت مقارنة بالإعدادات المربكة في 14. التغيير الرئيسي: لا شيء يتم تخزينه مؤقتاً افتراضياً بعد الآن. أنت تختار الدخول في التخزين المؤقت بشكل صريح. هذا أكثر عقلانية بكثير.

التخزين المؤقت مع توجيه `use cache`

قدم Next.js 15 توجيه use cache (حالياً في canary، من المتوقع أن يكون مستقراً في 15.2):

async function getProducts() {
  'use cache';
  const products = await db.products.findMany();
  return products;
}

بالنسبة لواجهة برمجية fetch، يتم التحكم في التخزين المؤقت بشكل صريح:

// بدون تخزين مؤقت (الإعداد الافتراضي في Next.js 15)
const data = await fetch('https://api.example.com/data');

// تخزين مؤقت حتى إعادة التحقق اليدوية
const data = await fetch('https://api.example.com/data', {
  cache: 'force-cache',
});

// إعادة التحقق كل 60 ثانية
const data = await fetch('https://api.example.com/data', {
  next: { revalidate: 60 },
});

استراتيجية التخزين المؤقت حسب نوع المحتوى

نوع المحتوى الاستراتيجية إعادة التحقق مثال
صفحات التسويق Static (build-time) عند النشر الصفحة الرئيسية، حول
قوائم المنتجات ISR 60-300 ثانية صفحات الفئة
لوحة معلومات المستخدم Dynamic (no cache) كل طلب إعدادات الحساب
منشورات المدونة ISR 3600 ثانية محتوى مدفوع بـ CMS
نتائج البحث Dynamic + client cache نمط SWR صفحة البحث
بيانات API Server + CDN cache يختلف REST/GraphQL

بالنسبة للمشاريع التي تستخدم CMS بدون رؤوس، وهو معظم ما نبنيه في ممارسة تطوير CMS بدون رؤوس، ISR مع إعادة التحقق التي تُطلقها webhook هي المعيار الذهبي. تظهر تحديثات المحتوى في غضون ثوان دون إعادة بناء الموقع بالكامل.

أداء Edge Runtime والوسيط

يعمل Edge Runtime الخاص بك على عقد CDN بالقرب من المستخدمين. ينخفض TTFB بشكل كبير -- لقد قسنا 50-150ms TTFB من edge مقابل 300-800ms من origin منطقة واحدة.

لكن هناك مشكلة: لا يدعم Edge Runtime جميع واجهات برمجية Node.js. لا fs، crypto محدود، لا وحدات أصلية. يعمل الكود الخاص بك في عزلة V8، وليس عملية Node.js الكاملة.

متى يتم استخدام Edge

  • Middleware (فحوصات المصادقة، إعادة التوجيه، اختبار A/B)
  • مسارات API البسيطة التي لا تحتاج إلى اتصالات قاعدة البيانات
  • الصفحات ذات التخصيص التي لا يمكن تخزينها مؤقتاً بشكل ثابت

متى يتم تجنب Edge

  • استعلامات قاعدة البيانات الثقيلة (تجميع الاتصال لا يعمل بشكل جيد على الحافة)
  • المسارات التي تستخدم مكتبات خاصة بـ Node.js
  • أي شيء يحتاج إلى أكثر من 25ms من وقت CPU (وظائف edge لها حدود صارمة)
// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  // Fast geo-based redirect -- runs at the edge
  const country = request.geo?.country;

  if (country === 'DE' && !request.nextUrl.pathname.startsWith('/de')) {
    return NextResponse.redirect(new URL('/de' + request.nextUrl.pathname, request.url));
  }

  return NextResponse.next();
}

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'],
};

احتفظ بالوسيط نحيفاً. كل ميلي ثانية في الوسيط تضيف إلى تحميل كل صفحة واحدة.

تحسين طبقة قاعدة البيانات واجهة برمجية التطبيقات

تجميع الاتصال

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

استخدم جامع اتصالات:

  • PgBouncer لـ PostgreSQL (Supabase و Neon يتضمنان هذا)
  • Prisma Accelerate إذا كنت تستخدم Prisma (يضيف مجمع اتصال + ذاكرة تخزين عام)
  • Drizzle مع postgres.js يتعامل مع الاتصالات بكفاءة من الصندوق

أنماط تحسين الاستعلام

// سيء -- مشكلة استعلام N+1
const posts = await db.post.findMany();
for (const post of posts) {
  post.author = await db.user.findUnique({ where: { id: post.authorId } });
}

// جيد -- استعلام واحد مع join
const posts = await db.post.findMany({
  include: { author: true },
});

// الأفضل -- حدد فقط الحقول التي تحتاجها
const posts = await db.post.findMany({
  select: {
    id: true,
    title: true,
    slug: true,
    author: {
      select: { name: true, avatar: true },
    },
  },
});

جلب البيانات المتوازي

هذا هو أحد أكثر الأنماط تأثيراً وسوء الاستخدام بشكل إجرامي:

// سيء -- متسلسل (الوقت الإجمالي = مجموع جميع الجلب)
const products = await getProducts();
const categories = await getCategories();
const banners = await getBanners();

// جيد -- متوازي (الوقت الإجمالي = أبطأ جلب)
const [products, categories, banners] = await Promise.all([
  getProducts(),
  getCategories(),
  getBanners(),
]);

لقد شاهدت هذا التغيير الواحد يقلل أوقات تحميل الصفحة بمقدار النصف.

اختيار استراتيجية العرض

يعطيك Next.js 15 خمس استراتيجيات عرض. إليك كيفية تقرري:

Partial Prerendering (PPR)

PPR هي الخيار الأحدث والأكثر إثارة للاهتمام. يقوم بإنشاء shell الصفحة بشكل ثابت في وقت الإنشاء، ثم ينبثق المحتوى الديناميكي. يرى المستخدمون استجابة ثابتة فورية أثناء تحميل المحتوى الشخصي.

// app/page.tsx -- PPR enabled
import { Suspense } from 'react';
import { StaticHero } from '@/components/StaticHero';
import { PersonalizedRecommendations } from '@/components/Recommendations';

export default function HomePage() {
  return (
    <div>
      {/* Static shell -- served from CDN instantly */}
      <StaticHero />

      {/* Dynamic content -- streamed in */}
      <Suspense fallback={<RecommendationsSkeleton />}>
        <PersonalizedRecommendations />
      </Suspense>
    </div>
  );
}

تفعيل PPR في إعدادك:

// next.config.mjs
export default {
  experimental: {
    ppr: 'incremental',
  },
};

بالنسبة لمواقع التجارة الإلكترونية والمحتوى الثقيل، يعطيك PPR أفضل ما في العالمين -- تحميل سريع على CDN مع محتوى شخصي.

إدارة البرامج النصية للأطراف الثالثة

البرامج النصية للأطراف الثالثة هي قاتل الأداء الصامت. التحليلات، أدوات الدردشة، متتبعات الإعلانات، أدوات اختبار A/B -- يضيفون حتى الآن.

استخدم `next/script` بشكل استراتيجي

import Script from 'next/script';

// التحليلات -- تحميل بعد تفاعل الصفحة
<Script
  src="https://www.googletagmanager.com/gtag/js?id=G-XXXXX"
  strategy="afterInteractive"
/>

// أداة الدردشة -- تحميل عند الخمول
<Script
  src="https://widget.intercom.io/widget/xxxxx"
  strategy="lazyOnload"
/>

// اختبار A/B الحرج -- يجب تحميله قبل الطلاء
<Script
  src="https://cdn.optimizely.com/js/xxxxx.js"
  strategy="beforeInteractive"
/>

كن قاسياً. كل برنامج نصي تضيفه يكلف مستخدميك الوقت. أوصي بتدقيق البرامج النصية للأطراف الثالثة ربع سنوية. في نصف الوقت، ستجد برامج نصية لأدوات لا أحد من الفريق يستخدمها بعد الآن.

Partytown لتحميل قائم على Worker

بالنسبة للبرامج النصية للأطراف الثالثة غير الحرجة، فكر في Partytown. ينقل البرامج النصية إلى web worker، مما يحرر thread رئيسي:

<Script
  src="https://example.com/analytics.js"
  strategy="worker" // Runs in a web worker via Partytown
/>

البنية التحتية والنشر

حيث وكيف تقوم بالنشر أهم مما يعتقده معظم المطورين.

مقارنة المنصات لـ Next.js في عام 2026

المنصة دعم SSR Edge Functions Cold Start السعر البداية
Vercel كامل نعم (عام) ~50ms $20/mo (Pro)
Cloudflare Pages كامل (عبر OpenNext) نعم (عام) ~10ms $5/mo
AWS Amplify كامل محدود ~200ms الدفع حسب الاستخدام
Netlify كامل نعم (Deno) ~100ms $19/mo (Pro)
Self-hosted (Docker) كامل لا N/A تكلفة الخادم
Coolify / SST كامل يعتمد ~150ms تكلفة الخادم

Vercel لا تزال مسار أقل مقاومة لـ Next.js. يبنون الإطار عمل، يحسنون المنصة له. لكن Cloudflare Pages مع OpenNext أصبحت منافسة جادة في عام 2026، خاصة بالنسبة للمشاريع الحساسة للتكلفة.

بالنسبة للعملاء الذين يحتاجون إلى نشر self-hosted، حققنا نتائج جيدة مع حاويات Docker خلف CDN. يستغرق المزيد من الإعداد، لكنك تتحكم في البنية التحتية بالكامل. صفحة التسعير الخاصة بنا تغطي سيناريوهات نشر مختلفة إذا كنت تريد التحدث عما يعتبر معقولاً لمشروعك.

تخزين CDN والحافة مؤقتاً

بغض النظر عن المنصة، ضع CDN أمام كل شيء. الأصول الثابتة يجب أن تحتوي على رؤوس ذاكرة تخزين مؤقت ثابتة. صفحات ISR يجب أن تستخدم stale-while-revalidate. استجابات API يجب تخزينها مؤقتاً حيث ينطبق.

// بالنسبة لمسارات API التي يمكن تخزينها مؤقتاً
export async function GET() {
  const data = await getPopularProducts();

  return Response.json(data, {
    headers: {
      'Cache-Control': 'public, s-maxage=60, stale-while-revalidate=300',
    },
  });
}

المعايير الفعلية والدراسات الحالة

إليك أرقام فعلية من المشاريع التي حسناها في العام الماضي:

موقع التجارة الإلكترونية (Shopify Headless + Next.js 15)

  • قبل: LCP 4.2s, INP 380ms, bundle 487KB
  • بعد: LCP 1.4s, INP 89ms, bundle 156KB
  • التغييرات الرئيسية: Server Components لصفحات المنتج، تحسين الصور، إزالة 4 برامج نصية لأطراف ثالثة غير مستخدمة، التبديل من سلة عميل إلى server actions
  • تأثير الأعمال: 23% زيادة في معدل التحويل

لوحة معلومات SaaS (Next.js 14 → 15 migration)

  • قبل: Initial load 6.8s, TTI 8.2s
  • بعد: Initial load 2.1s, TTI 2.8s
  • التغييرات الرئيسية: الهجرة إلى App Router، تنفيذ البث للجداول غنية البيانات، إضافة PPR لصفحات مختلطة ثابتة/ديناميكية، جلب البيانات المتوازي

منصة المحتوى (Headless CMS + Next.js)

  • قبل: TTFB 890ms (SSR), LCP 3.1s
  • بعد: TTFB 120ms (ISR + edge), LCP 1.1s
  • التغييرات الرئيسية: التبديل من SSR إلى ISR مع إعادة التحقق حسب الطلب، نشر على الحافة، تحسين استعلامات CMS

هذه ليست أرقام مختارة. أنها تمثيلية لما يمكن تحقيقه عندما تطبق أنماط في هذا الدليل بشكل منهجي.

بالنسبة للمشاريع المبنية مع Astro بدلاً من Next.js -- خاصة المواقع الثقيلة بالمحتوى حيث متطلبات JavaScript ضئيلة -- يمكن أن تكون الأرقام أكثر إثارة للإعجاب. نحن نغطي ذلك في قدرات تطوير Astro.

الأسئلة الشائعة

كم تبلغ تكلفة تحسين أداء Next.js عادة؟ يعتمد بشدة على حجم وتعقيد التطبيق الخاص بك. بالنسبة لموقع مباشر، يمكن لسباق تحسين مركز المدة 1-2 أسابيع تحقيق نتائج درامية. بالنسبة للتطبيقات الكبيرة ذات المشاكل المعمارية العميقة، خطط لـ 4-8 أسابيع من إعادة الصياغة. عادة ما يؤتي الاستثمار على نفسه من خلال معدلات تحويل محسنة وتكاليف البنية التحتية المخفضة. توصل عبر صفحة جهات الاتصال إذا كنت تريد تقديراً محدداً.

هل Next.js 15 أسرع من Next.js 14؟ نعم، بشكل قابل للقياس. Turbopack كـ bundler افتراضي يقلل أوقات البناء بمقدار 30-50٪ وينتج حزم أصغر قليلاً. نموذج التخزين المؤقت المبسط يقلل حمل الخادم غير الضروري. و Partial Prerendering، عند استخدامه بشكل صحيح، يحسن الأداء المتصورة بشكل كبير. لقد رأينا تحسنات TTFB 15-25% في المتوسط بعد الهجرة.

هل يجب أن أستخدم Pages Router أو App Router في عام 2026؟ App Router، بكل الطرق. Pages Router لا تزال تعمل وتُدعم لا تزال، لكن كل ابتكار الأداء يحدث في App Router. مكونات الخادم، البث، PPR، server actions -- لا شيء من هذا متاح في Pages Router. إذا كنت تبدأ مشروع جديد، لا يوجد سبب لاستخدام Pages Router.

كيف يمكنني تقليل حجم حزمة Next.js بسرعة؟ قم بتشغيل محلل الحزم أولاً -- هذا يعرض لك بالضبط حيث يكون الوزن. ثم: استبدل المكتبات الثقيلة ببدائل أخف، استخدم الواردات الديناميكية للمكونات تحت الثنية، تأكد من أنك تستخدم الواردات المسماة من مكتبات tree-shakeable، وقيّم توجيهات 'use client'. هذه الخطوات الأربعة وحدها عادة ما تقلل حجم الحزمة بمقدار 30-50%.

هل منصة الاستضافة تؤثر فعلاً على أداء Next.js؟ أكثر مما تتوقع. البنية التحتية لـ Vercel مضبوطة على وجه التحديد لـ Next.js -- شبكتهم الحافة، تنفيذ ISR، و image optimization CDN مدمجة بإحكام. تعمل المنصات الأخرى بشكل جيد أيضاً، لكن قد تحتاج إلى تكوين الأشياء يدوياً التي تتعامل معها Vercel بالفعل. أكبر عامل هو التوزيع الجغرافي -- إذا كان المستخدمون لديك عام، فأنت بحاجة إلى نشر الحافة أو CDN، بغض النظر عن المنصة.

ما هو أكبر خطأ أداء Next.js الذي تراه؟ جعل كل شيء مكون عميل. لقد دققت قاعدة أكواد حيث تم لف شجرة الصفحة كاملة في 'use client' لأن المطور احتاج إلى معالج onClick واحد في المستوى الأعلى. هذا يفرض على المتصفح تنزيل وترطيب كل شيء، مما يلغي تماماً فوائد Server Component التي تجعل Next.js سريع. أعد هيكلة شجرة مكونك بحيث تكون مكونات العميل عقد صغيرة على مستوى الورقة.

كيف يقارن Partial Prerendering (PPR) بـ ISR العادي؟ ISR ينشئ الصفحة بالكامل في وقت الإنشاء ويعيد التحقق بشكل دوري. PPR ينشئ shell الثابت في وقت الإنشاء لكن يترك "ثقوب" ديناميكية تُملأ عبر البث في وقت الطلب. PPR أفضل لصفحات تخلط بين المحتوى الثابت والمخصص -- فكر في صفحة منتج حيث الوصف ثابت لكن المنتجات الموصى بها مخصصة. الاستجابة الأولية سريعة مثل النقاء الثابت، لكن المحتوى الديناميكي يظهر بدون تحميل صفحة كاملة.

هل يمكنني تحسين أداء Next.js بدون Vercel؟ بالتأكيد. التحسينات في هذا الدليل تعمل بغض النظر عن منصة الاستضافة. مكونات الخادم، تحسين الحزمة، تحسين الصور، استراتيجيات التخزين المؤقت، جلب البيانات المتوازي -- هذه اهتمامات على مستوى التطبيق. الميزات الخاصة بالمنصة مثل وظائف الحافة و دعم ISR المدمج تختلف، لكن أدوات مثل OpenNext تجعل من الممكن تشغيل Next.js الكامل على Cloudflare و AWS والمنصات الأخرى بخصائص أداء متشابهة.