در بخش قبل، مسیرهای محصول را مشخص کردیم: صفحه عمومی معرفی، ورود، فهرست سفارش و جزئیات. حالا می‌توانیم درباره رندر تصمیم بگیریم. پرسش درست این نیست که SSR بهتر است یا CSR؛ باید ببینیم هر صفحه چه داده‌ای دارد، چه زمانی تغییر می‌کند و کاربر برای انجام کارش به چه تعاملی نیاز دارد.
این مقاله سه شیوه رایج آماده‌کردن صفحه را روی همان پنل سفارش بررسی می‌کند. دانستن HTML، JavaScript و مفهوم درخواست HTTP کافی است. در پایان، برای هر مسیر یک تصمیم اولیه و چند شرط بازبینی خواهیم داشت. بحث مفهومی است و به پیش‌فرض کش یا API خاص یک نسخه از فریم‌ورک تکیه نمی‌کند.
سه نام درباره زمان و محل آماده‌شدن محتوا
در CSR، بخش مهمی از رابط پس از دریافت و اجرای JavaScript در مرورگر آماده می‌شود. ممکن است برای داده نیز درخواست جداگانه لازم باشد. در SSR، سرور برای یک درخواست صفحه، HTML را آماده می‌کند. در SSG، HTML از قبل ساخته و برای درخواست‌های بعدی ارائه می‌شود؛ بعضی ابزارها راه‌هایی برای بازسازی یا تازه‌کردن این خروجی دارند.
این تعریف‌ها تمام جزئیات یک فریم‌ورک مدرن را پوشش نمی‌دهند. صفحه می‌تواند ترکیبی باشد: پوسته‌ای که زود آماده می‌شود و بخشی که بعداً داده تازه می‌گیرد. همچنین محل اجرای یک کامپوننت با زمان کش‌شدن کل مسیر دقیقاً یک مفهوم نیست. بهتر است هنگام تصمیم، رفتار واقعی خروجی را بررسی کنیم و فقط به برچسب اکتفا نکنیم.
صفحه معرفی محصول: محتوای عمومی و تغییر کم
صفحه عمومی توضیح می‌دهد محصول چه کاری می‌کند و بازدیدکننده از کجا باید شروع کند. متن برای همه یکسان است و احتمالاً با هر درخواست تغییر نمی‌کند. آماده‌بودن محتوای اصلی در HTML و داشتن عنوان و توضیح مناسب، برای دسترسی و اشتراک صفحه ارزشمند است.
ساخت از پیش می‌تواند برای این مسیر مناسب باشد، به شرط اینکه راه به‌روزرسانی محتوا روشن باشد. اگر توضیح خدمت در پنل مدیریت تغییر کرد، چه زمانی نسخه عمومی تازه می‌شود؟ پاسخ «در انتشار بعدی» ممکن است برای یک سایت کافی باشد و برای محصول دیگر مناسب نباشد. سیاست تازگی باید همراه انتخاب رندر نوشته شود.
فهرست سفارش: داده خصوصی و متغیر
فهرست سفارش به هویت و مجوز کاربر وابسته است. دو کاربر ممکن است با یک URL، داده متفاوتی ببینند. بنابراین نمی‌توان خروجی خصوصی را مانند صفحه معرفی در کش عمومی گذاشت. باید روشن باشد احراز هویت کجا بررسی می‌شود و پاسخ تحت چه کلیدی و در چه محدوده‌ای نگهداری می‌شود.
SSR می‌تواند داده نخستین نمایش را روی سرور آماده کند و CSR می‌تواند تعامل و تازه‌سازی بعدی را انجام دهد. یک پنل کاملاً مبتنی بر مرورگر هم ممکن است مناسب باشد. انتخاب به تجربه موردنیاز، شکل نشست و توان تیم وابسته است. هیچ‌کدام، بررسی مجوز در API را حذف نمی‌کنند.
| مسیر | نوع داده | تصمیم اولیه قابل بررسی |
|---|---|---|
| معرفی محصول | عمومی و کم‌تغییر | ساخت از پیش با سیاست به‌روزرسانی روشن |
| ورود | فرم تعاملی و وضعیت نشست | HTML اولیه ساده با تعامل مرورگر |
| فهرست سفارش | خصوصی و متغیر | نمایش اولیه و تازه‌سازی متناسب با نشست |
| جزئیات سفارش | خصوصی با عملیات حساس | دریافت معتبر و کنترل تازگی پس از تغییر |
جزئیات سفارش: تازه‌بودن مهم‌تر از نام روش است
کاربر جزئیات را باز کرده و همکارش هم‌زمان سفارش را لغو می‌کند. اگر صفحه اول همچنان عملیات ارسال را نشان دهد، مهم نیست با SSR ساخته شده یا CSR؛ داده کهنه است. سرور باید هنگام عملیات، وضعیت جاری را کنترل کند و رابط هم نتیجه ناسازگاری را درست نشان دهد.
برای این صفحه، پرسش‌های مهم این‌ها هستند: داده چه زمانی دوباره دریافت می‌شود؟ بعد از تغییر وضعیت، کدام بخش تازه می‌شود؟ آیا بازگشت از صفحه دیگر، نسخه قبلی را نشان می‌دهد؟ رندر سمت سرور در هر درخواست می‌تواند تازگی اولیه بدهد، اما داده پس از نمایش نیز ممکن است تغییر کند.
محتوای اولیه و تعاملی‌شدن را جدا بسنجیم
ممکن است کاربر متن و جدول را ببیند ولی دکمه‌ها هنوز آماده تعامل نباشند. در برخی معماری‌ها، مرورگر باید JavaScript لازم را دریافت و به HTML آماده‌شده متصل کند؛ این مرحله را hydration می‌نامند. بنابراین «سریع دیده‌شدن» و «آماده استفاده‌شدن» لزوماً یک زمان ندارند.
اگر صفحه SSR حجم زیادی کد سمت مرورگر داشته باشد، همچنان ممکن است روی دستگاه ضعیف دیر آماده شود. در مقابل، یک رابط مرورگرمحور کوچک با کش مناسب ممکن است برای کار روزمره پنل تجربه خوبی بسازد. باید سناریوی واقعی و دستگاه نماینده را اندازه گرفت، نه اینکه از روی نام روش نتیجه قطعی اعلام کنیم.
Client Component به معنی نبود HTML اولیه نیست
در ابزارهایی مانند Next.js، مرز Server Component و Client Component درباره مسئولیت و دسترسی به قابلیت‌های سرور و مرورگر نیز هست. یک جزء تعاملی الزاماً به این معنی نیست که هیچ خروجی اولیه‌ای روی سرور ندارد. این تفاوت در مستندات رسمی ابزار باید با نسخه پروژه بررسی شود.
اشتباه رایج این است که برای افزودن یک دکمه تعاملی، کل صفحه و دریافت داده را بدون نیاز به سمت مرورگر ببریم. می‌توان مرز تعامل را کوچک نگه داشت: بخش داده و نمایش اولیه جدا، کنترل‌هایی مثل فیلتر یا دیالوگ در محدوده تعاملی مناسب. شکل دقیق این ترکیب به فریم‌ورک بستگی دارد.
کش، تصمیم مستقل و ضروری است
SSG بدون سیاست به‌روزرسانی ممکن است محتوای قدیمی بدهد. SSR هم اگر خروجی یا داده آن کش شود، الزاماً در هر درخواست اطلاعات تازه از منبع نمی‌خواند. CSR نیز می‌تواند از کش مرورگر یا کتابخانه داده استفاده کند. پس انتخاب شیوه رندر باید با نقشه کش همراه باشد.
برای هر داده بنویسید چه کسی حق دیدن آن را دارد، چه مدت کهنه‌بودن قابل قبول است و پس از ویرایش چگونه باطل یا تازه می‌شود. در اطلاعات خصوصی، خطای محدوده کش می‌تواند داده کاربر دیگری را نمایش دهد؛ این مسئله را با کنترل دسترسی و طراحی پاسخ بررسی می‌کنیم، نه فقط با تنظیم ظاهری صفحه.
خطا در هر مرحله رفتار متفاوت دارد
اگر دریافت داده پیش از آماده‌شدن HTML شکست بخورد، سرور باید خروجی مناسب بدهد. اگر تازه‌سازی بعدی در مرورگر شکست بخورد، شاید بهتر باشد داده قبلی با نشانه وضعیت باقی بماند. این دو حالت را نباید به یک صفحه سفید یا پیام کلی تبدیل کنیم.
در پنل سفارش، خطای تغییر وضعیت باید در همان زمینه عملیات نمایش داده شود. کاربر باید بداند آیا تغییر اعمال شده یا نتیجه نامعلوم است. مسیر بررسی دوباره اهمیت دارد؛ تلاش مجدد کورکورانه برای عملیات حساس ممکن است اثر تکراری ایجاد کند.
SEO فقط دلیل انتخاب رندر نیست
برای صفحه عمومی، عنوان، توضیح، canonical و محتوای قابل خواندن اهمیت دارند. برای صفحه خصوصی سفارش، هدف اصلی دیده‌شدن در موتور جست‌وجو نیست و باید سیاست نمایه‌سازی مناسب داشته باشد. این تفاوت از نقشه مسیر بخش قبل می‌آید.
آماده‌بودن HTML به‌تنهایی تضمین رتبه یا نمایه‌شدن نیست. کیفیت محتوا، ساختار پیوندها و دسترسی واقعی هم دخیل‌اند. به همین ترتیب، نمی‌توان گفت هر صفحه تعاملی الزاماً برای جست‌وجو نامناسب است. تصمیم را با نیاز همان مسیر و خروجی قابل بررسی بگیریم.
یک آزمایش مقایسه طراحی کنیم
یک صفحه فهرست با داده نماینده انتخاب کنید. زمان نمایش محتوای اصلی، زمان آماده‌شدن عملیات و رفتار هنگام خطای شبکه را ثبت کنید. اندازه داده، وضعیت کش و دستگاه باید در مقایسه مشخص باشند. در این مقاله چنین آزمایشی اجرا نشده و هیچ عدد عملکردی ارائه نمی‌شود.
برای تمرین، کنار هر مسیر جدول، سیاست تازگی و مرز داده خصوصی را بنویسید. سپس بررسی کنید چه بخش‌هایی واقعاً به JavaScript مرورگر نیاز دارند. بخش بعد درباره ساختار قابلیت‌محور فرانت است؛ تصمیم رندر را به مرز سفارش، کاربر و اجزای مشترک وصل خواهیم کرد.
مستندات تکمیلی
- Server و Client Components در Next.js؛ برای تفاوت مرز کامپوننت با روش ساده‌شده رندر.
- راهنمای کش Next.js؛ رفتار کش باید با نسخه و تنظیمات پروژه تطبیق داده شود.