وقتی پاسخ Strapi کند است: تجربهٔ پیش‌رندر و ISR در Next.js
تجربه‌ام از بهبود بلاگ Arvand Termo Tec با پیش‌رندر و ISR؛ رفتار revalidate = 60 و نتیجهٔ تست production محلی، با توضیح محدودیت‌ها.
در اصل به فارسی در لینکدین منتشر شده است. خواندن پست اصلی در لینکدین ↗(در زبانهٔ جدید باز می‌شود)
یک درخواست کوچک، یک انتظار طولانی
یه درخواست حدود ۲۰ کیلوبایتی به Strapi، نزدیک ۲۹ ثانیه طول کشید تا اولین بایت پاسخ رو برگردونه! داشتیم روی عملکرد بخش بلاگ وب‌سایت Arvand Termo Tec کار می‌کردیم؛ پروژه‌ای که فرانت‌اندش با Next.js توسعه داده شده و محتوای بلاگش از Strapi میاد.
کش سمت مرورگر باعث شده بود رفت‌وبرگشت بین صفحات، درخواست تکراری ایجاد نکنه. ولی وقتی کش سمت سرور خالی بود، اولین بازدید همچنان به پاسخ کند CMS وابسته می‌موند. اینجا بود که کاربرد واقعی پیش‌رندر و ISR برام روشن‌تر شد.
انتقال کار پرهزینه از مسیر کاربر
تغییری که پیاده کردم این بود:
- موقع build روی Vercel، اطلاعات منتشرشده از Strapi دریافت می‌شه و صفحات لیست بلاگ و مقاله‌ها از قبل ساخته می‌شن.
- کاربر جدید، HTML و داده‌های آمادهٔ صفحه رو دریافت می‌کنه. بنابراین نمایش محتوای موجود، نیازمند یک درخواست هم‌زمان به Strapi نیست.
- با تنظیم revalidate = 60، صفحه بعد از ۶۰ ثانیه واجد شرایط بازسازی می‌شه.
export const revalidate = 60;بعد از ۶۰ ثانیه چه اتفاقی می‌افته؟
نکته‌ای که خیلی برام باحال بود همین بخش آخره: رسیدن به ثانیهٔ ۶۰، خودش درخواستی ایجاد نمی‌کنه. اولین درخواست بعد از این بازه، معمولاً نسخهٔ ذخیره‌شده رو دریافت می‌کنه و Next.js بازسازی صفحه رو در پس‌زمینه انجام می‌ده. بعد از اتمام موفق بازسازی، درخواست‌های بعدی نسخهٔ جدید رو می‌گیرن.
اگر CMS در این بازسازی خطا بده، آخرین نسخهٔ موفق حفظ می‌شه.
البته این فرایند، صفحهٔ بازشده در مرورگر کاربر رو خودکار تغییر نمی‌ده. کش سرور و state فعلی مرورگر، دو لایهٔ جدا هستن.
تست بدون دسترسی به CMS
برای بررسی نتیجه، در یک تست production محلی، بعد از build یک سرور جدید اجرا کردیم و CMS رو از دسترس خارج کردیم. دریافت کامل صفحات لیست حداکثر ۲۳ میلی‌ثانیه و مقاله‌ها حداکثر ۱۱ میلی‌ثانیه طول کشید.
نتیجه و محدودیت‌های این تغییر
این معماری، خود Strapi رو سریع‌تر نکرده؛ تأخیر backend همچنان نیاز به بررسی داره. همچنین مقاله‌ای که بعد از build منتشر شده، اگر هنوز warm نشده باشه، ممکنه در اولین درخواست منتظر CMS بمونه.
برای من، ارزش اصلی این تغییر، انتقال کار پرهزینه از مسیر درخواست کاربر به مرحلهٔ build و بازسازی پس‌زمینه بود. همین جزئیات معماری می‌تونن تأثیر بزرگی روی تجربهٔ اولین بازدید بذارن.