𝗠𝘆 𝗔𝗣𝗜 𝗥𝗲𝘀𝗽𝗼𝗻𝗱𝗲𝗱 𝗶𝗻 𝟰 𝗺𝘀, 𝗯𝘂𝘁 𝗡𝗮𝘃𝗶𝗴𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗶𝗹𝗹 𝗙𝗲𝗹𝘁 𝗦𝗹𝗼𝘄

मी SvelteKit आणि Rust API वापरून बनवलेल्या एका प्रोजेक्ट मॅनेजमेंट ॲपचे डीबगिंग करत होतो.

माझ्या लोकल मशीनवर सर्व काही झटपट वाटत होते. पण VPS वर, नेव्हिगेशन जड (heavy) वाटत होते. Tickets किंवा Timeline सारखी पेजेस उघडायला खूप वेळ लागत होता. एखाद्या तिकीटवर क्लिक केल्यावर प्रीव्ह्यू दिसण्यापूर्वी लक्षणीय विलंब होत होता.

मला वाटले की समस्या सर्व्हरमध्ये आहे. मला संशय होता की डेटाबेस क्वेरीज संथ आहेत किंवा VPS कमकुवत आहे.

मोजमापांनी मला चुकीचे ठरवले.

मी feature list endpoint तपासले. फक्त ५२ तिकीट असूनही, API ने ४ ms मध्ये प्रतिसाद दिला. हे ऐकायला खूप वेगवान वाटते. पण रिस्पॉन्सचा आकार (size) ३५४ KB होता.

SvelteKit route payload मध्ये देखील तीच समस्या दिसून आली. एका साध्या लिस्टसाठी डेटाचा आकार खूप मोठा होता.

समस्या वेगाची नव्हती. समस्या डेटाच्या वजनाची (weight) होती.

केवळ वर्णनांमुळे (descriptions) एकूण रिस्पॉन्सचा ८०% भाग व्यापला होता. लिस्ट endpoint प्रत्येक आयटमसाठी पूर्ण Markdown वर्णने परत करत होते.

हा एक सामान्य सापळा आहे. लिस्ट endpoint आता detail endpoint बनले होते. जेव्हा जेव्हा एखाद्या पेजला लिस्टची गरज असायची, तेव्हा त्याला न वापरल्या जाणाऱ्या डेटाची किंमत मोजावी लागत होती.

UI चा वापर पेलोड (payload) ठरवत नाही. Loader चा return shape तो ठरवतो.

जर तुमचा loader पूर्ण ऑब्जेक्ट परत करत असेल, तर SvelteKit त्या संपूर्ण ऑब्जेक्टला route data मध्ये सिरीयलाईझ (serialize) करते. तुम्ही एखादे फील्ड कधीही रेंडर केले नसले तरी, ते नेटवर्कवरून प्रवास करतेच.

मी समरी डेटा (summary data) आणि डिटेल डेटा (detail data) वेगळा करून ही समस्या सोडवली.

मी दोन वेगळे कॉन्ट्रॅक्ट्स (contracts) तयार केले:

• सारांशासाठी (summaries) एक लिस्ट कॉन्ट्रॅक्ट (ID, title, status, dates). • पूर्ण माहितीसाठी (descriptions, commands) एक डिटेल कॉन्ट्रॅक्ट.

मी API चे दोन endpoints मध्ये विभाजन केले:

  • GET /features (summaries परत करते)
  • GET /features/:id (एक पूर्ण डिटेल परत करते)

मी फ्रंटएंड कसे काम करते यामध्येही बदल केला. आता, ॲप समरी डेटा वापरून लिस्ट लगेच रेंडर करते. जेव्हा तुम्ही एखाद्या तिकीटवर क्लिक करता, तेव्हा ॲप एक 'शेल' (shell) दाखवते आणि बॅकग्राउंडमध्ये जड डिटेल डेटा फेच (fetch) करते.

याचे परिणाम प्रचंड होते:

• Feature list API: ८९.६% घट • Tickets route data: ९१.४% घट • OpenSpec docs API: ९८.९% घट

डेटाबेस नेहमीच वेगवान होता. खरा अडथळा (bottleneck) API आणि पेजमधील डेटा कॉन्ट्रॅक्टमध्ये होता.

लिस्ट-हेवी (list-heavy) ॲप्ससाठी धडे:

  • केवळ प्रतिसादाचा वेळ (response time) न मोजता, प्रतिसादाचा आकार (response size) देखील मोजा.
  • लिस्ट (list) आणि डिटेल (detail) पेलोड्सना (payloads) वेगवेगळ्या गोष्टी म्हणून हाताळा.
  • लिस्ट व्ह्यूमध्ये (list view) कधीही मोठे टेक्स्ट फील्ड्स (text fields) परत करू नका.
  • तुमचा SSR लोडर (loader) प्रत्यक्षात काय सिरीयलाईझ (serializing) करत आहे ते तपासा.
  • डिटेल डेटा 'लेझी-लोड' (lazy-load) करा पण UI शेल (UI shell) त्वरित दाखवा.
  • हेवी पेलोड (heavy payload) लपवण्यासाठी लोडिंग स्पिनरचा (loading spinner) वापर करू नका.

जलद क्वेरी (fast query) म्हणजे पेज देखील जलद असेलच याची खात्री नसते.

स्रोत: https://dev.to/ahikmah/my-api-responded-in-4-ms-but-navigation-still-felt-slow-1hk8