على مدى الأشهر القليلة الماضية، كنا نعمل على تحسين أداء التطوير المحلي باستخدام Turbopack. في الإصدار 14.2، أصبح مرشح الإصدار من Turbopack متاحًا الآن للتطوير المحلي:
كنا نختبر Turbopack بشكل مكثف مع تطبيقات Vercel. على سبيل المثال، مع تطبيق vercel.com الكبير الذي يعمل بـ Next.js، لاحظنا:
أسرع بنسبة 76.7% في بدء تشغيل الخادم المحلي.
أسرع بنسبة 96.3% في تحديثات الكود مع Fast Refresh.
أسرع بنسبة 45.8% في تجميع المسار الأولي بدون تخزين مؤقت (لا يمتلك Turbopack تخزين مؤقت على القرص بعد).
لا يزال Turbopack اختياريًا ويمكنك تجربته باستخدام:
Terminal
next dev --turbo
سنركز الآن على تحسين استخدام الذاكرة، وتنفيذ التخزين المؤقت الدائم، و next build --turbo.
استخدام الذاكرة - قمنا ببناء أدوات منخفضة المستوى للتحقيق في استخدام الذاكرة. يمكنك الآن إنشاء ملفات تتبع تتضمن مقاييس الأداء ومعلومات استخدام الذاكرة العامة. تتيح هذه الملفات التحقيق في الأداء واستخدام الذاكرة دون الحاجة إلى الوصول إلى كود مصدر التطبيق.
التخزين المؤقت الدائم - نستكشف أيضًا أفضل خيارات البنية، ونخطط لمشاركة المزيد من التفاصيل في إصدار مستقبلي.
next build - بينما Turbopack غير متاح حاليًا للبناء، نجح 74.7% من الاختبارات بالفعل. يمكنك متابعة التقدم على areweturboyet.com/build.
حددنا تحسينًا للحد بين مكونات الخادم والعميل يسمح بإزالة الصادرات غير المستخدمة. على سبيل المثال، استيراد مكون Icon واحد من ملف يحتوي على "use client" لم يعد يتضمن جميع الأيقونات الأخرى من تلك الحزمة. يمكن أن يقلل هذا بشكل كبير من حجم حزمة JavaScript النهائية.
اختبار هذا التحسين على مكتبة شهيرة مثل react-aria-components قلل حجم الحزمة النهائية بنسبة -51.3%.
ملاحظة: لا يعمل هذا التحسين حاليًا مع ملفات البرميل (barrel files). في الوقت الحالي، يمكنك استخدام خيار التكوين optimizePackageImports:
بالنسبة لتطبيقات Next.js الكبيرة جدًا، لاحظنا تعطلًا بسبب نفاد الذاكرة (OOMs) أثناء عمليات البناء للإنتاج. بعد التحقيق في تقارير المستخدمين والتكرارات، وجدنا أن المشكلة الأساسية كانت في الحزمة الزائدة والتقليل (كان Next.js ينشئ ملفات JavaScript أقل وأكبر مع تكرار). قمنا بإعادة هيكلة منطق الحزمة وتحسين المترجم لهذه الحالات.
تظهر اختباراتنا الأولية أنه في تطبيق Next.js بسيط، انخفض استخدام الذاكرة وحجم ملفات التخزين المؤقت من 2.2 جيجابايت إلى أقل من 190 ميجابايت في المتوسط.
لتسهيل تصحيح أداء الذاكرة، أضفنا علامة --experimental-debug-memory-usage إلى next build. تعلم المزيد في توثيقنا.
إذا كنت تستخدم أسماء فئات عامة، قم باستيراد الأنماط العامة في نفس ملف JS/TS أيضًا.
لا نتوقع أن يؤثر هذا التغيير سلبًا على غالبية التطبيقات. ومع ذلك، إذا رأيت أي أنماط غير متوقعة عند الترقية، يرجى مراجعة ترتيب استيراد CSS وفقًا للتوصيات في توثيقنا.
يعد التخزين المؤقت جزءًا أساسيًا من بناء تطبيقات الويب السريعة والموثوقة. عند إجراء التغييرات، يتوقع كل من المستخدمين والمطورين تحديث التخزين المؤقت ليعكس أحدث التغييرات. كنا نستكشف كيفية تحسين تجربة التخزين المؤقت في Next.js في App Router.
ذاكرة التوجيه من جانب العميل هي طبقة تخزين مؤقت مصممة لتوفير تجربة تنقل سريعة عن طريق تخزين المسارات التي تمت زيارتها واستباقها على العميل.
بناءً على ملاحظات المجتمع، أضفنا خيارًا تجريبيًا staleTimes للسماح بتكوين فترة إبطال ذاكرة التوجيه من جانب العميل.
بشكل افتراضي، سيتم تخزين المسارات المستبقة (باستخدام مكون <Link> بدون خاصية prefetch) لمدة 30 ثانية، وإذا تم تعيين خاصية prefetch على true، فستكون 5 دقائق. يمكنك تجاوز هذه القيم الافتراضية عن طريق تحديد أوقات إعادة التحقق مخصصة في next.config.js:
يهدف staleTimes إلى تحسين التجربة الحالية للمستخدمين الذين يريدون المزيد من التحكم في إرشادات التخزين المؤقت، ولكنه ليس الحل الكامل. في الإصدارات القادمة، سنركز على تحسين دلالات التخزين المؤقت بشكل عام وتوفير حلول أكثر مرونة.
المسارات المتوازية والمتقاطعة التي تستدعي إجراءات الخادم (Server Actions) باستخدام revalidatePath أو revalidateTag ستعيد التحقق من صحة الذاكرة المؤقتة وتحديث الأقسام المرئية مع الحفاظ على العرض الحالي للمستخدم.
وبالمثل، سيؤدي استدعاء router.refresh الآن إلى تحديث الأقسام المرئية بشكل صحيح مع الحفاظ على العرض الحالي.
في الإصدار 14.1، بدأنا العمل على تحسين قابلية قراءة رسائل الأخطاء وتتبع المكدس (stack traces) عند تشغيل next dev. وقد استمر هذا العمل في الإصدار 14.2 ليشمل الآن رسائل أخطاء أفضل، وتحسينات في تصميم الطبقة العلوية (overlay) لكل من موجه التطبيق (App Router) وموجه الصفحات (Pages Router)، ودعم الوضعين الفاتح والداكن، وسجلات dev وbuild أكثر وضوحًا.
على سبيل المثال، تعد أخطاء الترطيب (Hydration errors) في React مصدرًا شائعًا للارتباك في مجتمعنا. بينما قمنا بتحسينات لمساعدة المستخدمين في تحديد مصدر عدم تطابق الترطيب (انظر أدناه)، فإننا نعمل مع فريق React لتحسين رسائل الأخطاء الأساسية وعرض اسم الملف الذي حدث فيه الخطأ.
قبل:
مثال على طبقة الأخطاء في Next.js قبل الإصدار 14.2.
بعد:
مثال على طبقة الأخطاء في Next.js بعد الإصدار 14.2.
في فبراير، أعلن فريق React عن الإصدار القادم لـ React 19. للتحضير لـ React 19، نعمل على دمج أحدث الميزات والتحسينات في Next.js، ونخطط لإصدار نسخة رئيسية لتنسيق هذه التغييرات.
الميزات الجديدة مثل الإجراءات (Actions) والخطافات (hooks) المرتبطة بها، والتي كانت متاحة في Next.js من قناة React التجريبية (React canary channel)، ستكون الآن متاحة لجميع تطبيقات React (بما في ذلك التطبيقات التي تعمل على جانب العميل فقط). نحن متحمسون لرؤية اعتماد أوسع لهذه الميزات في نظام React البيئي.
[تحسين] حماية الانحراف (Skew protection) مستقرة على Vercel (Docs).
[تحسين] جعل useSelectedLayoutSegment متوافقًا مع موجه الصفحات (Pages Router) (PR).
[تحسين] تخطي تحذيرات metadataBase عندما لا تحتاج عناوين URL المطلقة إلى الحل (PR).
[تحسين] إصلاح إجراءات الخادم التي لا يتم إرسالها عند تعطيل JavaScript عند النشر على Vercel (PR)
[تحسين] إصلاح الخطأ حول عدم العثور على إجراء الخادم في بيان الإجراءات (actions manifest) إذا تم تشغيله بعد الانتقال بعيدًا عن الصفحة المشار إليها، أو إذا تم استخدامه داخل قسم مسار متوازي غير نشط (PR)
[تحسين] إصلاح استيرادات CSS في المكونات المحملة بواسطة next/dynamic (PR).
[تحسين] تحذير عند فقدان خاصية unoptimized للصور المتحركة (PR).
[تحسين] عرض رسالة خطأ إذا لم يصدر images.loaderFile دالة افتراضية (PR)