ઘડિયાળથી આગળ: વેબ પરફોર્મન્સ API ને વાસ્તવિક વપરાશકર્તા અનુભવ સાથે જોડવું

ડિજિટલ અર્થતંત્રમાં, ઝડપ માત્ર એક વિશેષતા નથી; તે વપરાશકર્તા અનુભવનો પાયો છે. ધીમી વેબસાઇટ વપરાશકર્તાઓને નિરાશ કરી શકે છે, બાઉન્સ રેટ વધારે છે અને આવક પર સીધી અસર કરે છે. વર્ષોથી, વિકાસકર્તાઓએ પ્રદર્શનને માપવા માટે window.onload જેવા સમયના મેટ્રિક્સ પર આધાર રાખ્યો છે. પરંતુ શું ઝડપી લોડ થવાનો સમય ખરેખર ખુશ વપરાશકર્તા સમાન છે? જવાબ મોટાભાગે ના છે.

એક પૃષ્ઠ એક સેકન્ડથી ઓછા સમયમાં તેના બધા તકનીકી સંસાધનો લોડ કરવાનું સમાપ્ત કરી શકે છે, તેમ છતાં વાસ્તવિક વ્યક્તિ સાથે વાતચીત કરવાનો પ્રયાસ કરતી વખતે તે ધીમું અને બિનઉપયોગી લાગે છે. આ ડિસ્કનેક્ટ વેબ ડેવલપમેન્ટમાં એક મહત્વપૂર્ણ ઉત્ક્રાંતિને પ્રકાશિત કરે છે: તકનીકી સમયને માપવાથી માનવ અનુભવને માપવા તરફનો ફેરફાર. આધુનિક વેબ પ્રદર્શન એ બે દ્રષ્ટિકોણની વાર્તા છે: વેબ પરફોર્મન્સ API દ્વારા પૂરા પાડવામાં આવેલ દાણાદાર, નીચા-સ્તરનો ડેટા અને Googleના કોર વેબ વાઇટલ્સ જેવા ઉચ્ચ-સ્તરના, વપરાશકર્તા-કેન્દ્રિત મેટ્રિક્સ.

આ વ્યાપક માર્ગદર્શિકા તે અંતરને દૂર કરશે. અમે વેબ પરફોર્મન્સ API ના શક્તિશાળી સ્યુટનું અન્વેષણ કરીશું જે અમારા ડાયગ્નોસ્ટિક ટૂલ્સ તરીકે કાર્ય કરે છે. પછી, અમે આધુનિક વપરાશકર્તા અનુભવ મેટ્રિક્સમાં તપાસ કરીશું જે આપણને કહે છે કે પ્રદર્શન કેવું લાગે છે. સૌથી અગત્યનું, અમે ટપકાં જોડીશું, તમને બતાવીશું કે તમારા વૈશ્વિક પ્રેક્ષકો માટે નબળા વપરાશકર્તા અનુભવના મૂળ કારણોનું નિદાન અને સમારકામ કરવા માટે નીચા-સ્તરના સમય ડેટાનો ઉપયોગ કેવી રીતે કરવો.

આધાર: વેબ પરફોર્મન્સ API ને સમજવું

વેબ પરફોર્મન્સ API એ પ્રમાણિત બ્રાઉઝર ઇન્ટરફેસનો સમૂહ છે જે વિકાસકર્તાઓને વેબ પૃષ્ઠના નેવિગેશન અને રેન્ડરિંગથી સંબંધિત અત્યંત વિગતવાર અને સચોટ સમય ડેટાની ઍક્સેસ આપે છે. તે પ્રદર્શન માપનનો આધારસ્તંભ છે, જે આપણને સરળ સ્ટોપવોચથી આગળ વધવા અને નેટવર્ક વિનંતીઓ, પાર્સિંગ અને રેન્ડરિંગના જટિલ નૃત્યને સમજવાની મંજૂરી આપે છે.

નેવિગેશન ટાઇમિંગ API: પૃષ્ઠની સફર

નેવિગેશન ટાઇમિંગ API મુખ્ય દસ્તાવેજને લોડ કરવામાં લાગતા સમયનો વિગતવાર વિરામ પૂરો પાડે છે. તે વપરાશકર્તા નેવિગેશન શરૂ કરે તે ક્ષણથી (જેમ કે લિંક પર ક્લિક કરવું) તે ક્ષણ સુધી કે પૃષ્ઠ સંપૂર્ણપણે લોડ થાય છે તે ક્ષણ સુધીના સીમાચિહ્નોને કેપ્ચર કરે છે. આ પૃષ્ઠ લોડ પ્રક્રિયામાં આપણું પ્રથમ અને સૌથી મૂળભૂત દૃશ્ય છે.

તમે આ ડેટાને સરળ જાવાસ્ક્રિપ્ટ કૉલ વડે ઍક્સેસ કરી શકો છો:

const navigationEntry = performance.getEntriesByType('navigation')[0]; console.log(navigationEntry.toJSON());

આ ટાઈમસ્ટેમ્પ્સથી ભરપૂર ઑબ્જેક્ટ પરત કરે છે. કેટલીક મુખ્ય મિલકતોમાં શામેલ છે:

• fetchStart: જ્યારે બ્રાઉઝર દસ્તાવેજ લાવવાનું શરૂ કરે છે.
• responseStart: જ્યારે બ્રાઉઝર સર્વરમાંથી પ્રતિસાદનો પ્રથમ બાઇટ મેળવે છે. fetchStart અને responseStart વચ્ચેના સમયને ઘણીવાર ટાઇમ ટુ ફર્સ્ટ બાઇટ (TTFB) તરીકે ઓળખવામાં આવે છે.
• domContentLoadedEventEnd: જ્યારે પ્રારંભિક HTML દસ્તાવેજ સંપૂર્ણપણે લોડ અને પાર્સ થઈ ગયો હોય, સ્ટાઈલશીટ્સ, છબીઓ અને સબફ્રેમ્સ લોડ થવાનું સમાપ્ત થવાની રાહ જોયા વિના.
• loadEventEnd: જ્યારે પૃષ્ઠ માટેના તમામ સંસાધનો (છબીઓ, CSS વગેરે સહિત) સંપૂર્ણપણે લોડ થઈ ગયા હોય.

લાંબા સમયથી, loadEventEnd ગોલ્ડ સ્ટાન્ડર્ડ હતું. જોકે, તેની મર્યાદા ગંભીર છે: તે એવું કશું કહેતું નથી કે વપરાશકર્તા ક્યારે અર્થપૂર્ણ સામગ્રી જુએ છે અથવા ક્યારે તેઓ પૃષ્ઠ સાથે ક્રિયાપ્રતિક્રિયા કરી શકે છે. તે માનવ નથી પણ તકનીકી સીમાચિહ્નરૂપ છે.

રિસોર્સ ટાઇમિંગ API: ઘટકોને ડિસ્કન્સ્ટ્રક્ટ કરવું

એક વેબ પૃષ્ઠ ભાગ્યે જ એક જ ફાઇલ હોય છે. તે HTML, CSS, JavaScript, છબીઓ, ફોન્ટ્સ અને API કૉલ્સનું એસેમ્બલી છે. રિસોર્સ ટાઇમિંગ API તમને આ દરેક વ્યક્તિગત સંસાધનો માટે નેટવર્ક ટાઇમિંગનું નિરીક્ષણ કરવાની મંજૂરી આપે છે.

આ બોટલનેક્સને ઓળખવા માટે અતિશય શક્તિશાળી છે. શું કન્ટેન્ટ ડિલિવરી નેટવર્ક (CDN) માંથી એક મોટી, અનઓપ્ટિમાઇઝ હીરો છબી અન્ય ખંડમાં પ્રારંભિક રેન્ડરને ધીમું કરી રહી છે? શું તૃતીય-પક્ષ એનાલિટિક્સ સ્ક્રિપ્ટ મુખ્ય થ્રેડને અવરોધિત કરી રહી છે? રિસોર્સ ટાઇમિંગ તમને આ પ્રશ્નોના જવાબ આપવા માટે મદદ કરે છે.

તમે આ રીતે બધા સંસાધનોની સૂચિ મેળવી શકો છો:

const resourceEntries = performance.getEntriesByType('resource'); resourceEntries.forEach(resource => { if (resource.duration > 200) { // Find resources that took longer than 200ms console.log(`Slow resource: ${resource.name}, Duration: ${resource.duration}ms`); } });

મુખ્ય ગુણધર્મોમાં name (સંસાધનનું URL), initiatorType (જેના કારણે સંસાધન લોડ થયું, દા.ત., 'img', 'script') અને duration (તેને લાવવામાં લીધેલું કુલ સમય) શામેલ છે.

વપરાશકર્તા સમય API: તમારી એપ્લિકેશનની લોજિકને માપવી

કેટલીકવાર, પ્રદર્શનનો અવરોધ અસ્કયામતો લોડ કરવામાં નહીં પરંતુ ક્લાયન્ટ-સાઇડ કોડમાં જ હોય છે. API માંથી ડેટા પ્રાપ્ત થયા પછી તમારા સિંગલ-પેજ એપ્લિકેશન (SPA) ને જટિલ ઘટકને રેન્ડર કરવામાં કેટલો સમય લાગે છે? વપરાશકર્તા ટાઇમિંગ API તમને કસ્ટમ, એપ્લિકેશન-વિશિષ્ટ માપન બનાવવાની મંજૂરી આપે છે.

તે બે મુખ્ય પદ્ધતિઓ સાથે કામ કરે છે:

• performance.mark(name): પ્રદર્શન બફરમાં નામવાળું ટાઈમસ્ટેમ્પ બનાવે છે.
• performance.measure(name, startMark, endMark): બે ગુણ વચ્ચેનો સમયગાળો ગણતરી કરે છે અને નામવાળું માપન બનાવે છે.

ઉદાહરણ: ઉત્પાદન સૂચિ ઘટકનો રેન્ડર સમય માપવો.

// When you start fetching data performance.mark('product-list-fetch-start'); fetch('/api/products') .then(response => response.json()) .then(data => { // After fetching, before rendering performance.mark('product-list-render-start'); renderProductList(data); // Immediately after rendering is complete performance.mark('product-list-render-end'); // Create a measure performance.measure( 'Product List Render Time', 'product-list-render-start', 'product-list-render-end' ); });

આ તમને તમારી એપ્લિકેશનના તે ભાગોને માપવા માટે ચોક્કસ નિયંત્રણ આપે છે જે વપરાશકર્તાના વર્કફ્લો માટે સૌથી વધુ મહત્વપૂર્ણ છે.

PerformanceObserver: આધુનિક, કાર્યક્ષમ અભિગમ

વારંવાર performance.getEntriesByType() ને પોલ કરવું બિનકાર્યક્ષમ છે. `PerformanceObserver` API પ્રદર્શન એન્ટ્રી સાંભળવા માટે વધુ સારી રીત પૂરી પાડે છે. તમે ચોક્કસ એન્ટ્રી પ્રકારોનું સબ્સ્ક્રાઇબ કરો છો અને બ્રાઉઝર તમારી કૉલબેક કાર્યને એસિન્ક્રોનસલી સૂચિત કરે છે કારણ કે તેઓ રેકોર્ડ કરવામાં આવે છે. આ તમારી એપ્લિકેશનમાં ઓવરહેડ ઉમેર્યા વિના પ્રદર્શન ડેટા એકત્રિત કરવાની ભલામણ કરેલ રીત છે.

const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { console.log(`Entry Type: ${entry.entryType}, Name: ${entry.name}`); } }); observer.observe({ entryTypes: ['resource', 'navigation', 'mark', 'measure'] });

આ નિરીક્ષક માત્ર ઉપરના પરંપરાગત મેટ્રિક્સ જ નહીં પરંતુ આધુનિક, વપરાશકર્તા-કેન્દ્રિત મેટ્રિક્સ પણ એકત્રિત કરવાની ચાવી છે જેની ચર્ચા આપણે આગળ કરીશું.

વપરાશકર્તા-કેન્દ્રિયતા તરફનો ફેરફાર: કોર વેબ વાઇટલ્સ

એ જાણવું ઉપયોગી છે કે પૃષ્ઠ 2 સેકન્ડમાં લોડ થયું, પરંતુ તે મહત્વપૂર્ણ પ્રશ્નોના જવાબ આપતું નથી: શું વપરાશકર્તા તે 2 સેકન્ડ માટે ખાલી સ્ક્રીન સામે જોઈ રહ્યો હતો? શું તેઓ પૃષ્ઠ સાથે ક્રિયાપ્રતિક્રિયા કરી શક્યા, અથવા તે સ્થિર થઈ ગયું હતું? શું તેઓ વાંચવાનો પ્રયાસ કરી રહ્યા હતા ત્યારે સામગ્રી અણધારી રીતે આસપાસ કૂદી હતી?

આને સંબોધવા માટે, Google એ કોર વેબ વાઇટલ્સ (CWV) રજૂ કર્યા, જે ત્રણ મુખ્ય પરિમાણોમાં પૃષ્ઠના વાસ્તવિક-વિશ્વ વપરાશકર્તા અનુભવને માપવા માટે રચાયેલ મેટ્રિક્સનો સમૂહ છે: લોડિંગ, ઇન્ટરેક્ટિવિટી, અને વિઝ્યુઅલ સ્થિરતા.

સૌથી મોટું કન્ટેન્ટફુલ પેઇન્ટ (LCP): માનવામાં આવતા લોડિંગને માપવું

LCP વ્યૂપોર્ટમાં દેખાતા સૌથી મોટા ચિત્ર અથવા ટેક્સ્ટ બ્લોકના રેન્ડર સમયને માપે છે. તે ત્યારે ઉત્તમ પ્રોક્સી છે જ્યારે વપરાશકર્તાને લાગે છે કે પૃષ્ઠની મુખ્ય સામગ્રી લોડ થઈ ગઈ છે. તે સીધો વપરાશકર્તાના પ્રશ્નનો જવાબ આપે છે: “શું આ પૃષ્ઠ હજી ઉપયોગી છે?”

• સારું: 2.5 સેકન્ડથી ઓછું
• સુધારાની જરૂર છે: 2.5s અને 4.0s વચ્ચે
• ખરાબ: 4.0 સેકન્ડથી વધુ

`loadEventEnd` થી વિપરીત, LCP એના પર ધ્યાન કેન્દ્રિત કરે છે કે વપરાશકર્તા પ્રથમ શું જુએ છે, જે તેને માનવામાં આવેલ લોડ સ્પીડનું વધુ સચોટ પ્રતિબિંબ બનાવે છે.

ઇન્ટરેક્શન ટુ નેક્સ્ટ પેઇન્ટ (INP): પ્રતિભાવને માપવું

INP એ ફર્સ્ટ ઇનપુટ ડીલે (FID)નું અનુગામી છે અને માર્ચ 2024 માં એક સત્તાવાર કોર વેબ વાઇટલ બન્યું. જ્યારે FID માત્ર *પ્રથમ* ક્રિયાપ્રતિક્રિયામાં વિલંબને માપતી હતી, ત્યારે INP પૃષ્ઠના જીવનચક્ર દરમિયાન *બધી* વપરાશકર્તા ક્રિયાપ્રતિક્રિયાઓની (ક્લિક્સ, ટેપ્સ, કી પ્રેસ) લેટન્સીને માપે છે. તે સૌથી લાંબી ક્રિયાપ્રતિક્રિયાની જાણ કરે છે, જે અસરકારક રીતે ખરાબ-કેસ પ્રતિભાવની ઓળખ કરે છે જેનો વપરાશકર્તા અનુભવ કરે છે.

INP વપરાશકર્તાના ઇનપુટથી લઈને નેક્સ્ટ ફ્રેમને પેઇન્ટ કરવામાં આવે ત્યાં સુધીના સમગ્ર સમયને માપે છે, જે વિઝ્યુઅલ પ્રતિસાદને પ્રતિબિંબિત કરે છે. તે વપરાશકર્તાના પ્રશ્નનો જવાબ આપે છે: “જ્યારે હું આ બટન પર ક્લિક કરું છું, ત્યારે શું પૃષ્ઠ ઝડપથી પ્રતિસાદ આપે છે?”

• સારું: 200 મિલીસેકન્ડથી ઓછું
• સુધારાની જરૂર છે: 200ms અને 500ms ની વચ્ચે
• ખરાબ: 500ms થી વધુ

ઉચ્ચ INP સામાન્ય રીતે એક વ્યસ્ત મુખ્ય થ્રેડને કારણે થાય છે, જ્યાં લાંબા સમય સુધી ચાલતા JavaScript કાર્યો બ્રાઉઝરને વપરાશકર્તા ઇનપુટનો પ્રતિસાદ આપતા અટકાવે છે.

ક્યુમ્યુલેટિવ લેઆઉટ શિફ્ટ (CLS): વિઝ્યુઅલ સ્થિરતાને માપવું

CLS પૃષ્ઠની વિઝ્યુઅલ સ્થિરતાને માપે છે. તે ગણતરી કરે છે કે લોડિંગ પ્રક્રિયા દરમિયાન સ્ક્રીન પર સામગ્રી કેટલી અણધારી રીતે ફરે છે. ઉચ્ચ CLS સ્કોર એ વપરાશકર્તાની નિરાશાનું સામાન્ય કારણ છે, જેમ કે જ્યારે તમે બટન પર ક્લિક કરવાનો પ્રયાસ કરો છો, પરંતુ તેની ઉપર એક જાહેરાત લોડ થાય છે, બટનને નીચે ધકેલે છે અને તમને તેના બદલે જાહેરાત પર ક્લિક કરે છે.

CLS વપરાશકર્તાના પ્રશ્નનો જવાબ આપે છે: “શું હું આ પૃષ્ઠનો ઉપયોગ તત્વોને બધે કૂદકા માર્યા વગર કરી શકું છું?”

• સારું: 0.1 થી ઓછું
• સુધારાની જરૂર છે: 0.1 અને 0.25 ની વચ્ચે
• ખરાબ: 0.25 થી વધુ

ઉચ્ચ CLS ના સામાન્ય કારણોમાં પરિમાણો વિનાની છબીઓ અથવા iframes, મોડેથી લોડ થતા વેબ ફોન્ટ્સ અથવા સામગ્રીને તે માટે જગ્યા અનામત રાખ્યા વિના પૃષ્ઠમાં ગતિશીલ રીતે ઇન્જેક્ટ કરવામાં આવે છે.

અંતરને દૂર કરવું: નબળા વપરાશકર્તા અનુભવનું નિદાન કરવા માટે API નો ઉપયોગ કરવો

આ તે છે જ્યાં બધું એકસાથે આવે છે. કોર વેબ વાઇટલ્સ આપણને કહે છે કે વપરાશકર્તાએ *શું* અનુભવ્યું (દા.ત., ધીમા LCP). વેબ પરફોર્મન્સ API આપણને કહે છે કે તે *કેમ* થયું. તેમને જોડીને, અમે ફક્ત પ્રદર્શનનું અવલોકન કરવાથી તેને સક્રિય રીતે ડાયગ્નોસિંગ અને તેને ઠીક કરવામાં પરિવર્તન પામીએ છીએ.

ધીમા LCP નું નિદાન

કલ્પના કરો કે તમારું રીઅલ યુઝર મોનિટરિંગ (RUM) ટૂલ ચોક્કસ પ્રદેશના વપરાશકર્તાઓ માટે 4.5 સેકન્ડનું નબળું LCP રિપોર્ટ કરે છે. તમે તેને કેવી રીતે ઠીક કરશો? તમારે LCP સમયને તેના ઘટક ભાગોમાં તોડવાની જરૂર છે.

1. ટાઇમ ટુ ફર્સ્ટ બાઇટ (TTFB): શું સર્વર પ્રતિસાદ આપવા માટે ધીમું છે? નેવિગેશન ટાઇમિંગ API નો ઉપયોગ કરો. અવધિ `responseStart - requestStart` તમને ચોક્કસ TTFB આપે છે. જો આ ઊંચું હોય, તો સમસ્યા તમારા બેકએન્ડ, સર્વર ગોઠવણી અથવા ડેટાબેઝમાં છે, ફ્રન્ટએન્ડમાં નહીં.
2. સંસાધન લોડ વિલંબ અને સમય: શું LCP તત્વ પોતે ધીમેથી લોડ થાય છે? સૌપ્રથમ, LCP તત્વને ઓળખો (દા.ત., એક હીરો છબી). તમે તત્વ મેળવવા માટે `largest-contentful-paint` માટે `PerformanceObserver` નો ઉપયોગ કરી શકો છો. પછી, તે તત્વના URL માટેની એન્ટ્રી શોધવા માટે રિસોર્સ ટાઇમિંગ API નો ઉપયોગ કરો. તેના સમયરેખાનું વિશ્લેષણ કરો: શું લાંબુ `connectStart` થી `connectEnd` (ધીમું નેટવર્ક) હતું? શું `responseStart` થી `responseEnd` લાંબુ હતું (એક વિશાળ ફાઇલનું કદ)? શું તેનું `fetchStart` વિલંબિત હતું કારણ કે તે CSS અથવા JavaScript જેવા અન્ય રેન્ડર-બ્લોકીંગ સંસાધનો દ્વારા અવરોધિત હતું?
3. એલિમેન્ટ રેન્ડર વિલંબ: આ સંસાધન લોડ થવાનું સમાપ્ત થયા પછી તે ખરેખર સ્ક્રીન પર પેઇન્ટ થાય ત્યાં સુધીનો સમય છે. આ અન્ય કાર્યો સાથે વ્યસ્ત મુખ્ય થ્રેડને કારણે થઈ શકે છે, જેમ કે મોટા JavaScript બંડલનું અમલ કરવું.

નેવિગેશન અને રિસોર્સ ટાઇમિંગનો ઉપયોગ કરીને, તમે નિર્ધારિત કરી શકો છો કે ધીમા LCP ધીમા સર્વર, રેન્ડર-બ્લોકીંગ સ્ક્રિપ્ટ અથવા વિશાળ, અનઓપ્ટિમાઇઝ છબીને કારણે છે કે નહીં.

નબળા INP ની તપાસ

તમારા વપરાશકર્તાઓને ફરિયાદ છે કે “કાર્ટમાં ઉમેરો” બટન પર ક્લિક કરવું અટકી ગયું છે. તમારું INP મેટ્રિક “નબળું” શ્રેણીમાં છે. આ લગભગ હંમેશા મુખ્ય થ્રેડની સમસ્યા છે.

1. લાંબા કાર્યોને ઓળખો: લોંગ ટાસ્ક API અહીં તમારું પ્રાથમિક સાધન છે. તે મુખ્ય થ્રેડ પરના કોઈપણ કાર્યની જાણ કરે છે જે 50ms કરતાં વધુ સમય લે છે, કારણ કે તેનાથી લાંબો સમય વપરાશકર્તાને નોંધપાત્ર વિલંબનું જોખમ છે. `'longtask'` એન્ટ્રી સાંભળવા માટે `PerformanceObserver` સેટ કરો.
2. વપરાશકર્તા ક્રિયાઓ સાથે સહસંબંધ: લાંબુ કાર્ય માત્ર ત્યારે જ સમસ્યા છે જ્યારે તે વપરાશકર્તા ક્રિયાપ્રતિક્રિયા કરવાનો પ્રયાસ કરી રહ્યો હોય. તમે INP ઇવેન્ટના `startTime` (જે `PerformanceObserver` દ્વારા `'event'` પ્રકાર પર અવલોકન કરવામાં આવે છે) ને તે જ સમયે થતા કોઈપણ લાંબા કાર્યોના સમય સાથે સહસંબંધિત કરી શકો છો. આ તમને બરાબર કહે છે કે કયા JavaScript ફંક્શને વપરાશકર્તાની ક્રિયાપ્રતિક્રિયાને અવરોધિત કરી.
3. ચોક્કસ હેન્ડલર્સને માપો: વધુ દાણાદાર થવા માટે વપરાશકર્તા ટાઇમિંગ API નો ઉપયોગ કરો. તમારા નિર્ણાયક ઇવેન્ટ હેન્ડલર્સ (જેમ કે “કાર્ટમાં ઉમેરો” માટે ‘ક્લિક’ હેન્ડલર) ને `performance.mark()` અને `performance.measure()` સાથે લપેટો. આ તમને બરાબર જણાવશે કે તમારો પોતાનો કોડ ચલાવવામાં કેટલો સમય લાગે છે અને શું તે લાંબા કાર્યનો સ્ત્રોત છે.

ઉચ્ચ CLS ને હલ કરવું

વપરાશકર્તાઓ અહેવાલ આપે છે કે તેઓ તેમના મોબાઇલ ઉપકરણો પર એક લેખ વાંચી રહ્યા છે ત્યારે ટેક્સ્ટ આસપાસ કૂદી રહ્યો છે. તમારો CLS સ્કોર 0.3 છે.

1. લેઆઉટ શિફ્ટ્સનું અવલોકન કરો: `'layout-shift'` એન્ટ્રી સાંભળવા માટે `PerformanceObserver` નો ઉપયોગ કરો. દરેક એન્ટ્રીમાં `value` (CLS સ્કોર માટેનું તેનું યોગદાન) અને `sources` ની સૂચિ હશે, જે DOM તત્વો ખસેડાયા છે. આ તમને કહે છે કે *શું* ખસેડ્યું.
2. ગુનેગાર સંસાધન શોધો: આગલો પ્રશ્ન એ છે કે *તે કેમ* ખસેડ્યો. એક સામાન્ય કારણ એ છે કે કોઈ સંસાધન મોડેથી લોડ થાય છે અને અન્ય સામગ્રીને નીચે ધકેલે છે. તમે રિસોર્સ ટાઇમિંગ API માંથી એન્ટ્રીના `responseEnd` સમય સાથે `layout-shift` એન્ટ્રીના `startTime` ને સહસંબંધિત કરી શકો છો. જો કોઈ લેઆઉટ શિફ્ટ કોઈ જાહેરાત સ્ક્રિપ્ટ અથવા મોટી છબી લોડ થવાનું સમાપ્ત થયા પછી તરત જ થાય છે, તો તમે સંભવતઃ તમારા ગુનેગારને શોધી લીધો છે.
3. સક્રિય ઉકેલો: ફિક્સમાં ઘણીવાર છબીઓ અને જાહેરાતો માટે પરિમાણો પ્રદાન કરવાનો સમાવેશ થાય છે (``) અથવા લોડ થાય તે પહેલાં ડાયનેમિક સામગ્રી માટે પૃષ્ઠ પર જગ્યા અનામત રાખવી. રિસોર્સ ટાઇમિંગ તમને એ ઓળખવામાં મદદ કરે છે કે તમારે કયા સંસાધનો માટે સક્રિય બનવાની જરૂર છે.

પ્રાયોગિક અમલીકરણ: વૈશ્વિક મોનિટરિંગ સિસ્ટમનું નિર્માણ

આ API ને સમજવું એક વસ્તુ છે; તમારા વૈશ્વિક વપરાશકર્તા આધારના અનુભવને મોનિટર કરવા માટે તેમને તૈનાત કરવું એ આગળનું પગલું છે. આ રીઅલ યુઝર મોનિટરિંગ (RUM) નો ડોમેન છે.

`PerformanceObserver` સાથે આ બધાને એકસાથે મૂકવું

તમે આ બધા નિર્ણાયક ડેટાને એકત્રિત કરવા માટે એક જ, શક્તિશાળી સ્ક્રિપ્ટ બનાવી શકો છો. ધ્યેય એ છે કે તમે જે પ્રદર્શનને માપવાનો પ્રયાસ કરી રહ્યાં છો તેના પર અસર કર્યા વિના મેટ્રિક્સ અને તેમના સંદર્ભો એકત્રિત કરવા.

અહીં એક મજબૂત નિરીક્ષણ સેટઅપનું એક ખ્યાલિત સ્નિપેટ છે:

const collectedMetrics = {}; const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { if (entry.entryType === 'largest-contentful-paint') { collectedMetrics.lcp = entry.startTime; } else if (entry.entryType === 'layout-shift') { collectedMetrics.cls = (collectedMetrics.cls || 0) + entry.value; } else if (entry.entryType === 'event') { // This is a simplified view of INP calculation const duration = entry.duration; if (duration > (collectedMetrics.inp || 0)) { collectedMetrics.inp = duration; } } // ... and so on for other entry types like 'longtask' } }); observer.observe({ entryTypes: ['largest-contentful-paint', 'layout-shift', 'event', 'longtask'] });

ડેટા ભરોસાપાત્ર રીતે મોકલવો

એકવાર તમે તમારો ડેટા એકત્રિત કરી લો, પછી તમારે તેને સ્ટોરેજ અને વિશ્લેષણ માટે એનાલિટિક્સ બેકએન્ડ પર મોકલવાની જરૂર છે. આ પૃષ્ઠ અનલોડિંગમાં વિલંબ કર્યા વિના અથવા તેમના ટેબ્સ ઝડપથી બંધ કરનારા વપરાશકર્તાઓનો ડેટા ગુમાવ્યા વિના આ કરવું મહત્વપૂર્ણ છે.

આ માટે `navigator.sendBeacon()` API સંપૂર્ણ છે. તે સર્વરને થોડી માત્રામાં ડેટા મોકલવા માટે એક વિશ્વસનીય, એસિન્ક્રોનસ રીત પૂરી પાડે છે, પછી ભલે પૃષ્ઠ અનલોડ થઈ રહ્યું હોય. તે પ્રતિસાદની અપેક્ષા રાખતું નથી, જે તેને હળવા અને બિન-અવરોધક બનાવે છે.

window.addEventListener('visibilitychange', () => { if (document.visibilityState === 'hidden') { const payload = JSON.stringify(collectedMetrics); navigator.sendBeacon('/api/performance-analytics', payload); } });

વૈશ્વિક દૃશ્યનું મહત્વ

લાઇટહાઉસ જેવા લેબ ટેસ્ટિંગ ટૂલ્સ અમૂલ્ય છે, પરંતુ તે નિયંત્રિત વાતાવરણમાં ચાલે છે. આ API માંથી એકત્રિત RUM ડેટા તમને જણાવે છે કે તમારા વપરાશકર્તાઓ વિવિધ દેશો, નેટવર્ક પરિસ્થિતિઓ અને ઉપકરણોમાં શું અનુભવે છે તેનું સત્ય શું છે.

તમારા ડેટાનું વિશ્લેષણ કરતી વખતે, હંમેશા તેને સેગમેન્ટ કરો. તમે શોધી શકો છો કે:

• તમારું LCP ઉત્તર અમેરિકાના વપરાશકર્તાઓ માટે ઉત્તમ છે પરંતુ ઑસ્ટ્રેલિયાના વપરાશકર્તાઓ માટે નબળું છે કારણ કે તમારું પ્રાથમિક છબી સર્વર યુએસમાં આધારિત છે.
• તમારું INP મધ્ય-શ્રેણીના Android ઉપકરણો પર ઊંચું છે, જે ઉભરતા બજારોમાં લોકપ્રિય છે, કારણ કે તમારું JavaScript તેમના માટે ખૂબ જ CPU-સઘન છે.
• તમારી CLS ફક્ત ચોક્કસ સ્ક્રીન કદ પર જ સમસ્યા છે જ્યાં CSS મીડિયા ક્વેરી જાહેરાતને અયોગ્ય રીતે ફરીથી માપવાનું કારણ બને છે.

વિભાજિત આંતરદૃષ્ટિનું આ સ્તર તમને ઑપ્ટિમાઇઝેશન્સને પ્રાથમિકતા આપવા દે છે જે તમારા વાસ્તવિક વપરાશકર્તા આધાર પર સૌથી વધુ નોંધપાત્ર અસર કરશે, પછી ભલે તેઓ ગમે ત્યાં હોય.

નિષ્કર્ષ: માપનથી માસ્ટરી સુધી

વેબ પ્રદર્શનની દુનિયા પરિપક્વ થઈ છે. અમે સરળ તકનીકી સમયથી વપરાશકર્તાના માનવામાં આવતા અનુભવની જટિલ સમજણ તરફ આગળ વધ્યા છીએ. આ યાત્રામાં ત્રણ મુખ્ય પગલાં સામેલ છે:

1. અનુભવને માપો: કોર વેબ વાઇટલ્સ (LCP, INP, CLS) એકત્રિત કરવા માટે `PerformanceObserver` નો ઉપયોગ કરો. આ તમને કહે છે કે *શું* થઈ રહ્યું છે અને તે વપરાશકર્તાને *કેવું લાગે છે*.
2. કારણનું નિદાન કરો: ઊંડાણપૂર્વક તપાસ કરવા માટે ફાઉન્ડેશનલ ટાઇમિંગ API (નેવિગેશન, રિસોર્સ, યુઝર, લોંગ ટાસ્ક) નો ઉપયોગ કરો. આ તમને જણાવે છે કે *કેમ* અનુભવ નબળો છે.
3. ચોકસાઈ સાથે કાર્ય કરો: ચોક્કસ વપરાશકર્તા સેગમેન્ટ માટે સમસ્યાના મૂળ કારણને સંબોધતા, માહિતીપ્રદ, લક્ષિત ઑપ્ટિમાઇઝેશન્સ બનાવવા માટે સંયુક્ત ડેટાનો ઉપયોગ કરો.

ઉચ્ચ-સ્તરના વપરાશકર્તા મેટ્રિક્સ અને નીચા-સ્તરના ડાયગ્નોસ્ટિક API બંનેમાં નિપુણતા મેળવીને, તમે એક સર્વગ્રાહી પ્રદર્શન વ્યૂહરચના બનાવી શકો છો. તમે અનુમાન લગાવવાનું બંધ કરો છો અને વેબનો અનુભવ એન્જિનિયર કરવાનું શરૂ કરો છો જે માત્ર તકનીકી રીતે ઝડપી નથી, પરંતુ તે દરેક વપરાશકર્તાને, દરેક ઉપકરણ પર, વિશ્વમાં દરેક જગ્યાએ ઝડપી, પ્રતિભાવશીલ અને આનંદદાયક લાગે છે.