Chrome 151 ની Soft Navigations API આખરે single-page apps (SPAs) ને દરેક in-app navigation માટે Core Web Vitals રિપોર્ટ કરવાની સુવિધા આપે છે, પરંતુ Google નો CrUX dataset હજુ પણ માત્ર પ્રથમ hard load જ રેકોર્ડ કરે છે, જેના કારણે ડેવલપર્સ પાસે પરફોર્મન્સના બે અલગ-અલગ ચિત્રો રહે છે.
શા માટે SPA metrics પાછળ રહી ગયા છે
Core Web Vitals—Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) અને Cumulative Layout Shift (CLS)—hard navigations ના આધારે વ્યાખ્યાયિત કરવામાં આવ્યા હતા. Hard navigation એક નવું ડોક્યુમેન્ટ ફેચ કરે છે અને અગાઉના પેજની સ્ટેટ (state) ને ડિસ્કાર્ડ કરે છે.
React, Vue, Next.js અથવા સમાન frameworks સાથે બનેલા SPAs માં ભાગ્યે જ hard navigations ટ્રિગર થાય છે. લિંક પર ક્લિક કરવાથી History API દ્વારા URL અપડેટ થાય છે, બેકગ્રાઉન્ડમાં ડેટા ફેચ થાય છે, અને ફૂલ રીલોડ વગર કન્ટેન્ટ બદલાઈ જાય છે. હાલની Performance API માત્ર પ્રારંભિક પેજ લોડ જ કેપ્ચર કરે છે, તેથી જ્યારે યુઝર્સ એક રૂટથી બીજા રૂટ પર જાય છે ત્યારે તેઓ જે લેટન્સી (latency) અનુભવે છે તેને LCP અને INP ક્યારેય જોઈ શકતા નથી.
આ અંધપોઈન્ટ (blind spot) Performance Timeline અથવા Google ના Chrome User Experience Report (CrUX) માંથી ડેટા લેતા ડેશબોર્ડ્સને ખોટી દિશામાં લઈ જાય છે. તેઓ ઘણીવાર "shell" પેજ માટે ઉત્તમ LCP બતાવે છે પરંતુ એપમાં ઊંડે સુધી થતા ધીમા લોડ્સને અવગણે છે, જેનાથી પરફોર્મન્સ હેલ્થનો ખોટો અહેસાસ થાય છે.
Chrome ની Soft Navigations API
Chrome 151 એ Soft Navigations API રજૂ કરી છે, જે હ્યુરિસ્ટિક્સ (heuristics) નો એક સેટ છે જે અમુક SPA ઇન્ટરેક્શનને સાચા નેવિગેશન તરીકે ગણે છે. આ API ત્રણ સિગ્નલો પર નજર રાખે છે:
- યુઝર દ્વારા શરૂ કરાયેલ ઇન્ટરેક્શન (click, tap, keyboard event)
- History API દ્વારા URL માં ફેરફાર
- ત્યારબાદના paint events જે નવું કન્ટેન્ટ રેન્ડર કરે છે
જ્યારે આ ત્રણેય બાબતો સુસંગત હોય, ત્યારે Chrome Performance Timeline માં soft navigation લોગ કરે છે, અને તે ટ્રાન્ઝિશન માટે Core Web Vitals ની ગણતરી બરાબર hard navigation ની જેમ જ કરવામાં આવે છે. ઓપન-સોર્સ web-vitals લાઇબ્રેરીએ 21 જુલાઈના રોજ સપોર્ટ ઉમેર્યો છે, જેથી ડેવલપર્સ પહેલેથી જ ઉપયોગમાં લેતા API સાથે આ આંકડા મેળવવાનું શરૂ કરી શકે છે.
વ્યવહારમાં, હવે તમે દરેક રૂટ ચેન્જ માટે LCP વેલ્યુ, છેલ્લી યુઝર ઇનપુટની સાચી લેટન્સી દર્શાવતું INP, અને soft navigation પછી લેઆઉટ શિફ્ટને કેપ્ચર કરતું CLS જોઈ શકો છો.
ડેટા સ્પ્લિટ: Chrome વિરુદ્ધ CrUX
Google નો CrUX (Chrome User Experience Report) PageSpeed Insights, Search Console અને પરોક્ષ રીતે, રેન્કિંગ સિગ્નલ્સને પાવર આપે છે. CrUX હજુ પણ માત્ર hard-navigation ડેટા જ એગ્રીગેટ કરે છે.
પરિણામે, તમારી પાસે બે સુસંગત પરંતુ અલગ ડેટા સ્ટ્રીમ્સ હોય છે:
- Internal tools જે Performance Timeline વાંચે છે તે હવે રૂટ-લેવલ LCP, INP અને CLS બતાવે છે, જે SPA માં યુઝર્સ શું અનુભવે છે તેનો વાસ્તવિક દૃષ્ટિકોણ આપે છે.
- Google ના પબ્લિક datasets માત્ર પ્રથમ પેજ લોડ માટે જ મેટ્રિક્સ બતાવવાનું ચાલુ રાખે છે, જે Search Console રિપોર્ટ કરે છે અને Google ના રેન્કિંગ અલ્ગોરિધમ્સ સંદર્ભ લે છે.
બંને સાચા છે; તેઓ ફક્ત અલગ-અલગ ક્ષણો માપે છે. માત્ર Search Console પર આધાર રાખવાથી પ્રારંભિક લોડ પછી થતા પરફોર્મન્સ રિગ્રેશન (regressions) છુપાઈ શકે છે, જ્યારે માત્ર ઇન્ટરનલ ડેશબોર્ડ્સ એ બેઝલાઇનને પ્રતિબિંબિત કરશે નહીં જે Google SEO માટે ઉપયોગ કરે છે.
ડેવલપર્સએ શેના પર ધ્યાન આપવાની જરૂર છે
- Browser support – Soft Navigations API આજે માત્ર Chromium-આધારિત બ્રાઉઝર્સમાં જ ઉપલબ્ધ છે. Safari અને Firefox માં તેના જેવું કંઈ નથી, તેથી તમારે તમારા પ્રેક્ષકોના અમુક ભાગ માટે ફોલબેક લોજિક (fallback logic) રાખવું પડશે.
- Heuristic limits – API સંકેતોના સેટના આધારે soft navigation નક્કી કરે છે. જો તમારી એપ URL બદલ્યા વિના કન્ટેન્ટ અપડેટ કરે છે (દા.ત., modal overlays અથવા infinite scroll), તો API તે ટ્રાન્ઝિશન ચૂકી શકે છે, જેનાથી ડેટામાં ગેપ્સ રહી શકે છે.
- Testing before trusting – ડિટેક્શન હ્યુરિસ્ટિક હોવાને કારણે, તમારી એપ પર વાસ્તવિક-દુનિયાના ઇન્ટરેક્શનનો સેટ રન કરો અને રિપોર્ટ કરેલા મેટ્રિક્સની સરખામણી મેન્યુઅલ ટાઇમિંગ સાથે કરો (દા.ત.,
performance.markનો ઉપયોગ કરીને). ચોકસાઈની ખાતરી કર્યા પછી જ તમારે નવા આંકડાઓના આધારે ઓપ્ટિમાઇઝેશનના નિર્ણયો લેવા જોઈએ.
નિષ્કર્ષ
Chrome 151 SPA ડેવલપર્સને દરેક in-app રૂટ ચેન્જ માટે LCP, INP અને CLS માપવાની લાંબા સમયથી રાહ જોવાતી ક્ષમતા આપે છે, પરંતુ Google નો રેન્કિંગ ડેટા હજુ પણ માત્ર પ્રથમ hard load જ પ્રતિબિંબિત કરે છે. જ્યાં સુધી CrUX તેની સાથે મેળ ન ખાય ત્યાં સુધી, ટીમોએ બે સમાંતર ડેટા સેટ્સ સાથે કામ કરવું પડશે: એક જે યુઝરની સાચી વાર્તા કહે છે, અને બીજું જે સર્ચ રેન્કિંગને ચલાવે છે. બંને વચ્ચે સંતુલન જાળવવું—અને વ્યાપક બ્રાઉઝર સપોર્ટ માટે તૈયાર રહેવું—સ્પર્ધાત્મક વેબ ઇકોસિસ્ટમમાં પરફોર્મન્સ-ફર્સ્ટ SPAs જાળવી રાખવા માટે મહત્વપૂર્ણ રહેશે.
