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

ನಾನು SvelteKit ಮತ್ತು Rust API ಬಳಸಿ ನಿರ್ಮಿಸಲಾದ ಒಂದು ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಆ್ಯಪ್ ಅನ್ನು ಡಿಬಗ್ ಮಾಡುತ್ತಿದ್ದೆ.

ನನ್ನ ಲೋಕಲ್ ಮೆಷಿನ್‌ನಲ್ಲಿ ಎಲ್ಲವೂ ತಕ್ಷಣವೇ ನಡೆಯುವಂತಿದ್ದವು. ಆದರೆ VPS ನಲ್ಲಿ, ನ್ಯಾವಿಗೇಷನ್ ಭಾರವಾಗಿ ಅನಿಸಿತು. Tickets ಅಥವಾ Timeline ನಂತಹ ಪುಟಗಳನ್ನು ತೆರೆಯಲು ತುಂಬಾ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತಿತ್ತು. ಒಂದು ಟಿಕೆಟ್ ಮೇಲೆ ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ, ಪ್ರಿವ್ಯೂ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಮೊದಲು ಗಮನಾರ್ಹ ವಿಳಂಬವಾಗುತ್ತಿತ್ತು.

ಸಮಸ್ಯೆ ಸರ್ವರ್‌ನಲ್ಲಿದೆ ಎಂದು ನಾನು ಭಾವಿಸಿದೆ. ನಿಧಾನಗತಿಯ ಡೇಟಾಬೇಸ್ ಕ್ವೇರಿಗಳು ಅಥವಾ ದುರ್ಬಲ VPS ಕಾರಣವಿರಬಹುದು ಎಂದು ನಾನು ಶಂಕಿಸಿದೆ.

ಅಳತೆಗಳು (measurements) ನನ್ನ ತಪ್ಪು ಎಂದು ಸಾಬೀತುಪಡಿಸಿದವು.

ನಾನು feature list endpoint ಅನ್ನು ಪರಿಶೀಲಿಸಿದೆ. ಕೇವಲ 52 ಟಿಕೆಟ್‌ಗಳಿಗಾಗಿ, API 4 ms ನಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯಿಸಿತು. ಇದು ವೇಗವಾಗಿ ಕೇಳಿಸುತ್ತದೆ. ಆದರೆ ರೆಸ್ಪಾನ್ಸ್ ಗಾತ್ರ (response size) 354 KB ಇತ್ತು.

SvelteKit route payload ಕೂಡ ಇದೇ ಸಮಸ್ಯೆಯನ್ನು ತೋರಿಸಿತು. ಒಂದು ಸರಳ ಪಟ್ಟಿಗೆ (list) ಡೇಟಾ ಗಾತ್ರವು ತುಂಬಾ ದೊಡ್ಡದಾಗಿತ್ತು.

ಸಮಸ್ಯೆ ವೇಗವಾಗಿರಲಿಲ್ಲ. ಸಮಸ್ಯೆ ತೂಕದಲ್ಲಿತ್ತು (weight).

ಕೇವಲ ವಿವರಣೆಗಳು (descriptions) ಒಟ್ಟು ರೆಸ್ಪಾನ್ಸ್‌ನ 80% ಭಾಗವನ್ನು 차지 ಮಾಡುತ್ತಿದ್ದವು. ಲಿಸ್ಟ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಪ್ರತಿಯೊಂದು ಐಟಂಿಗಾಗಿ ಪೂರ್ಣ Markdown ವಿವರಣೆಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತಿತ್ತು.

ಇದು ಒಂದು ಸಾಮಾನ್ಯ ಬಲೆ. ಲಿಸ್ಟ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಒಂದು ಡೀಟೇಲ್ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಆಗಿ ಬದಲಾಗಿತ್ತು. ಪ್ರತಿ ಬಾರಿ ಒಂದು ಪುಟಕ್ಕೆ ಪಟ್ಟಿಯ ಅಗತ್ಯವಿದ್ದಾಗಲೂ, ಅದು ಬಳಸದ ಡೇಟಾಕ್ಕಾಗಿ ಬೆಲೆ ತೆರುತ್ತಿತ್ತು.

UI ಬಳಕೆ ಪೇಲೋಡ್ ಅನ್ನು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. ಲೋಡರ್ ರಿಟರ್ನ್ ಶೇಪ್ (loader return shape) ಅದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.

ನಿಮ್ಮ ಲೋಡರ್ ಪೂರ್ಣ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಿದರೆ, SvelteKit ಆ ಇಡೀ ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ರೂಟ್ ಡೇಟಾ ಆಗಿ ಸೀರಿಯಲೈಸ್ ಮಾಡುತ್ತದೆ. ನೀವು ಯಾವುದೇ ಫೀಲ್ಡ್ ಅನ್ನು ರೆಂಡರ್ ಮಾಡದಿದ್ದರೂ ಸಹ, ಅದು ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಪ್ರಯಾಣಿಸುತ್ತದೆ.

ಸಮ್ಮರಿ ಡೇಟಾವನ್ನು (summary data) ಡೀಟೇಲ್ ಡೇಟಾದಿಂದ (detail data) ಪ್ರತ್ಯೇಕಿಸುವ ಮೂಲಕ ನಾನು ಇದನ್ನು ಸರಿಪಡಿಸಿದೆ.

ನಾನು ಎರಡು ವಿಭಿನ್ನ ಕಾಂಟ್ರಾಕ್ಟ್‌ಗಳನ್ನು ರಚಿಸಿದೆ:

• ಸಮ್ಮರಿಗಳಿಗಾಗಿ ಒಂದು ಲಿಸ್ಟ್ ಕಾಂಟ್ರಾಕ್ಟ್ (ID, title, status, dates). • ಪೂರ್ಣ ಮಾಹಿತಿಗಾಗಿ ಒಂದು ಡೀಟೇಲ್ ಕಾಂಟ್ರಾಕ್ಟ್ (descriptions, commands).

ನಾನು API ಅನ್ನು ಎರಡು ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳಾಗಿ ವಿಂಗಡಿಸಿದೆ:

  • GET /features (ಸಮ್ಮರಿಗಳನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ)
  • GET /features/:id (ಒಂದು ಪೂರ್ಣ ವಿವರವನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ)

ನಾನು ಫ್ರಂಟ್‌ಎಂಡ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನೂ ಬದಲಾಯಿಸಿದೆ. ಈಗ, ಆ್ಯಪ್ ಸಮ್ಮರಿ ಡೇಟಾವನ್ನು ಬಳಸಿ ಪಟ್ಟಿಯನ್ನು ತಕ್ಷಣವೇ ರೆಂಡರ್ ಮಾಡುತ್ತದೆ. ನೀವು ಒಂದು ಟಿಕೆಟ್ ಮೇಲೆ ಕ್ಲಿಕ್ ಮಾಡಿದಾಗ, ಆ್ಯಪ್ ಒಂದು ಶೆಲ್ (shell) ಅನ್ನು ತೋರಿಸುತ್ತದೆ ಮತ್ತು ಹಿನ್ನೆಲೆಯಲ್ಲಿ (background) ಭಾರವಾದ ಡೀಟೇಲ್ ಡೇಟಾವನ್ನು ಪಡೆಯುತ್ತದೆ.

ಫಲಿತಾಂಶಗಳು ಭಾರಿವಾಗಿದ್ದವು:

• Feature list API: 89.6% ಕಡಿತ • Tickets route data: 91.4% ಕಡಿತ • OpenSpec docs API: 98.9% ಕಡಿತ

ಡೇಟಾಬೇಸ್ ಯಾವಾಗಲೂ ವೇಗವಾಗಿತ್ತು. ನಿಜವಾದ ಅಡಚಣೆಯು (bottleneck) API ಮತ್ತು ಪುಟದ ನಡುವಿನ ಡೇಟಾ ಕಾಂಟ್ರಾಕ್ಟ್ ಆಗಿತ್ತು.

ಲಿಸ್ಟ್-ಹೆವಿ ಆ್ಯಪ್‌ಗಳಿಗಾಗಿ ಪಾಠಗಳು:

  • ಕೇವಲ ಪ್ರತಿಕ್ರಿಯೆಯ ಸಮಯವನ್ನು ಮಾತ್ರವಲ್ಲದೆ, ಪ್ರತಿಕ್ರಿಯೆಯ ಗಾತ್ರವನ್ನು ಅಳೆಯಿರಿ.
  • ಲಿಸ್ಟ್ ಮತ್ತು ಡೀಟೇಲ್ ಪೇಲೋಡ್‌ಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಗಣಿಸಿ.
  • ಲಿಸ್ಟ್ ವ್ಯೂನಲ್ಲಿ ಎಂದಿಗೂ ದೊಡ್ಡ ಪಠ್ಯದ ಕ್ಷೇತ್ರಗಳನ್ನು (large text fields) ಹಿಂತಿರುಗಿಸಬೇಡಿ.
  • ನಿಮ್ಮ SSR ಲೋಡರ್ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಸೀರಿಯಲೈಸ್ ಮಾಡುತ್ತಿದೆ ಎಂಬುದನ್ನು ಪರಿಶೀಲಿಸಿ.
  • ವಿವರಣಾತ್ಮಕ ಡೇಟಾವನ್ನು ಲೇಜಿ-ಲೋಡ್ ಮಾಡಿ, ಆದರೆ UI ಶೆಲ್ ಅನ್ನು ತಕ್ಷಣವೇ ತೋರಿಸಿ.
  • ಭಾರೀ ಪೇಲೋಡ್ ಅನ್ನು ಮರೆಮಾಚಲು ಲೋಡಿಂಗ್ ಸ್ಪಿನ್ನರ್ ಅನ್ನು ಬಳಸಬೇಡಿ.

ವೇಗದ ಕ್ವೇರಿಯು ವೇಗದ ಪೇಜ್ ಅನ್ನು ಖಾತರಿಪಡಿಸುವುದಿಲ್ಲ.

ಮೂಲ: https://dev.to/ahikmah/my-api-responded-in-4-ms-but-navigation-still-felt-slow-1hk8