وقتی اینترنت کاربر ضعیف است، Frontend حرفه‌ای چه کار می‌کند؟

وقتی درباره تجربه کاربری و کیفیت یک وب‌سایت صحبت می‌کنیم، معمولاً سرعت اینترنت بالا، دستگاه قدرتمند و شرایط ایده‌آل را در نظر می‌گیریم. اما کاربران همیشه با اینترنت سریع و پایدار وارد سایت نمی‌شوند. گاهی اینترنت موبایل ضعیف است، اتصال ناپایدار است یا کاربر با شبکه‌ای مواجه شده که Latency بالایی دارد.

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

یک Frontend حرفه‌ای فقط برای شرایط ایده‌آل طراحی نمی‌شود؛ بلکه باید بتواند در اینترنت ضعیف، قطعی موقت شبکه و حتی حالت Offline نیز تا حد ممکن تجربه قابل قبولی برای کاربر ایجاد کند.

در این مقاله بررسی می‌کنیم که Frontend حرفه‌ای هنگام ضعیف بودن اینترنت چه کارهایی انجام می‌دهد و چه تکنیک‌هایی می‌توانند عملکرد و تجربه کاربری سایت را در شبکه‌های کند و ناپایدار بهبود دهند.

اینترنت ضعیف چه تأثیری روی Frontend دارد؟

Frontend برای نمایش بسیاری از اطلاعات به منابع مختلفی وابسته است. درخواست‌های API، فایل‌های JavaScript، CSS، تصاویر، فونت‌ها و سایر منابع باید از سرور دریافت شوند.

وقتی شبکه ضعیف باشد، زمان دریافت این منابع افزایش پیدا می‌کند.

برای مثال ممکن است:

• درخواست‌های API دیر پاسخ دهند.

• تصاویر مدت زیادی برای نمایش زمان نیاز داشته باشند.

• فایل‌های JavaScript دیرتر دانلود شوند.

• صفحه مدت بیشتری در حالت Loading باقی بماند.

• درخواست‌ها با Timeout مواجه شوند.

• ارتباط با سرور به صورت موقت قطع شود.

• بعضی درخواست‌ها چندین بار ارسال شوند.

• کاربر تصور کند سایت خراب شده است.

بنابراین مشکل فقط «کند شدن سایت» نیست. مسئله اصلی این است که Frontend در برابر شرایط نامناسب شبکه چگونه واکنش نشان می‌دهد.

۱. نمایش تدریجی محتوا به جای انتظار برای کل صفحه

یکی از اشتباهات رایج در طراحی Frontend این است که صفحه تا زمانی که تمام اطلاعات دریافت نشده، چیزی برای نمایش نداشته باشد.

فرض کنید کاربر وارد صفحه محصول می‌شود و Frontend باید اطلاعات محصول، تصاویر، قیمت، نظرات و پیشنهادهای مرتبط را دریافت کند.

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

Frontend حرفه‌ای می‌تواند محتوا را Progressively نمایش دهد.

برای مثال:

1. ساختار اصلی صفحه نمایش داده شود.

2. اطلاعات مهم‌تر زودتر دریافت شوند.

3. بخش‌های کم‌اهمیت‌تر بعداً بارگذاری شوند.

4. تصاویر و محتوای سنگین به صورت Lazy Load دریافت شوند.

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

۲. استفاده از Skeleton Loading

Skeleton Loading یکی از تکنیک‌های مهم برای مدیریت تجربه کاربر هنگام دریافت اطلاعات است.

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

برای مثال، قبل از دریافت اطلاعات یک کارت محصول می‌توان چنین ساختاری نمایش داد:

┌─────────────────────────┐
│                         │
│       █████████         │
│                         │
├─────────────────────────┤
│ ███████████████         │
│ ██████████              │
│                         │
│ ████████                │
└─────────────────────────┘

Skeleton باعث می‌شود کاربر بهتر متوجه شود که چه چیزی در حال بارگذاری است.

این موضوع به‌خصوص در اینترنت ضعیف اهمیت زیادی دارد؛ زیرا کاربر ممکن است چند ثانیه منتظر دریافت اطلاعات بماند.

۳. اولویت‌بندی درخواست‌ها

در شرایط اینترنت ضعیف، Frontend نباید تمام منابع را با یک اولویت دریافت کند.

همه اطلاعات یک صفحه اهمیت یکسانی ندارند.

برای مثال در یک فروشگاه اینترنتی:

اطلاعات مهم:

• نام محصول

• قیمت

• موجودی

• دکمه خرید

اطلاعات کم‌اهمیت‌تر:

• محصولات پیشنهادی

• نظرات کاربران

• بنرهای تبلیغاتی

• محتوای پایین صفحه

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

این رویکرد باعث می‌شود کاربر سریع‌تر به مهم‌ترین قسمت صفحه دسترسی داشته باشد.

۴. Lazy Loading؛ همه چیز را از ابتدا دانلود نکنیم

یکی از راهکارهای مهم برای بهبود عملکرد سایت در اینترنت ضعیف، Lazy Loading است.

در Lazy Loading، منابعی که در ابتدای صفحه مورد نیاز نیستند، بلافاصله دانلود نمی‌شوند.

برای مثال اگر صفحه‌ای ۲۰ تصویر داشته باشد و فقط ۳ تصویر در محدوده قابل مشاهده کاربر باشند، نیازی نیست تمام تصاویر از همان ابتدا دانلود شوند.

تصاویر بعدی می‌توانند زمانی دریافت شوند که کاربر به آن بخش از صفحه نزدیک شود.

این روش باعث کاهش:

• حجم اولیه دانلود

• تعداد درخواست‌ها

• مصرف اینترنت

• زمان بارگذاری اولیه

می‌شود.

۵. کاهش حجم تصاویر

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

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

در چنین شرایطی، کاربر مجبور است حجم بیشتری از داده را دانلود کند.

برای بهینه‌سازی تصاویر می‌توان از روش‌هایی مانند:

• استفاده از فرمت‌های مدرن تصویر

• فشرده‌سازی تصاویر

• Responsive Images

• تعیین ابعاد مناسب

• Lazy Loading

• CDN

استفاده کرد.

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

۶. استفاده هوشمندانه از Cache

یکی از قدرتمندترین ابزارهای Frontend برای شرایط شبکه ضعیف، Caching است.

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

برای مثال اطلاعاتی مانند:

• تنظیمات رابط کاربری

• برخی تصاویر

• فایل‌های استاتیک

• داده‌هایی که به ندرت تغییر می‌کنند

می‌توانند تا مدت مشخصی Cache شوند.

در نتیجه، هنگام مراجعه مجدد کاربر، بخشی از محتوا بدون نیاز به دانلود مجدد در اختیار Frontend قرار می‌گیرد.

این موضوع می‌تواند در کاهش زمان بارگذاری و مصرف اینترنت تأثیر قابل توجهی داشته باشد.

۷. مدیریت صحیح خطاهای Network

در اینترنت ضعیف، خطا اجتناب‌ناپذیر است.

بنابراین Frontend حرفه‌ای باید برای خطاهای شبکه از قبل برنامه داشته باشد.

نمایش چنین پیامی:

Something went wrong.

معمولاً اطلاعات زیادی به کاربر نمی‌دهد.

بهتر است پیام خطا متناسب با شرایط باشد.

برای مثال:

اتصال به سرور برقرار نشد. اتصال اینترنت خود را بررسی کنید و دوباره تلاش کنید.

همچنین می‌توان یک دکمه Retry در اختیار کاربر قرار داد.

اتصال برقرار نشد.

[ تلاش مجدد ]

این کار بسیار بهتر از آن است که کاربر مجبور شود کل صفحه را Refresh کند.

۸. Retry هوشمند به جای درخواست‌های بی‌نهایت

ممکن است یک درخواست API به دلیل ناپایداری شبکه شکست بخورد.

یکی از راهکارها، Retry کردن درخواست است؛ اما Retry نیز باید هوشمندانه انجام شود.

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

برای مثال می‌توان بین درخواست‌ها فاصله ایجاد کرد:

Request
   ↓
Error
   ↓
Wait
   ↓
Retry
   ↓
Error
   ↓
Wait longer
   ↓
Retry

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

۹. تشخیص وضعیت اتصال شبکه

Frontend می‌تواند تا حدی وضعیت اتصال کاربر را بررسی کند.

برای مثال ممکن است برنامه متوجه شود که اتصال شبکه قطع شده یا دوباره برقرار شده است.

در چنین شرایطی می‌توان تجربه متفاوتی ارائه کرد.

مثلاً هنگام قطع اتصال:

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

و پس از بازگشت اتصال:

اتصال دوباره برقرار شد.
در حال همگام‌سازی اطلاعات...

این بازخورد ساده باعث می‌شود کاربر بهتر متوجه وضعیت برنامه شود.

البته تشخیص وضعیت شبکه به تنهایی به معنی اطمینان از دسترسی واقعی به Backend نیست؛ ممکن است دستگاه به شبکه متصل باشد اما سرور قابل دسترسی نباشد.

۱۰. Offline Support؛ سایت بدون اینترنت چه می‌کند؟

در برخی پروژه‌ها می‌توان تجربه Offline را نیز در نظر گرفت.

این موضوع مخصوصاً برای Web Appهایی که کاربران دائماً از آنها استفاده می‌کنند اهمیت دارد.

با استفاده از تکنولوژی‌هایی مانند Service Worker می‌توان برخی منابع و داده‌ها را در مرورگر Cache کرد تا در شرایط خاص حتی بدون اتصال مستقیم به اینترنت نیز بخشی از برنامه قابل استفاده باشد.

برای مثال یک برنامه می‌تواند:

• صفحات قبلی را نمایش دهد.

• اطلاعات ذخیره‌شده را نشان دهد.

• برخی عملیات را موقتاً ذخیره کند.

• بعد از بازگشت اینترنت، اطلاعات را Sync کند.

البته Offline-first برای همه وب‌سایت‌ها ضروری نیست و باید بر اساس نوع محصول و نیاز کاربران طراحی شود.

۱۱. Optimistic UI؛ منتظر پاسخ سرور نمانیم

یکی از تکنیک‌های جذاب برای افزایش سرعت ادراکی رابط کاربری، Optimistic UI است.

فرض کنید کاربر یک محصول را به لیست علاقه‌مندی‌ها اضافه می‌کند.

به جای اینکه UI تا دریافت پاسخ سرور منتظر بماند، می‌توان رابط کاربری را بلافاصله تغییر داد و هم‌زمان درخواست را به Backend ارسال کرد.

Click
  ↓
UI Update
  ↓
API Request
  ↓
Success → ادامه وضعیت
  ↓
Error → Rollback

در این حالت کاربر احساس می‌کند برنامه سریع‌تر واکنش نشان داده است.

البته این تکنیک زمانی مناسب است که عملیات قابل برگشت باشد و احتمال شکست آن قابل مدیریت باشد.

۱۲. Debounce و Throttle برای کاهش درخواست‌ها

بعضی قابلیت‌های Frontend می‌توانند در اینترنت ضعیف مشکل‌ساز شوند.

برای مثال یک Search Box را تصور کنید که با هر تغییر حروف یک درخواست API ارسال می‌کند.

کاربر عبارت زیر را تایپ می‌کند:

React

ممکن است برنامه برای هر حرف یک درخواست ارسال کند:

R
Re
Rea
Reac
React

در چنین شرایطی استفاده از Debounce می‌تواند تعداد درخواست‌ها را کاهش دهد.

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

این کار علاوه بر کاهش فشار روی Backend، مصرف اینترنت کاربر را نیز کاهش می‌دهد.

۱۳. Code Splitting و کاهش JavaScript اولیه

یکی از مشکلات مهم سایت‌های مدرن، حجم بالای JavaScript است.

اگر تمام کدهای برنامه در اولین ورود دانلود شوند، کاربر اینترنت ضعیف مجبور می‌شود حجم زیادی از اطلاعات را دریافت کند.

با استفاده از Code Splitting می‌توان JavaScript را به بخش‌های کوچک‌تر تقسیم کرد.

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

این موضوع در پروژه‌های بزرگ React و Next.js اهمیت بیشتری پیدا می‌کند.

هدف این است:

به جای اینکه کاربر کل برنامه را دانلود کند، فقط چیزی را دریافت کند که در همان لحظه به آن نیاز دارد.

۱۴. Font و فایل‌های استاتیک را فراموش نکنیم

گاهی توسعه‌دهندگان روی API و تصاویر تمرکز می‌کنند اما فایل‌های دیگری مانند Font نیز می‌توانند روی Performance تأثیر بگذارند.

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

بنابراین بهتر است:

• تعداد Fontها محدود شود.

• وزن‌های غیرضروری حذف شوند.

• فایل‌ها بهینه شوند.

• فونت‌ها با استراتژی مناسب Load شوند.

در Frontend حرفه‌ای، حتی جزئیات کوچک نیز در مجموع روی تجربه کاربر تأثیر می‌گذارند.

۱۵. تجربه کاربر مهم‌تر از نمایش یک Loading است

یکی از مهم‌ترین نکات در طراحی برای اینترنت ضعیف این است که فقط به Performance واقعی فکر نکنیم؛ Perceived Performance نیز اهمیت دارد.

ممکن است دو سایت دقیقاً یک API را در ۳ ثانیه دریافت کنند.

اما در سایت اول:

۳ ثانیه صفحه خالی

و در سایت دوم:

ساختار صفحه
↓
Skeleton
↓
محتوای اصلی
↓
اطلاعات تکمیلی

نمایش داده شود.

از نظر زمان دریافت API تفاوتی وجود ندارد، اما تجربه کاربر می‌تواند کاملاً متفاوت باشد.

Frontend حرفه‌ای تلاش می‌کند زمان انتظار را برای کاربر قابل فهم و قابل تحمل کند.

۱۶. طراحی برای شرایط واقعی، نه فقط اینترنت ایده‌آل

هنگام توسعه یک سایت، تست کردن آن فقط روی اینترنت سریع کافی نیست.

باید شرایط مختلف را نیز در نظر گرفت:

• اینترنت سریع

• اینترنت متوسط

• اینترنت کند

• Latency بالا

• قطع موقت اتصال

• Timeout

• پاسخ دیرهنگام API

• خطای Server

• Offline

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

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

Frontend حرفه‌ای یعنی مدیریت شرایط غیرایده‌آل

Frontend حرفه‌ای فقط مجموعه‌ای از Componentها، Animationها و طراحی‌های زیبا نیست.

یکی از نشانه‌های بلوغ یک Frontend این است که برای شرایط غیرعادی نیز طراحی شده باشد.

وقتی اینترنت کاربر ضعیف می‌شود، یک Frontend خوب باید بتواند:

• منابع مهم را اولویت‌بندی کند.

• محتوا را تدریجی نمایش دهد.

• از Skeleton استفاده کند.

• تصاویر را بهینه کند.

• درخواست‌های غیرضروری را کاهش دهد.

• داده‌های مناسب را Cache کند.

• خطاهای شبکه را مدیریت کند.

• Retry هوشمند داشته باشد.

• در صورت نیاز از Offline Support استفاده کند.

• از Optimistic UI بهره ببرد.

• JavaScript اولیه را کاهش دهد.

• وضعیت اتصال را به شکل مناسبی به کاربر نشان دهد.

در نهایت، هدف این نیست که اینترنت ضعیف را «سریع» کنیم؛ چون Frontend نمی‌تواند کیفیت شبکه کاربر را تغییر دهد.

هدف این است که حتی وقتی شبکه ضعیف است، محصول همچنان قابل استفاده، قابل فهم و قابل اعتماد باقی بماند.

جمع‌بندی

کاربر همیشه با بهترین اینترنت، جدیدترین گوشی یا قدرتمندترین کامپیوتر وارد سایت شما نمی‌شود.

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

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

تکنیک‌هایی مانند Lazy Loading، Caching، Code Splitting، Skeleton Loading، Retry، Optimistic UI، Debounce و Offline Support می‌توانند به ساخت رابط‌هایی کمک کنند که در شرایط واقعی نیز تجربه قابل قبولی ارائه می‌دهند.

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

کلمات کلیدی اصلی

• Frontend حرفه‌ای

• اینترنت ضعیف

• بهینه سازی Frontend

• Performance در Frontend

• بهبود تجربه کاربری

• بهینه سازی سایت

• سرعت سایت

کلمات کلیدی فرعی و مرتبط

• Slow Network

• Network Resilience

• Offline First

• Offline Support

• Lazy Loading

• Skeleton Loading

• Optimistic UI

• Code Splitting

• Caching در Frontend

• Retry Request

• Exponential Backoff

• Debounce

• Web Performance

• تجربه کاربری در اینترنت ضعیف

• مدیریت خطا در Frontend

• کاهش مصرف اینترنت سایت

زمان مطالعه

حدود ۸ تا ۱۰ دقیقه