اگر چند ماه با یک پروژه‌ی واقعی Next.js کار کرده باشی، احتمالاً با چند دردسر آشنا هستی.

همان لحظه‌ای که پروژه بزرگ‌تر می‌شود، next dev دیگر مثل روزهای اول سبک نیست. یک تغییر کوچک در کد ممکن است باعث شود چند ثانیه منتظر بمانید تا همه چیز دوباره آماده شود. Buildهای CI طولانی‌تر می‌شوند و روی بعضی سیستم‌ها حتی باز کردن پروژه تبدیل به یک تست صبر می‌شود.

Next.js 16.3 دقیقاً روی همین مشکلات دست گذاشته است.

ما قبلا یکسری از آپدیت هایی که خود وبسایت نکست داده بود را بررسی کردیم مثل instant navigation, Ai Improvements و تغییرات توربو پک. نکته‌ی جالب اینجاست که بخش زیادی از این تغییرات بدون اینکه حتی یک خط کد پروژه‌ات را تغییر بدی فعال می‌شوند.

یعنی ممکن است فقط با تغییر نسخه‌ی Next.js، همان پروژه‌ی قبلی سریع‌تر اجرا شود.

بهبودهایی که همین امروز روی پروژه‌های موجود تأثیر می‌گذارند

بخش مهم معرفی Next.js 16.3 همین جمله است: این نسخه برای پروژه‌های موجود هم بهبود دارد.

معمولاً وقتی یک نسخه‌ی جدید منتشر می‌شود، اولین سوال این است که «چه API جدیدی اضافه شده؟»

اما این بار سوال بهتر این است که:

«توی پروژه‌ی فعلی من چه چیزی بهتر می‌شود؟»

جواب کوتاه:

• مصرف کمتر RAM در حالت توسعه
• Build سریع‌تر
• Type checking سریع‌تر
• SSR سریع‌تر
• درخواست‌های کمتر برای Prefetch
• Cache بهتر برای فایل‌های استاتیک

یعنی حتی اگر هیچ‌کدام از قابلیت‌های جدید را استفاده نکنی، باز هم احتمالاً تفاوت را حس می‌کنی.

Turbopack حالا تا ۹۰٪ حافظه‌ی کمتری مصرف می‌کند

یکی از بزرگ‌ترین تغییرات Next.js 16.3 مربوط به Turbopack است.

تا قبل از این نسخه، یکی از شکایت‌های رایج درباره‌ی dev server پروژه‌های بزرگ، مصرف بالای حافظه بود.

روی یک پروژه‌ی کوچک شاید متوجه نشوی، اما وقتی پروژه چند صد Route، تعداد زیادی dependency و فایل‌های زیاد دارد، مصرف RAM می‌تواند خیلی سریع بالا برود.

در Next.js 16.3 دو قابلیت مهم به‌صورت پیش‌فرض فعال شده‌اند:

• Disk Cache برای توسعه
• Memory Eviction

ترکیب این دو باعث شده Turbopack بتواند بهتر تصمیم بگیرد چه چیزهایی را در حافظه نگه دارد و چه چیزهایی را از RAM خارج کند.

نتیجه در بعضی پروژه‌های بزرگ چشمگیر بوده است.

البته مثل همیشه این عددها را نباید کورکورانه برای همه‌ی پروژه‌ها انتظار داشت. نوع پروژه، تعداد Routeها، dependencyها و نحوه‌ی استفاده از Server Componentها تأثیر زیادی دارند.

اما جهت تغییر مشخص است: Turbopack دیگر فقط دنبال سریع‌تر شدن نیست، بلکه می‌خواهد در پروژه‌های واقعی منابع کمتری مصرف کند.

به نظر من این یکی از آن تغییراتی است که توسعه‌دهنده‌هایی که لپ‌تاپ معمولی دارند بیشتر از همه حسش می‌کنند.

چون سریع بودن فقط این نیست که یک build چند ثانیه زودتر تمام شود؛ اگر سیستم وسط کار شروع کند به swap کردن و کند شدن، آن سرعت روی کاغذ چندان کاربردی نیست.

Buildهای سریع‌تر با FileSystem Cache

همان Cacheای که از Next.js 16.1 برای dev معرفی شده بود، حالا وارد مرحله‌ی بعدی شده و برای next build هم فعال شده است.

ایده ساده است:

اگر قبلاً چیزی محاسبه شده و هنوز معتبر است، دوباره از صفر انجامش نده.

این موضوع مخصوصاً در CI مهم است.

در پروژه‌هایی که مرتب build می‌شوند، زمان زیادی صرف کارهای تکراری می‌شود. حالا Turbopack می‌تواند بخشی از این خروجی‌ها را ذخیره کند و در buildهای بعدی دوباره استفاده کند.

طبق تست‌های تیم Next.js، بعضی پروژه‌ها در CI تا ۵.۵ برابر build سریع‌تر داشته‌اند.

جدول مقایسه زمان Build

این تغییر برای تیم‌هایی که روزانه چندین deploy انجام می‌دهند، شاید از هر قابلیت ظاهری دیگری مهم‌تر باشد.

چون چند ثانیه در یک build شاید مهم نباشد، اما وقتی صدها بار تکرار می‌شود، تبدیل به زمان واقعی تیم می‌شود.

TypeScript 7 و Type Checking سریع‌تر

Next.js 16.3 هم‌زمان با نسل جدید TypeScript آمده است.

TypeScript 7 یک تغییر مهم دارد: بخش‌هایی از آن با یک پیاده‌سازی Native بازنویسی شده که هدفش سرعت بالاتر در type checking است.

طبق اعلام تیم TypeScript، این نسخه می‌تواند در بعضی سناریوها چند برابر سریع‌تر باشد.

برای استفاده از آن در پروژه‌ی Next.js کافی است نسخه‌ی dependency را تغییر بدهی:

npm i -D typescript@^7

البته اینجا یک نکته وجود دارد.

سرعت بالاتر همیشه به معنی این نیست که همه‌ی پروژه‌ها دقیقاً همان نتیجه را می‌بینند. پروژه‌هایی با Type پیچیده، monorepoها یا dependencyهای سنگین ممکن است تفاوت بیشتری حس کنند.

اما برای پروژه‌هایی که TypeScript بخش بزرگی از زمان build را می‌گیرد، این تغییر ارزش بررسی دارد.

رندر سمت سرور سریع‌تر با Native Node.js Streams

یکی از تغییرات فنی جالب Next.js 16.3 در لایه‌ی رندرینگ App Router اتفاق افتاده است.

برای اینکه مرورگر بتواند محتوا را به‌صورت تدریجی دریافت کند، Next.js از Streamها استفاده می‌کند. این مدل باعث می‌شود لازم نباشد کاربر تا آماده شدن کل صفحه صبر کند و بخش‌های آماده‌شده زودتر ارسال شوند.

اما یک مشکل وجود داشت.

در محیط Node.js، Streamهای داخلی Node با Web Streams که در استانداردهای جدید وب استفاده می‌شوند، یکسان نیستند. در نتیجه بخشی از زمان و منابع صرف تبدیل بین این دو مدل می‌شد.

در Next.js 16.3 این مسیر تغییر کرده و در لایه‌ی رندرینگ App Router از Native Node.js Streams استفاده می‌شود.

نتیجه؟

کاهش overhead در SSR.

طبق بنچمارک‌های تیم Next.js، اپلیکیشن‌ها در شرایط بار بالا می‌توانند تا ۲۲٪ درخواست بیشتری را با همان شرایط پردازش کنند.

یعنی:

این تغییر شاید چیزی نباشد که هنگام توسعه‌ی روزمره فوراً ببینی، اما روی سرویس‌هایی که ترافیک بالا دارند، تفاوتش خودش را نشان می‌دهد.

این هم از آن دسته تغییراتی است که معمولاً کاربران متوجه وجودش نمی‌شوند؛ فقط متوجه می‌شوند سایت در فشار بالا بهتر دوام می‌آورد.

مستندات نسخه‌بندی‌شده برای AI Agentها

یکی از مسیرهایی که Next.js در نسخه‌های جدید جدی‌تر دنبال می‌کند، آماده کردن پروژه‌ها برای ابزارهای هوش مصنوعی است.

چند سال پیش اگر کسی می‌گفت فریمورک باید برای AI Agentها بهینه شود، احتمالاً خیلی‌ها تصور می‌کردند منظور فقط autocomplete داخل ادیتور است.

اما الان موضوع بزرگ‌تر شده.

Agentها قرار است کد بخوانند، تغییر بدهند، تست اجرا کنند و حتی تصمیم‌های معماری پیشنهاد کنند.

مشکل اینجاست که یک Agent بدون اطلاعات کافی درباره‌ی پروژه، ممکن است تصمیم‌هایی بگیرد که با ساختار پروژه هماهنگ نیست.

مثلاً:

• از API اشتباه استفاده کند.
• الگوی قدیمی پروژه را نادیده بگیرد.
• قوانین داخلی تیم را رعایت نکند.

Next.js 16.3 با اضافه کردن پشتیبانی بهتر برای Versioned Docs این مسیر را ساده‌تر می‌کند.

ایده این است که Agent بتواند به اطلاعات دقیق‌تر و هماهنگ با نسخه‌ی مورد استفاده‌ی پروژه دسترسی داشته باشد.

یعنی اگر پروژه روی Next.js 16.3 است، Agent لازم نیست از اطلاعات مربوط به نسخه‌های قدیمی‌تر استفاده کند.

این تغییر شاید امروز برای همه ضروری نباشد، اما اگر با ابزارهایی مثل Cursor، Claude Code یا Agentهای مشابه کار می‌کنی، اهمیتش بیشتر می‌شود.

درخواست‌های Prefetch کمتر، کنترل بهتر روی شبکه

یکی از بخش‌هایی که در Next.js همیشه بین سرعت و مصرف منابع تعادل ایجاد می‌کرد، Prefetch بود.

Prefetch یعنی قبل از اینکه کاربر روی یک لینک کلیک کند، Next.js حدس بزند که احتمالاً کاربر به آن صفحه می‌رود و بخشی از اطلاعات را از قبل دریافت کند.

این کار باعث Navigation سریع‌تر می‌شود.

اما یک مشکل دارد.

اگر تعداد لینک‌ها زیاد باشد، ممکن است درخواست‌های زیادی ایجاد شود؛ حتی برای صفحاتی که کاربر هیچ‌وقت باز نمی‌کند.

در Next.js 16.3 رفتار Prefetch بهینه‌تر شده تا درخواست‌های غیرضروری کمتر شوند.

هدف این نیست که Prefetch حذف شود؛ چون هنوز یکی از دلایل اصلی حس سریع بودن Next.js است.

هدف این است که هوشمندتر عمل کند.

یعنی:

• اطلاعات مهم زودتر آماده شوند.
• درخواست‌های بی‌مصرف کمتر شوند.
• فشار روی سرور و شبکه کاهش پیدا کند.

Cache بهتر برای Static Assetها

فایل‌های استاتیک مثل:

• تصویرها
• فایل‌های CSS
• JavaScript bundleها
• فونت‌ها

معمولاً باید مدت زیادی Cache شوند.

اما تنظیمات اشتباه Cache می‌تواند مشکل‌ساز شود.

اگر خیلی کوتاه باشد، کاربر مدام فایل‌های تکراری دانلود می‌کند.

اگر خیلی طولانی باشد، ممکن است نسخه‌ی قدیمی فایل نمایش داده شود.

Next.js 16.3 در این بخش رفتار Cache فایل‌های استاتیک را بهتر کرده تا استفاده از منابع شبکه منطقی‌تر شود.

این تغییر شاید در پروژه‌های کوچک دیده نشود، اما در سایت‌هایی که حجم زیادی Asset دارند، می‌تواند روی سرعت واقعی کاربران تأثیر بگذارد.

Custom Error Boundaries

مدیریت خطا در اپلیکیشن‌های بزرگ همیشه یک بخش مهم بوده است.

وقتی یک صفحه یا یک بخش از UI خراب می‌شود، اینکه کل برنامه از کار بیفتد تجربه‌ی خوبی نیست.

React و Next.js مدت‌ها امکان Error Boundary داشتند، اما Next.js 16.3 کنترل‌های بیشتری برای ساخت تجربه‌ی خطای بهتر ارائه می‌دهد.

هدف این است که بتوانی به جای نمایش یک صفحه‌ی خطای عمومی، رفتار دقیق‌تری برای بخش‌های مختلف برنامه داشته باشی.

مثلاً:

• یک بخش از داشبورد خراب شود.
• اما منوی اصلی همچنان کار کند.
• کاربر بتواند دوباره تلاش کند.

این مدل در اپلیکیشن‌های بزرگ اهمیت زیادی دارد.

Built-in Glob Imports؛ وارد کردن فایل‌ها ساده‌تر می‌شود

یکی دیگر از تغییرات کوچک اما کاربردی، اضافه شدن قابلیت Glob Import داخلی است.

گاهی در پروژه‌ها لازم است تعداد زیادی فایل را بر اساس یک الگو وارد کنی.

مثلاً:

• همه‌ی فایل‌های Markdown یک پوشه
• همه‌ی کامپوننت‌های یک مسیر
• همه‌ی فایل‌های ترجمه

قبلاً معمولاً برای این کار سراغ ابزارهای جانبی می‌رفتیم.

حالا Next.js پشتیبانی بهتری برای این سناریوها فراهم کرده است.

این قابلیت شاید به تنهایی دلیل آپدیت نباشد، اما در پروژه‌های Content-heavy یا سیستم‌های بزرگ مدیریت فایل، کار را راحت‌تر می‌کند.

Instant Navigation؛ نزدیک‌تر شدن Next.js به حس SPA

تا اینجا بیشتر درباره‌ی تغییرات زیرساختی صحبت کردیم.

اما بخشی که احتمالاً کاربران نهایی بیشتر حس می‌کنند، Navigation جدید است.

یکی از چالش‌های همیشگی Next.js این بوده:

چطور سرعت SPA را داشته باشیم، بدون اینکه مزیت‌های Server Components و Server Rendering را از دست بدهیم؟

Next.js 16.3 تلاش می‌کند این فاصله را کمتر کند.

Partial Prefetching

در نسخه‌های قبلی، Prefetch همیشه یک تعادل سخت داشت.

اگر زیاد Prefetch کنی:

• درخواست زیاد می‌شود.
• داده‌ی اضافی مصرف می‌شود.

اگر کم Prefetch کنی:

• Navigation کندتر حس می‌شود.

Partial Prefetching راه وسط است.

به جای اینکه کل Route را از قبل آماده کند، فقط بخش‌هایی که برای شروع Navigation لازم هستند را دریافت می‌کند.

مثلاً Shell صفحه سریع آماده می‌شود و بخش‌های سنگین‌تر بعداً می‌رسند.

نتیجه چیزی شبیه اپلیکیشن‌های SPA است، اما با معماری Server-Driven.

Instant Insights؛ فهمیدن اینکه Navigation واقعاً چه اتفاقی می‌افتد

یکی از مشکلات توسعه‌دهنده‌ها با اپلیکیشن‌های مدرن این است که وقتی یک صفحه کند باز می‌شود، همیشه مشخص نیست مشکل دقیقاً کجاست.

آیا مشکل از:

• دریافت داده از API است؟
• Server Component زمان زیادی می‌برد؟
• Bundle سمت کلاینت بزرگ است؟
• Prefetch درست انجام نشده؟
• Cache کار نکرده؟

در Next.js 16.3 ابزارهای بهتری برای مشاهده‌ی رفتار Navigation اضافه شده تا توسعه‌دهنده بتواند دقیق‌تر بفهمد هنگام جابه‌جایی بین صفحات چه اتفاقی می‌افتد.

این همان چیزی است که در پروژه‌های بزرگ اهمیت پیدا می‌کند.

در پروژه‌ی کوچک شاید بگویی:

«این صفحه فقط یک ثانیه دیرتر باز می‌شود.»

اما در یک محصول واقعی، همین یک ثانیه می‌تواند نتیجه‌ی چندین مشکل کوچک باشد که پیدا کردنشان بدون ابزار مناسب سخت است.

Navigation Inspector؛ دیدن مسیر واقعی جابه‌جایی صفحات

وقتی یک کاربر روی یک لینک کلیک می‌کند، اتفاقات زیادی پشت صحنه رخ می‌دهد.

Next.js باید:

• Route را پیدا کند.
• داده‌های لازم را آماده کند.
• Cache را بررسی کند.
• Server Componentها را پردازش کند.
• نتیجه را به کلاینت برساند.

Navigation Inspector کمک می‌کند این مسیر واضح‌تر دیده شود.

این ابزار مخصوصاً برای زمانی کاربردی است که احساس می‌کنی یک Route باید سریع باشد، اما در عمل نیست.

به جای حدس زدن، می‌توانی ببینی زمان دقیق کجا مصرف شده.

این تغییر شاید برای همه‌ی توسعه‌دهنده‌ها روزانه استفاده نشود، اما برای Debug کردن پروژه‌های بزرگ ارزش زیادی دارد.

بهبود Incremental Static Regeneration (ISR)

ISR یکی از قابلیت‌هایی است که باعث شد Next.js در سال‌های اخیر بین سایت‌های محتوایی و اپلیکیشن‌های ترکیبی محبوب شود.

ایده ساده است:

صفحه را Static تولید کن، اما اجازه بده بعداً بدون Build کامل به‌روزرسانی شود.

مشکل همیشه این بوده که Cache و Revalidation در پروژه‌های بزرگ می‌تواند پیچیده شود.

Next.js 16.3 روی رفتار ISR هم بهبودهایی آورده تا مدیریت این سناریوها قابل پیش‌بینی‌تر شود.

این موضوع مخصوصاً برای سایت‌هایی که:

• محتوای زیاد دارند.
• تغییرات مداوم دارند.
• ولی نمی‌خواهند هر تغییر باعث Build کامل شود.

مهم است.

تست راحت‌تر با Playwright Test Helper

تست کردن Navigation و رفتارهای سمت سرور همیشه کمی سخت‌تر از تست کردن کامپوننت‌های ساده بوده است.

چون باید رفتار واقعی مرورگر، شبکه، Route و Rendering را هم در نظر بگیری.

Next.js 16.3 یک helper جدید برای Playwright ارائه کرده تا نوشتن تست‌های مرتبط با اپلیکیشن‌های Next.js راحت‌تر شود.

این یعنی تست کردن مواردی مثل:

• Navigation
• Loading State
• Error State
• رفتارهای App Router

کمتر نیاز به کد تکراری دارد.

برای تیم‌هایی که تست E2E جدی دارند، این تغییر کوچک نیست.

بهبودهای AI؛ Next.js برای دوره‌ی Agentها آماده‌تر می‌شود

اگر بخش‌های مختلف Next.js 16.3 را کنار هم بگذاری، یکی از پیام‌های واضح این نسخه این است:

فریمورک‌ها دیگر فقط برای انسان‌ها نوشته نمی‌شوند.

بخش زیادی از کدنویسی آینده احتمالاً با کمک Agentها انجام می‌شود.

اما یک Agent خوب فقط با داشتن یک مدل زبانی ساخته نمی‌شود.

باید:

• ساختار پروژه را بفهمد.
• قوانین تیم را بداند.
• بداند از چه الگوهایی استفاده کند.
• بداند کدام API مربوط به کدام نسخه است.

برای همین Next.js روی چند بخش کار کرده است.

AGENTS.md؛ قراردادن قوانین پروژه برای Agentها

اگر با ابزارهای AI کار کرده باشی، احتمالاً این مشکل را دیده‌ای.

هر بار باید توضیح بدهی:

«در این پروژه از Server Component استفاده کن.»

«این پوشه را تغییر نده.»

«برای API از این الگو استفاده کن.»

«قبل از تغییر، تست‌ها را اجرا کن.»

فایل AGENTS.md قرار است همین اطلاعات را به شکل استاندارد در اختیار Agent قرار دهد.

در واقع یک فایل راهنما برای هوش مصنوعی پروژه است.

چیزی شبیه README، اما با مخاطب متفاوت.

README برای انسان‌هاست.

AGENTS.md برای Agentها.

Skills؛ اضافه کردن توانایی‌های مشخص به Agent

یک Agent عمومی همه چیز را نمی‌داند.

گاهی می‌خواهی یک Agent دقیقاً برای یک کار خاص آماده باشد.

مثلاً:

• ساخت Componentهای UI
• کار با Database
• نوشتن تست
• مدیریت API

Skills این امکان را می‌دهد که توانایی‌های مشخص‌تری تعریف شود.

این مدل باعث می‌شود Agent به جای اینکه هر بار از صفر تصمیم بگیرد، یک مسیر مشخص داشته باشد.

Versioned Docs برای جلوگیری از اشتباه Agentها

یکی از مشکلات رایج ابزارهای AI این است که ممکن است اطلاعات قدیمی استفاده کنند.

مثلاً یک Agent ممکن است کدی پیشنهاد دهد که برای Next.js 14 درست بوده، اما در Next.js 16 روش بهتری وجود داشته باشد.

Versioned Docs کمک می‌کند Agent اطلاعات هماهنگ با نسخه‌ی واقعی پروژه دریافت کند.

این موضوع در فریمورک‌هایی مثل Next.js که مرتب تغییر می‌کنند، اهمیت زیادی دارد.

قابلیت‌های آزمایشی Next.js 16.3

همه‌ی تغییرات این نسخه برای استفاده‌ی عمومی آماده نیستند.

چند قابلیت هنوز Experimental هستند.

React Compiler مبتنی بر Rust

React Compiler یکی از پروژه‌هایی است که هدفش بهینه‌سازی خودکار React است.

ایده این است که کامپایلر بتواند بخشی از بهینه‌سازی‌هایی را انجام دهد که قبلاً توسعه‌دهنده باید دستی انجام می‌داد.

چیزهایی مثل:

• جلوگیری از Render اضافی
• مدیریت بهتر Memoization
• بهینه‌سازی محاسبات

نسخه‌ی Rust-based React Compiler تلاش می‌کند این فرآیند را سریع‌تر و مقیاس‌پذیرتر کند.

البته چون هنوز Experimental است، احتمالاً نباید همین فردا آن را روی Production فعال کرد.

اما مسیر آینده مشخص است.

React دارد بیشتر به سمت یک مدل Compiler-driven حرکت می‌کند.

Network Resilience؛ مقاوم‌تر شدن در برابر مشکلات شبکه

اپلیکیشن‌های واقعی همیشه در شرایط ایده‌آل اجرا نمی‌شوند.

کاربر ممکن است:

• اینترنت ضعیف داشته باشد.
• اتصال لحظه‌ای قطع شود.
• درخواست‌ها timeout شوند.

Network Resilience تلاش می‌کند رفتار اپلیکیشن در این شرایط بهتر شود.

هدف این نیست که مشکل شبکه جادویی حل شود.

هدف این است که برنامه در برابر این اتفاق‌ها رفتار قابل پیش‌بینی‌تری داشته باشد.

آیا باید همین حالا به Next.js 16.3 آپدیت کنیم؟

مثل همیشه جواب به پروژه بستگی دارد.

اگر یک پروژه‌ی حساس Production داری که چند هفته است بدون مشکل کار می‌کند، بهتر است طبق روال معمول:

• نسخه را در محیط تست بررسی کنی.
• Build را چک کنی.
• تست‌ها را اجرا کنی.
• بعد منتشر کنی.

اما اگر:

• پروژه‌ی بزرگی داری.
• RAM زیادی در dev مصرف می‌شود.
• CI Build طولانی است.
• از App Router استفاده می‌کنی.
• با ابزارهای AI کار می‌کنی.

Next.js 16.3 احتمالاً یکی از آن آپدیت‌هایی است که ارزش امتحان کردن دارد.

چیزی که این نسخه را جالب می‌کند این نیست که یک API عجیب اضافه کرده.

اتفاق مهم‌تر این است که تقریباً همه‌جا کمی بهتر شده.

Turbopack سبک‌تر شده.

Buildها سریع‌تر شده‌اند.

SSR بهینه‌تر شده.

Navigation روان‌تر شده.

و ابزارهای AI حالا بیشتر بخشی از اکوسیستم Next.js محسوب می‌شوند.

به نظر من Next.js 16.3 بیشتر از اینکه یک نسخه‌ی «با چند قابلیت جدید» باشد، یک قدم برای بالغ‌تر شدن فریمورک است.

قدم بعدی احتمالاً فقط سریع‌تر کردن اپلیکیشن نیست؛ بلکه ساختن محیطی است که انسان و Agent بتوانند کنار هم راحت‌تر محصول بسازند.