ढिलो इन्टरनेटमा पनि चल्ने एप कसरी बनाउने

हाम्रो अफिसको Wi-Fi मा जुन एप एक सेकेन्डमा खुल्छ, त्यही एप गाउँमा एक डन्डी डाटामा तीस सेकेन्डसम्म सेतो स्क्रिन देखाउँछ। प्रयोगकर्ताले त्यतिन्जेल पर्खँदैनन्। यो लेख त्यो तीस सेकेन्ड घटाउने व्यावहारिक तरिकाबारे हो।

नेपालमा एप बनाउँदा ढिलो इन्टरनेट "edge case" होइन। पहाडमा, बसमा यात्रा गर्दा, भवनको भित्री कोठामा, नेट कमजोर हुनु सामान्य कुरा हो। मोबाइल डाटा किन्नु पर्ने भएकोले मान्छेहरू कुन एपले कति डाटा खान्छ भन्ने पनि ख्याल गर्छन्। मैले अंग्रेजीमा Designing Apps for Slow Internet Connections मा डिजाइनको पक्ष लेखेको थिएँ। यहाँ म बढी प्राविधिक र व्यावहारिक कुरा गर्छु, जुन मैले कृषि ज्ञान प्लेटफर्म, NovaRestro र आफ्नै portfolio मा प्रयोग गरेको छु।

पहिले नाप्नुस्, अनि सुधार्नुस्

सबैभन्दा पहिलो काम: आफ्नो एप ढिलो नेटमा कस्तो चल्छ भनेर आफैं हेर्ने। Chrome DevTools को Network tab मा throttling विकल्प छ। त्यहाँ "Slow 3G" वा "Fast 3G" छानेर एप खोल्नुस्।

पहिलो पटक यसो गर्दा म आफैं लाजमा परेँ। मेरो MacBook मा छिटो खुल्ने पेज Slow 3G मा धेरै बेर खाली देखियो। त्यसपछि मैले यो नियम बनाएँ: हरेक नयाँ फिचर merge गर्नुअघि एक पटक throttled नेटमा चलाएर हेर्ने।

• Network tab: कुन फाइल कति ठूलो छ, कुन request ले कति समय लियो।
• Lighthouse: performance को मोटामोटी तस्बिर।
• साँच्चैको फोन: सस्तो Android फोनमा मोबाइल डाटा चलाएर हेर्नु DevTools भन्दा धेरै इमानदार हुन्छ।

Payload सानो बनाउनुस्

ढिलो नेटमा हरेक KB को मूल्य छ। सबैभन्दा धेरै फाइदा प्रायः यहीँबाट आउँछ।

• तस्बिर: WebP वा AVIF प्रयोग गर्नुस्, सही साइजमा। मोबाइलमा 400px चौडा देखिने तस्बिरका लागि 3000px को फोटो पठाउनु बेकार हो। Next.js को Image component ले यो धेरै हदसम्म आफैं गर्छ।
• JavaScript: ठूला library सोचेर मात्र थप्नुस्। मिति format गर्न मात्र भारी package राख्नु पर्दैन।
• Code splitting: हरेक पेजलाई चाहिने कोड मात्र पठाउनुस्। Admin panel को कोड सामान्य प्रयोगकर्तालाई किन पठाउने?
• API response: list मा पूरा object होइन, देखाउन चाहिने field मात्र पठाउनुस्। Pagination अनिवार्य राख्नुस्।
• Font: धेरै weight र धेरै font परिवार नलोड गर्नुस्। नेपाली font थप्दा फाइल साइज झनै बढ्छ, त्यसैले subset र font-display: swap प्रयोग गर्नुस्।

Django REST Framework मा list र detail का लागि छुट्टाछुट्टै serializer बनाउनु मलाई धेरै काम लाग्यो। list मा पाँच field, detail मा बीस field। यति सानो परिवर्तनले response धेरै हलुका हुन्छ।

Caching: एक पटक लोड भएको कुरा फेरि नमाग्नुस्

Static फाइल (JS, CSS, font, तस्बिर) लाई लामो समयसम्म cache गर्न browser लाई भन्नुस्। Next.js ले build गर्दा फाइलको नाममा hash राख्छ, त्यसैले लामो cache राख्दा पनि नयाँ deploy मा नयाँ फाइल नै लोड हुन्छ। Nginx बाट serve गर्दा header आफैं मिलाउनुपर्छ।

Data का लागि म TanStack Query प्रयोग गर्छु। एक पटक ल्याएको data cache मा रहन्छ, र प्रयोगकर्ता अर्को पेजमा गएर फर्किँदा तुरुन्तै देखिन्छ। पृष्ठभूमिमा चुपचाप नयाँ data ल्याइन्छ।

const { data } = useQuery({
  queryKey: ["crops", region],
  queryFn: () => fetchCrops(region),
  staleTime: 5 * 60 * 1000,
  retry: 3,
});

staleTime ले पाँच मिनेटसम्म फेरि request नपठाउन भन्छ। कृषि जानकारी जस्तो छिटो नबदलिने data का लागि यो पर्याप्त हो।

Service worker: नेट नभए पनि केही देखाउने

Service worker browser र नेटवर्कबीच बस्ने सानो script हो। यसले request रोकेर cache बाट जवाफ दिन सक्छ। मैले यसबारे How Service Workers Actually Work मा विस्तारमा लेखेको छु।

व्यवहारमा म यसो गर्छु:

1. App shell cache: layout, CSS, मुख्य JS पहिलो पटकमै cache गर्ने, ताकि दोस्रो पटक एप तुरुन्त खुलोस्।
2. Offline पेज: नेट छैन भने browser को डाइनोसर होइन, आफ्नै सफा पेज देखाउने जसमा "नेट छैन, जडान भएपछि फेरि प्रयास गर्नुहोस्" लेखिएको होस्।
3. पढिसकेको सामग्री: प्रयोगकर्ताले पढेका लेख cache मा राख्ने, ताकि नेट गएपछि पनि फेरि खोल्न मिलोस्।

मेरो portfolio मा पनि service worker, offline पेज र update toast छ। नयाँ version आएपछि प्रयोगकर्तालाई सानो सूचना देखिन्छ, जबर्जस्ती reload हुँदैन।

Optimistic UI: पर्खाउन नदिने

ढिलो नेटमा सबैभन्दा झन्झट लाग्ने कुरा हो, बटन थिचेपछि केही नहुनु। प्रयोगकर्ताले फेरि थिच्छ, फेरि थिच्छ, अनि तीन वटा अर्डर जान्छ।

Optimistic UI को अर्थ हो, server को जवाफ आउनुअघि नै UI मा परिणाम देखाउनु। जस्तै, वेटरले अर्डरमा आइटम थप्दा त्यो तुरुन्त सूचीमा देखिन्छ, र पृष्ठभूमिमा server मा जान्छ। असफल भयो भने UI फर्काउने र स्पष्ट सन्देश देखाउने।

तर हरेक कुरामा यो गर्नु हुँदैन। भुक्तानी जस्तो कुरामा server ले पक्का नगरेसम्म "सफल" देखाउनु खतरनाक हुन्छ। मेरो नियम: गल्ती भए सजिलै सच्याउन मिल्ने काममा optimistic, पैसा जोडिएको काममा होइन।

Retry र timeout

ढिलो नेटमा request बीचमै अड्किन्छ। केही कुरा ख्याल गर्नुस्:

• Timeout राख्नुस्: request अनन्तसम्म नपर्खियोस्। निश्चित समयपछि रोकेर प्रयोगकर्तालाई बताउनुस्।
• Retry मा ढिलाइ बढाउँदै: तुरुन्तै दश पटक retry गर्दा कमजोर नेट झन् थिचिन्छ। पहिलो पटक एक सेकेन्ड, अनि दुई, अनि चार, यसरी बढाउनुस्।
• दोहोरिन नदिने: अर्डर वा form submit जस्ता काममा हरेक request लाई unique id दिनुस्, ताकि retry हुँदा server ले एउटै काम दुई पटक नगरोस्।
• Retry बटन: स्वतः retry असफल भए प्रयोगकर्तालाई आफैं प्रयास गर्ने बटन दिनुस्।

Loading, error र खाली अवस्था कसरी देखाउने भन्नेबारे Handling Loading, Error and Empty States Properly मा लेखेको छु। ढिलो नेटमा यी अवस्था प्रयोगकर्ताले धेरै पटक देख्छन्, त्यसैले यिनलाई राम्रो बनाउनु झनै जरुरी छ।

Skeleton र progressive loading

सेतो खाली स्क्रिनभन्दा पेजको आकार देखाउने skeleton धेरै राम्रो हुन्छ। प्रयोगकर्तालाई केही भइरहेको छ भन्ने थाहा हुन्छ। Next.js मा loading.tsx र streaming ले पेजको केही भाग पहिले देखाउन मद्दत गर्छ। महत्त्वपूर्ण सामग्री पहिले, कम महत्त्वको कुरा पछि।

मेरो checklist

नयाँ प्रोजेक्ट सुरु गर्दा म यी प्रश्न सोध्छु:

1. Slow 3G मा पहिलो पेज कति सेकेन्डमा केही देखाउँछ?
2. सबैभन्दा ठूलो फाइल कुन हो, र त्यो चाहिन्छ नै?
3. नेट गएमा प्रयोगकर्ताले के देख्छ?
4. बटन दुई पटक थिच्दा के हुन्छ?
5. सस्तो Android फोनमा चलाएर हेरियो?

अन्तिम कुरा

ढिलो नेटमा राम्रो चल्ने एप छिटो नेटमा झन् राम्रो चल्छ। यो काम नेपालका लागि मात्र होइन, सबै प्रयोगकर्ताका लागि फाइदाजनक छ। तर नेपालमा यो नगरे एप धेरैका लागि चल्दै चल्दैन। सुरुदेखि नै throttling खोलेर विकास गर्ने बानी बसाल्नुस्, पछि सच्याउनुभन्दा धेरै सस्तो पर्छ।

साना व्यवसायका लागि सफ्टवेयर बनाउँदा offline किन चाहिन्छ भन्ने कुरा मैले नेपाली साना व्यवसायलाई कस्तो सफ्टवेयर चाहिन्छ? मा पनि लेखेको छु।