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

నేను SvelteKit మరియు Rust API తో నిర్మించిన ఒక ప్రాజెక్ట్ మేనేజ్‌మెంట్ యాప్‌ను డీబగ్ చేస్తున్నాను.

నా లోకల్ మెషీన్‌లో, అంతా తక్షణమే జరుగుతున్నట్లు అనిపించింది. కానీ VPSలో, నావిగేషన్ భారంగా అనిపించింది. Tickets లేదా Timeline వంటి పేజీలను ఓపెన్ చేయడానికి చాలా సమయం పడుతోంది. ఒక టికెట్‌ను క్లిక్ చేసినప్పుడు, ప్రివ్యూ కనిపించకముందే స్పష్టమైన ఆలస్యం జరిగింది.

సమస్య సర్వర్‌లో ఉందని నేను అనుకున్నాను. స్లో డేటాబేస్ క్వెరీస్ లేదా బలహీనమైన VPS వల్ల ఇలా జరుగుతుందని నేను అనుమానించాను.

కొలతలు (measurements) నేను అనుకున్నది తప్పని నిరూపించాయి.

నేను feature list endpointను తనిఖీ చేశాను. కేవలం 52 టికెట్ల కోసం, API 4 ms లో స్పందించింది. అది వేగంగా అనిపిస్తుంది. కానీ రెస్పాన్స్ సైజు 354 KB ఉంది.

SvelteKit route payload కూడా ఇదే సమస్యను చూపించింది. ఒక సాధారణ లిస్ట్ కోసం డేటా సైజు చాలా ఎక్కువగా ఉంది.

సమస్య వేగం కాదు. సమస్య బరువు (weight).

మొత్తం రెస్పాన్స్‌లో కేవలం డిస్క్రిప్షన్లే 80% ఉన్నాయి. లిస్ట్ endpoint ప్రతి ఐటెమ్‌కు పూర్తి Markdown డిస్క్రిప్షన్లను తిరిగి పంపుతోంది.

ఇది ఒక సాధారణ ఉచ్చు (trap). లిస్ట్ endpoint ఒక detail endpoint గా మారిపోయింది. ప్రతిసారీ ఒక పేజీకి లిస్ట్ అవసరమైనప్పుడు, దానికి అవసరం లేని డేటా కోసం కూడా సమయం/వనరులు ఖర్చవుతున్నాయి.

UI వినియోగం payloadను నిర్ణయించదు. Loader return shape మాత్రమే నిర్ణయిస్తుంది.

మీ loader ఒక పూర్తి ఆబ్జెక్ట్‌ను రిటర్న్ చేస్తే, SvelteKit ఆ మొత్తం ఆబ్జెక్ట్‌ను route dataగా సీరియలైజ్ చేస్తుంది. మీరు ఒక ఫీల్డ్‌ను రెండర్ చేయకపోయినా, అది నెట్‌వర్క్ ద్వారా ప్రయాణిస్తూనే ఉంటుంది.

సమ్మరీ డేటాను (summary data) మరియు డీటెయిల్ డేటాను (detail data) వేరు చేయడం ద్వారా నేను దీనిని పరిష్కరించాను.

నేను రెండు వేర్వేరు కాంట్రాక్ట్‌లను సృష్టించాను:

• సమ్మరీల కోసం ఒక లిస్ట్ కాంట్రాక్ట్ (ID, title, status, dates). • పూర్తి సమాచారం కోసం ఒక డీటెయిల్ కాంట్రాక్ట్ (descriptions, commands).

నేను APIని రెండు endpointsగా విభజించాను:

  • GET /features (సమ్మరీలను రిటర్న్ చేస్తుంది)
  • GET /features/:id (ఒక పూర్తి డీటెయిల్ రిటర్న్ చేస్తుంది)

నేను ఫ్రంటెండ్ పనితీరును కూడా మార్చాను. ఇప్పుడు, యాప్ సమ్మరీ డేటాను ఉపయోగించి లిస్ట్‌ను వెంటనే రెండర్ చేస్తుంది. మీరు ఒక టికెట్‌ను క్లిక్ చేసినప్పుడు, యాప్ ఒక షెల్ (shell) ను చూపిస్తుంది మరియు బ్యాక్‌గ్రౌండ్‌లో భారీ డీటెయిల్ డేటాను ఫెచ్ చేస్తుంది.

ఫలితాలు అద్భుతంగా ఉన్నాయి:

• Feature list API: 89.6% తగ్గింపు • Tickets route data: 91.4% తగ్గింపు • OpenSpec docs API: 98.9% తగ్గింపు

డేటాబేస్ ఎప్పుడూ వేగంగానే ఉంది. అసలైన అడ్డంకి (bottleneck) API మరియు పేజీ మధ్య ఉన్న డేటా కాంట్రాక్ట్.

లిస్ట్-హెవీ యాప్‌ల కోసం పాఠాలు:

  • కేవలం రెస్పాన్స్ సమయాన్ని మాత్రమే కాకుండా, రెస్పాన్స్ పరిమాణాన్ని కూడా కొలవండి.
  • లిస్ట్ మరియు డీటెయిల్ పేలోడ్‌లను వేర్వేరు అంశాలుగా పరిగణించండి.
  • లిస్ట్ వ్యూలో ఎప్పుడూ పెద్ద టెక్స్ట్ ఫీల్డ్‌లను పంపకండి.
  • మీ SSR లోడర్ నిజంగా దేనిని సీరియలైజ్ చేస్తోందో తనిఖీ చేయండి.
  • డీటెయిల్ డేటాను లేజీ-లోడ్ చేయండి, కానీ UI షెల్‌ను వెంటనే చూపించండి.
  • భారీ పేలోడ్‌ను దాచడానికి లోడింగ్ స్పిన్నర్‌ను ఉపయోగించకండి.

వేగవంతమైన క్వెరీ అంటే పేజీ కూడా వేగంగా ఉంటుందని గ్యారెంటీ లేదు.

మూలం: https://dev.to/ahikmah/my-api-responded-in-4-ms-but-navigation-still-felt-slow-1hk8