تکصفحهای یا چندصفحهای؟

در ده سال گذشته، پیشفرض بسیاری از تیمها این شده که هر سایتی را با فریمورکهای تکصفحهای بسازند.
برای بخشی از محصولات درست است. برای بخش بزرگی — بهویژه سایتهای محتوایی و فروشگاهی — انتخاب پیشفرض بدی است که هزینهاش دیر معلوم میشود.
تفاوت واقعی در یک جمله
چندصفحهای (MPA): هر کلیک، صفحهٔ جدیدی از سرور میگیرد. مرورگر کار ناوبری را انجام میدهد.
تکصفحهای (SPA): یک بار برنامه بارگذاری میشود و از آن به بعد، جاوااسکریپت محتوا را عوض میکند بدون بارگذاری مجدد.
تفاوت اصلی این است که در حالت دوم، شما کارهایی را که مرورگر رایگان انجام میداد، خودتان باید پیادهسازی کنید.
آنچه SPA پنهان میکند
فهرست کارهایی که در MPA رایگاناند و در SPA باید ساخته و نگهداری شوند:
ناوبری و آدرس. دکمهٔ برگشت مرورگر، تاریخچه، لینک قابل اشتراکگذاری. کتابخانه هست، ولی باید درست پیکربندی و تست شود.
وضعیت بارگذاری. در MPA مرورگر خودش نشانگر پیشرفت دارد. در SPA باید برای هر بخش، حالت بارگذاری و حالت خطا طراحی کنید.
مدیریت خطا. اگر درخواستی شکست بخورد، کاربر چه میبیند؟ در MPA صفحهٔ خطا؛ در SPA هر چیزی که خودتان ساخته باشید — و اگر نساخته باشید، صفحهٔ خالی.
پیمایش صفحه. بازگشت به موقعیت قبلی هنگام برگشت.
دسترسپذیری. در تغییر صفحه، فوکوس باید جابهجا شود و صفحهخوان باید بفهمد چیزی عوض شده. در MPA خودکار است؛ در SPA باید دستی انجام شود و تقریباً همیشه فراموش میشود.
سئو. اگر محتوا فقط بعد از اجرای جاوااسکریپت بیاید، ریسک دارید — که در سئوی فنی گفتیم.
هیچکدام از اینها غیرممکن نیستند. اما مجموعشان هزینهٔ واقعی است که در تصمیم اولیه دیده نمیشود.
آنچه SPA واقعاً بهتر انجام میدهد
منصفانه باشیم — جاهایی هست که SPA بهوضوح برنده است:
تعامل زیاد و حالتدار. ویرایشگر، داشبورد با فیلترهای درهم، ابزار طراحی، سامانهای که کاربر ساعتها در آن میماند.
بهروزرسانی لحظهای. چت، اعلان زنده، همکاری همزمان.
پس از بارگذاری اولیه، سریعتر است. جابهجایی بین بخشها بدون صبر.
کار آفلاین.
نکتهٔ مشترک: جایی که کاربر مدت طولانی در برنامه میماند. آنجا هزینهٔ بارگذاری اولیه یک بار پرداخت میشود و سود مکرر میدهد.
معیار انتخاب، ساده
یک سؤال: کاربر معمولی چند دقیقه در هر نشست میماند؟
-
کمتر از یک دقیقه، بیشتر بازدیدها ورودی مستقیم از جستوجو → چندصفحهای. مقالهٔ بلاگ، صفحهٔ خدمات، سایت شرکتی.
-
چند دقیقه، کاربر چند صفحه میبیند → هر دو ممکن است. رندر سمت سرور با تعامل جزئی، معمولاً بهترین ترکیب.
-
دهها دقیقه، کاربر وارد میشود و کار میکند → تکصفحهای.
جدول
| چندصفحهای | تکصفحهای | |
|---|---|---|
| بارگذاری اول | سریع | کند |
| جابهجایی بعدی | متوسط | سریع |
| سئو | آسان | نیاز به کار |
| دسترسپذیری | آسان | نیاز به کار |
| پیچیدگی توسعه | کم | زیاد |
| تعامل پیچیده | سخت | آسان |
| کار روی شبکهٔ ضعیف | بهتر | بدتر |
آن سطر آخر برای بازار ما مهم است: SPA سنگین روی شبکهٔ همراه متغیر، همه یا هیچ است. اگر بستهٔ اولیه نیاید، کاربر صفحهٔ سفید میبیند. در MPA، صفحهای که آمده کار میکند حتی اگر بقیه کند باشد.
گزینهٔ میانی، که معمولاً درستترین است
بحث «SPA یا MPA» امروز تا حد زیادی قدیمی شده، چون گزینهٔ سومی وجود دارد که بهترین هر دو را میگیرد:
رندر سمت سرور یا تولید ایستا، بهعلاوهٔ تعامل جزئی.
یعنی صفحه بهصورت HTML کامل از سرور میآید — سریع، قابل ایندکس، دسترسپذیر — و فقط بخشهایی که واقعاً تعامل دارند، جاوااسکریپت میگیرند.
نتیجه: صفحهٔ محتوایی صفر جاوااسکریپت میفرستد، و فرم جستوجو فقط کد خودش را.
برای اکثر سایتهای شرکتی، فروشگاهی و محتوایی، این جواب درست است. همین سایتی که میخوانید با همین رویکرد ساخته شده.
اشتباهاتی که مکرر دیدهایم
SPA برای سایت شرکتی پنجصفحهای. پیچیدگی بیدلیل، سئوی سختتر، و بارگذاری اولیهٔ کندتر — برای هیچ.
MPA برای داشبورد پیچیده. هر تغییر فیلتر، بارگذاری کامل صفحه. کاربری که روزی صد بار فیلتر عوض میکند، عذاب میکشد.
SPA بدون رندر سمت سرور برای فروشگاه. صفحهٔ محصولی که موتور جستوجو نمیبیند، یعنی فروشگاهی که پیدا نمیشود.
فرض اینکه فریمورک اجباری است. بخش زیادی از تعاملهای ساده — منوی بازشو، تب، آکاردئون — با HTML و CSS و چند خط جاوااسکریپت انجام میشود. فریمورک برای مسائل پیچیده است، نه برای هر تعاملی.
سؤالی که پیش از تصمیم باید بپرسید
«این صفحه اصلاً چقدر تعامل دارد؟»
جواب صادقانه برای بیشتر صفحات وب — صفحهٔ محصول، مقاله، دربارهٔ ما، تماس — «تقریباً هیچ» است. آن صفحات به فریمورک نیاز ندارند.
و اگر بخشی از محصولتان واقعاً پیچیده است، میتوانید ترکیب کنید: سایت عمومی چندصفحهای برای سئو و سرعت، پنل کاربری تکصفحهای برای تعامل. این تفکیک، هر دو مسئله را با ابزار مناسب خودش حل میکند.