బ్రౌజర్‌లకు 5.5 MB Python runtimeను పంపిణీ చేస్తున్న ఒక బృందం, ఇటీవల జరిగిన ఒక sprint సమయంలో నమోదైన లోపాలలో 69% ఒకే తప్పుదారి పట్టించే శీర్షిక కింద ఉన్నాయని, వాటిలో 89% వాస్తవానికి network timeouts అని కనుగొంది. ఈ తప్పు రిపోర్టింగ్ వల్ల డెవలపర్లు తప్పుడు డీబగ్గింగ్ మార్గంలో వెళ్లారు మరియు గణనీయమైన సంఖ్యలో వినియోగదారులు సైలెంట్ డౌన్‌లోడ్ ఫెయిల్యూర్స్ (silent download failures) ఎదుర్కొన్నారు—పెద్ద మొత్తంలో అసెట్స్‌ను కలిగి ఉండే ఏ వెబ్-యాప్ అయినా త్వరలో ఇలాంటి సమస్యను ఎదుర్కోవచ్చు.

డ్యాష్‌బోర్డ్ తప్పుదారి పట్టించింది

ఎర్రర్-ట్రాకింగ్ సిస్టమ్, లోపాలు మొదట కనిపించిన కోడ్ లొకేషన్ ఆధారంగా వాటిని ఆటోమేటిక్‌గా గ్రూప్ చేస్తుంది. దాని వల్ల వచ్చిన శీర్షిక runtime loaderలో ఒక సాధారణ బగ్ లాగా కనిపించింది, దీనివల్ల sprint అంతా టైమ్ అవుట్ అవ్వని కోడ్ పాత్‌ల కోసం వెతకడానికే సమయం వృథా అయింది. బృందం అసలు మెటాడేటాను పరిశీలించినప్పుడు, అసలు విషయం బయటపడింది: చాలా వైఫల్యాలు బగ్స్ ఏవీ కావు, అవి నెట్‌వర్క్ కనెక్షన్లు నిలిచిపోవడం వల్ల కలిగిన timeoutలు మాత్రమే.

ముఖ్య గమనిక: ఎర్రర్ టైటిల్ అనేది కేవలం సౌకర్యం కోసం మాత్రమే, అది రోగ నిర్ధారణ (diagnosis) కాదు. హెడ్‌లైన్ నిజంగా దేనిని సూచిస్తుందో నిర్ధారించుకోవడానికి క్రమ తప్పకుండా రా డేటా (raw data)ను లోతుగా పరిశీలించండి.

బ్రౌజర్ కనెక్షన్ API ఒక ప్లేస్‌హోల్డర్‌ను ఇచ్చింది

నెమ్మదిగా ఉన్న వినియోగదారులకు 5.5 MB డౌన్‌లోడ్ వల్ల ఇబ్బంది కలగకుండా ఉండటానికి, డెవలపర్లు బ్రౌజర్ యొక్క Network Information API (navigator.connection)ని ఉపయోగించారు. అయితే, ఆ API ప్రతి కొత్త విజిటర్‌కు స్థిరంగా 1.7 Mbps బ్యాండ్‌విడ్త్‌ను చూపిస్తోంది.

కొత్త వినియోగదారునికి సంబంధించిన పాత డేటా (historical data) లేనప్పుడు బ్రౌజర్‌లు ఒక డిఫాల్ట్ విలువను ఇస్తాయి. ఆ డిఫాల్ట్ విలువ కేవలం ఒక సూచన మాత్రమే, అది ఖచ్చితమైన వేగం కాదు. ప్రతి కొత్త సెషన్‌కు అదే ప్లేస్‌హోల్డర్ కనిపిస్తుందంటే, ఆ API ఇంకా ఆ వినియోగదారుల కోసం సరిగ్గా కాలిబ్రేట్ కాలేదని అర్థం.

ముఖ్య గమనిక: ఎప్పుడూ మారకుండా ఉండే నెట్‌వర్క్ సిగ్నల్‌ను ఒక ఫాల్‌బ్యాక్ (fallback)గా మాత్రమే పరిగణించండి, దానిని ఖచ్చితమైన కొలమానం (definitive metric)గా భావించకండి.

వన్-ఆఫ్ స్నాప్‌షాట్‌లు నమ్మదగినవి కావు

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

ముఖ్య గమనిక: నిరంతరం మారుతున్న అంశంపై కేవలం ఒకే ఒక్క రీడింగ్ ఆధారంగా శాశ్వత నిర్ణయాలు తీసుకోవద్దు. ఒకేసారి పోలింగ్ (polling) చేసే బదులు, మార్పుల కోసం (change events) సబ్‌స్క్రైబ్ అవ్వండి.

బృందం అమలు చేసిన ఆచరణాత్మక పరిష్కారాలు

  • కనెక్షన్ మార్పులకు సబ్‌స్క్రైబ్ అవ్వడం. navigator.connectionను ఒకేసారి చదివే బదులు, కోడ్ ఇప్పుడు change ఈవెంట్‌ను గమనిస్తుంది మరియు డౌన్‌లోడ్ సమయంలో బ్యాండ్‌విడ్త్ తగ్గినా లేదా పెరిగినా దానికి అనుగుణంగా స్పందిస్తుంది.
  • “నో-ప్రోగ్రెస్” వాచ్‌డాగ్‌ను జోడించడం. ఒక నిర్ణీత సమయం తర్వాత కూడా ఎటువంటి పురోగతి లేని రిక్వెస్ట్‌లను ఒక టైమర్ అబార్ట్ చేస్తుంది, తద్వారా బ్రౌజర్ మళ్ళీ ప్రయత్నించడానికి లేదా ఫాల్‌బ్యాక్ చేయడానికి వీలవుతుంది.
  • డౌన్‌లోడ్ మధ్యలో CDNలను మార్చడం ఆపివేయడం. నెమ్మదిగా ఉన్న లింక్‌లో పెద్ద ఫైల్ యొక్క మూలాన్ని (source) మార్చడం వల్ల ట్రాన్స్‌ఫర్ మళ్ళీ సున్నా నుండి ప్రారంభమవుతుంది, దీనివల్ల ఇప్పటికే వచ్చిన బైట్లు వృథా అవుతాయి. ఇప్పుడు డౌన్‌లోడ్ మొత్తం సమయం పాటు మొదట ఎంచుకున్న CDN కే కట్టుబడి ఉంటుంది.
  • భారీ క్యాషింగ్ పనులను వాయిదా వేయడం. క్యాష్‌లోకి పెద్ద మొత్తంలో డేటాను రాసే పనులను runtime లోడింగ్ పూర్తయ్యే వరకు వాయిదా వేస్తారు, దీనివల్ల క్రిటికల్ పాత్ (critical path) తక్కువగా ఉంటుంది.

మీ డ్యాష్‌బోర్డ్‌లు అసాధారణంగా చక్కని చిత్రాన్ని చూపిస్తుంటే, మరింత లోతుగా పరిశోధించండి. నెట్‌వర్క్ కొలత ఎప్పుడూ మారకపోతే, దానిని ఒక ప్లేస్‌హోల్డర్‌గా పరిగణించండి. ఒకే ఒక స్నాప్‌షాట్ మల్టీ-మెగాబైట్ డౌన్‌లోడ్ యొక్క గమ్యాన్ని నిర్ణయిస్తుంటే, మీరు ఒక భ్రమపై ఆధారపడుతున్నారని అర్థం. అటువంటి నిర్ణయాలు వినియోగదారుల నమ్మకాన్ని దెబ్బతీసే సైలెంట్ ఫెయిల్యూర్స్‌గా మారుతాయి—దీనిని తర్వాత ఎంత తెలివైన కోడ్‌తోనైనా పూర్తిగా సరిదిద్దలేము.