Next.js در مقیاس تجاری فقط «SSR روشن» نیست. باید استراتژی رندر، مرز کلاینت/سرور، تصویر، متادیتا و مشاهده‌پذیری را طوری بچینید که هم خزنده راضی باشد هم کاربر روی شبکهٔ واقعی.
۱. انتخاب استراتژی رندر
SSG برای محتوای ثابت، ISR برای کاتالوگ‌های نیمه‌پویا، SSR برای دادهٔ کاربرمحور و شخصی‌سازی حساس. ترکیب اشتباه — مثلاً SSR همه‌جا — هزینهٔ سرور و تأخیر TTFB می‌سازد.
App Router را با مرز واضح Server/Client طراحی کنید. آبشار داده (waterfall) بین layout و page را با Promise موازی و caching کنترل کنید.
هر صفحه‌ای که Client Component غیرضروری شود، هزینهٔ سئو و TTI را بی‌صدا بالا می‌برد.
— محمدعلی هاشمی، Frontend Lead
۲. داده و کش بدون بدهی
fetch با revalidate، tag-based revalidation و جداسازی دادهٔ عمومی از نشست کاربر جلوی stale HTML و نشت داده را می‌گیرد.
الگوهای پیشنهادی
- کش عمومی روی CDN برای صفحات بازاریابی
- revalidate هدفمند بعد از publish محتوا
- دادهٔ احراز هویت فقط در مسیرهای خصوصی
۳. سئو در اپ JS
Metadata API، sitemap پویا، canonical و دادهٔ ساختاریافته را از همان منبع محتوا بسازید. خزنده باید HTML معنادار ببیند، نه اسکلت خالی منتظر hydrate.
۴. بودجه عملکرد
تصویر next/image، تقسیم باندل، فونت محلی و حذف polyfill زائد را به Definition of Done ببندید. LCP و INP را در مسیرهای حیاتی مانیتور کنید.
۵. پایداری در پروداکشن
خطای مرز، لاگ ساختاریافته، ردیابی کندی API و تست رگرسیون Core Web Vitals بخشی از تحویل‌اند — نه کار «بعداً».
پایداری Next یعنی تصمیم رندر آگاهانه + بودجه عملکرد + مانیتور. استودیو هش همین الگو را در محصولات پرترافیک اعمال می‌کند.
