অ্যানালিটিক্সের মাধ্যমে আসল ব্যবহারকারীদের সমস্যা শনাক্ত ও সমাধান করতে, ডিবাগ তথ্য সহ আপনার পারফর্ম্যান্স ডেটা কীভাবে অ্যাট্রিবিউট করবেন তা জানুন
পারফর্ম্যান্স পরিমাপ ও ডিবাগ করার জন্য Google দু'টি বিভাগের টুল প্রদান করে:
- ল্যাব টুল: Lighthouse-এর মতো টুল, যেখানে আপনার পৃষ্ঠা একটি সিমুলেটেড এনভায়রনমেন্টে লোড করা হয় যা বিভিন্ন কন্ডিশন (যেমন, ধীর নেটওয়ার্ক ও লো-এন্ড মোবাইল ডিভাইস) অনুকরণ করতে পারে।
- ফিল্ড টুল: Chrome ব্যবহারকারীর অভিজ্ঞতা রিপোর্ট (CrUX)-এর মতো টুল, যা Chrome থেকে পাওয়া মোট, প্রকৃত ব্যবহারকারীর ডেটার উপর ভিত্তি করে তৈরি করা হয়। (মনে রাখবেন, PageSpeed Insights এবং Search Console-এর মতো টুলের মাধ্যমে রিপোর্ট করা ফিল্ড ডেটা, CrUX ডেটা থেকে নেওয়া হয়।)
ফিল্ড টুল আরও সঠিক ডেটা প্রদান করে—ডেটা যা আসলে আসল ব্যবহারকারীদের অভিজ্ঞতাকে প্রতিনিধিত্ব করে—অন্যদিকে, ল্যাব টুল আপনাকে সমস্যা শনাক্ত ও সমাধান করতে সাহায্য করার ব্যাপারে প্রায়শই আরও ভালো হয়।
CrUX ডেটা আপনার পৃষ্ঠার আসল পারফর্ম্যান্সের আরও ভাল প্রতিনিধিত্ব করে, কিন্তু আপনার CrUX স্কোর জানলে, পারফর্ম্যান্স কীভাবে উন্নত করবেন তা বুঝতে আপনাকে সাহায্য করার সম্ভাবনা কম।
অন্যদিকে, Lighthouse সমস্যা শনাক্ত করবে এবং কীভাবে উন্নতি করা যায় সেই ব্যাপারে নির্দিষ্ট পরামর্শ দেবে। তবে, Lighthouse শুধুমাত্র পৃষ্ঠা লোড করার সময় পারফর্ম্যান্স সংক্রান্ত যেসব সমস্যা খুঁজে পায় সেগুলির ব্যাপারে সাজেশন দেবে। এটি এমন সমস্যা শনাক্ত করে না যেগুলি শুধুমাত্র ব্যবহারকারীর ইন্টার্যাকশনের ফলে দেখা যায়, যেমন, পৃষ্ঠায় স্ক্রল করা বা বোতামে ক্লিক করা ইত্যাদি।
এটি একটি গুরুত্বপূর্ণ প্রশ্ন উত্থাপন করে: আপনি কীভাবে ফিল্ডে থাকা আসল ব্যবহারকারীদের থেকে Core Web Vitals বা অন্যান্য পারফর্ম্যান্স মেট্রিকের জন্য ডিবাগ তথ্য ক্যাপচার করতে পারবেন?
এই পোস্টে, বর্তমান প্রতিটি Core Web Vitals মেট্রিকের জন্য অতিরিক্ত ডিবাগিং তথ্য সংগ্রহ করতে আপনি কোন API ব্যবহার করতে পারবেন তা বিস্তারিতভাবে ব্যাখ্যা করা হবে এবং আপনার বর্তমান Analytics টুলে কীভাবে এই ডেটা ক্যাপচার করবেন সেই সম্পর্কে ধারণা দেওয়া হবে।
অ্যাট্রিবিউশন ও ডিবাগিংয়ের জন্য API
Cumulative Layout Shift (CLS)
সব Core Web Vitals মেট্রিকের মধ্যে, CLS হল সম্ভবত এমন একটি মেট্রিক যার জন্য ফিল্ডে ডিবাগ সংক্রান্ত তথ্য সংগ্রহ করা সবচেয়ে গুরুত্বপূর্ণ। CLS-কে পৃষ্ঠার সম্পূর্ণ জীবনকাল জুড়ে পরিমাপ করা হয়, তাই কোনও ব্যবহারকারী যেভাবে পৃষ্ঠার সাথে ইন্টার্যাক্ট করেন—কতদূর স্ক্রল করেন, কী ক্লিক করেন এবং আরও অনেক কিছু—তা লেআউট শিফট আছে কিনা এবং কোন এলিমেন্ট শিফট করছে তার উপর একটি উল্লেখযোগ্য প্রভাব ফেলতে পারে।
PageSpeed Insights থেকে পাওয়া নিম্নলিখিত রিপোর্টটি বিবেচনা করুন:
ল্যাব (Lighthouse) থেকে পাওয়া CLS-এর ভ্যালু এবং ফিল্ড (CrUX ডেটা) থেকে পাওয়া CLS-এর ভ্যালুর মধ্যে অনেক পার্থক্য আছে। এর কারণ হল, Lighthouse-এ পরীক্ষা করার সময় পৃষ্ঠায় থাকা অনেক ইন্ট্যার্যাক্টিভ কন্টেন্ট ব্যবহার করা হয় না।
তবে, আপনি যদি এটি বুঝতে পারেন যে ব্যবহারকারীর ইন্টার্যাকশন ফিল্ড ডেটাকে প্রভাবিত করে, তবুও আপনাকে জানতে হবে যে পৃষ্ঠার কোন কোন এলিমেন্ট শিফট করার ফলে ৭৫তম পার্সেন্টাইলে ০.২৮ স্কোর পাওয়া গেছে। LayoutShiftAttribution ইন্টারফেসের মাধ্যমে এটি সম্ভব হয়।
লেআউট শিফ্ট অ্যাট্রিবিউশন পাওয়া
LayoutShiftAttribution
ইন্টারফেস প্রতিটি layout-shift এন্ট্রি থেকে এক্সপোজ করা হয় যা Layout Instability
API নির্গত করে।
এই দুটি ইন্টারফেসের বিস্তারিত ব্যাখ্যা পেতে, Debug লেআউট শিফ্ট দেখুন। এই পোস্টের উদ্দেশ্য হল, আপনাকে মূল যে বিষয়টি জানতে হবে তা হল, একজন ডেভেলপার হিসেবে, আপনি পৃষ্ঠায় হওয়া প্রতিটি লেআউট শিফ্ট এবং কোন কোন এলিমেন্ট শিফট করছে তা পর্যবেক্ষণ করতে পারবেন।
এখানে কিছু উদাহরণ কোড দেওয়া হল যা প্রতিটি লেআউট শিফ্ট এবং তার সাথে শিফট করা এলিমেন্ট লগ করে:
new PerformanceObserver((list) => {
for (const {value, startTime, sources} of list.getEntries()) {
// Log the shift amount and other entry info.
console.log('Layout shift:', {value, startTime});
if (sources) {
for (const {node, curRect, prevRect} of sources) {
// Log the elements that shifted.
console.log(' Shift source:', node, {curRect, prevRect});
}
}
}
}).observe({type: 'layout-shift', buffered: true});
প্রতিটি লেআউট শিফ্টের জন্য আপনার অ্যানালিটিক্স টুলে ডেটা পরিমাপ ও পাঠানো সম্ভব নাও হতে পারে; তবে, সব শিফ্ট মনিটর করার মাধ্যমে, আপনি সবচেয়ে খারাপ শিফ্টগুলি ট্র্যাক করতে এবং শুধুমাত্র সেইসব শিফ্ট সম্পর্কে তথ্য রিপোর্ট করতে পারবেন।
প্রতিটি ব্যবহারকারীর জন্য হওয়া প্রতিটি লেআউট শিফট শনাক্ত করা ও ঠিক করা লক্ষ্য নয়; সবচেয়ে বেশি সংখ্যক ব্যবহারকারীকে প্রভাবিত করে এবং এইভাবে ৭৫ পার্সেন্টাইলে আপনার পৃষ্ঠার CLS-এ সবচেয়ে বেশি কন্ট্রিবিউট করে, এমন শিফট শনাক্ত করা লক্ষ্য।
এছাড়াও, যখনই কোনও শিফট হয়, আপনাকে প্রতিবার সবচেয়ে বড় সোর্স এলিমেন্ট গণনা করতে হবে না, আপনাকে শুধুমাত্র তখনই এটি করতে হবে যখন আপনি নিজের অ্যানালিটিক্স টুলে CLS ভ্যালু পাঠানোর জন্য প্রস্তুত হন।
নিচে দেওয়া কোডটি layout-shift এন্ট্রিগুলির একটি তালিকা নেয় যেগুলি CLS-এ কন্ট্রিবিউট করেছে
এবং সবচেয়ে বড় শিফ্ট থেকে সবচেয়ে বড় সোর্স এলিমেন্ট রিটার্ন করে:
function getCLSDebugTarget(entries) {
const largestEntry = entries.reduce((a, b) => {
return a && a.value > b.value ? a : b;
});
if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
const largestSource = largestEntry.sources.reduce((a, b) => {
return a.node && a.previousRect.width * a.previousRect.height >
b.previousRect.width * b.previousRect.height ? a : b;
});
if (largestSource) {
return largestSource.node;
}
}
}
সবচেয়ে বড় শিফটে অবদান রাখা সবচেয়ে বড় এলিমেন্টটি শনাক্ত করার পরে, সেটি আপনার অ্যানালিটিক্স টুলে রিপোর্ট করতে পারবেন।
কোনও নির্দিষ্ট পৃষ্ঠার জন্য CLS-এ সবচেয়ে বেশি কন্ট্রিবিউট করা এলিমেন্ট ব্যবহারকারী ভেদে আলাদা হতে পারে, কিন্তু আপনি যদি সব ব্যবহারকারী জুড়ে সেইসব এলিমেন্ট একত্রিত করেন, তাহলে আপনি এমন শিফ্ট করা এলিমেন্টের একটি তালিকা তৈরি করতে পারবেন যা সবচেয়ে বেশি সংখ্যক ব্যবহারকারীকে প্রভাবিত করে।
আপনি যদি সেইসব এলিমেন্টের শিফটের মূল কারণ শনাক্ত ও সমাধান করে থাকেন, তাহলে আপনার অ্যানালিটিক্স কোড ছোট শিফটগুলিকে আপনার পৃষ্ঠার "সবচেয়ে খারাপ" শিফট হিসেবে রিপোর্ট করা শুরু করবে। অবশেষে, সবকটি রিপোর্ট করা শিফ্ট এত ছোট হবে যে আপনার পৃষ্ঠাগুলি "ভাল" থ্রেশহোল্ডের 0.1-এর মধ্যে থাকবে!
সবচেয়ে বড় শিফ্টের সাথে ক্যাপচার করা যেতে পারে এমন কিছু অন্যান্য মেটাডেটা সোর্স এলিমেন্ট হল:
- সবচেয়ে বড় শিফটের সময়
- সবচেয়ে বড় পরিবর্তন হওয়ার সময় URL পাথ (যেসব সাইট ডায়নামিক পদ্ধতিতে URL আপডেট করে, যেমন সিঙ্গেল পেজ অ্যাপ্লিকেশন)।
Largest Contentful Paint (LCP)
ফিল্ডে LCP ডিবাগ করতে, আপনার প্রয়োজনীয় প্রাথমিক তথ্য হল, কোন নির্দিষ্ট এলিমেন্ট সেই নির্দিষ্ট পেজ লোডের জন্য সবচেয়ে বড় এলিমেন্ট (LCP ক্যান্ডিডেট এলিমেন্ট) ছিল।
মনে রাখবেন যে এটি সম্পূর্ণ সম্ভব—আসলে, এটি বেশ সাধারণ—যে LCP ক্যান্ডিডেট এলিমেন্ট ব্যবহারকারী থেকে ব্যবহারকারীর ক্ষেত্রে আলাদা হবে, এমনকি ঠিক একই পৃষ্ঠার ক্ষেত্রেও।
একাধিক কারণে এমন হতে পারে:
- ব্যবহারকারীর ডিভাইসে আলাদা আলাদা স্ক্রিন রেজোলিউশন থাকে, এর ফলে আলাদা আলাদা পেজ লেআউট তৈরি হয় এবং ভিউপোর্টের মধ্যে আলাদা আলাদা এলিমেন্ট দেখা যায়।
- ব্যবহারকারীরা সবসময় স্ক্রল করে পৃষ্ঠার সবচেয়ে উপরে যান না। প্রায়শই লিঙ্কে ফ্র্যাগমেন্ট আইডেন্টিফায়ার বা এমনকি টেক্সট ফ্র্যাগমেন্ট থাকে, যার অর্থ হল আপনার পৃষ্ঠা লোড করা এবং পৃষ্ঠার যেকোনও স্ক্রল পজিশনে দেখানো সম্ভব।
- বর্তমান ব্যবহারকারীর জন্য কন্টেন্ট পছন্দমতো হতে পারে, তাই LCP ক্যান্ডিডেট এলিমেন্ট ব্যবহারকারী ভেদে অনেক আলাদা হতে পারে।
এর অর্থ হল, কোনও নির্দিষ্ট পৃষ্ঠার জন্য কোন এলিমেন্ট বা এলিমেন্টের সেট সবচেয়ে সাধারণ LCP ক্যান্ডিডেট এলিমেন্ট হবে সেই সম্পর্কে আপনি কোনও অনুমান করতে পারবেন না। আপনাকে আসল ব্যবহারকারীর আচরণের উপর ভিত্তি করে এটি পরিমাপ করতে হবে।
LCP ক্যান্ডিডেট এলিমেন্ট শনাক্ত করা
JavaScript-এ LCP ক্যান্ডিডেট এলিমেন্ট নির্ধারণ করতে, আপনি Largest Contentful Paint API ব্যবহার করতে পারেন। LCP টাইম ভ্যালু নির্ধারণ করতে আপনি একই API ব্যবহার করেন।
largest-contentful-paint এন্ট্রি পর্যবেক্ষণ করার সময়, আপনি শেষ এন্ট্রির element প্রপার্টি দেখে
বর্তমান LCP ক্যান্ডিডেট এলিমেন্ট নির্ধারণ করতে পারবেন:
new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});
LCP ক্যান্ডিডেট এলিমেন্ট সম্পর্কে জানার পরে, আপনি এটি মেট্রিক ভ্যালু সহ আপনার অ্যানালিটিক্স টুলে পাঠাতে পারবেন। CLS-এর মতো, এটি আপনাকে শনাক্ত করতে সাহায্য করবে যে কোন এলিমেন্ট প্রথমে অপ্টিমাইজ করা সবচেয়ে গুরুত্বপূর্ণ।
LCP ক্যান্ডিডেট এলিমেন্ট ছাড়াও, LCP সাব-পার্ট টাইম পরিমাপ করাও কাজে লাগতে পারে। আপনার সাইটের জন্য কোন নির্দিষ্ট অপ্টিমাইজেশন ধাপ প্রাসঙ্গিক তা নির্ধারণ করতে এটি কাজে লাগতে পারে।
Interaction to Next Paint (INP)
ফিল্ডে INP-এর জন্য ক্যাপচার করার সবচেয়ে গুরুত্বপূর্ণ তথ্য হল:
- কোন এলিমেন্টের সাথে ইন্টার্যাক্ট করা হয়েছে
- কী ধরনের ইন্টার্যাকশন ছিল
- সেই ইন্টার্যাকশন কখন হয়েছিল
ইন্টার্যাকশন ধীরে হওয়ার একটি প্রধান কারণ হল ব্লক করা মূল থ্রেড, যা জাভাস্ক্রিপ্ট লোড করার সময় সাধারণ হতে পারে। পৃষ্ঠা লোড হওয়ার সময় বেশিরভাগ ধীর ইন্টার্যাকশন হয় কিনা তা জানলে, সমস্যা সমাধানের জন্য কী করতে হবে তা নির্ধারণ করতে সুবিধা হয়।
INP মেট্রিক কোনও ইন্টার্যাকশনের সম্পূর্ণ লেটেন্সি বিবেচনা করে—এর মধ্যে কোনও রেজিস্টার করা ইভেন্ট লিসনার রান করতে লাগা সময় এবং সমস্ত ইভেন্ট লিসনার রান করার পরে পরবর্তী ফ্রেম পেইন্ট করতে লাগা সময় অন্তর্ভুক্ত। এর অর্থ হল, INP-এর ক্ষেত্রে, কোন টার্গেট এলিমেন্টের ফলে ইন্ট্যার্যাকশন ধীরে হয় এবং সেইসব ইন্ট্যার্যাকশনের ধরন কী, তা জানা খুবই গুরুত্বপূর্ণ।
নিচের কোডটি টার্গেট এলিমেন্ট এবং INP এন্ট্রির সময় লগ করে।
function logINPDebugInfo(inpEntry) {
console.log('INP target element:', inpEntry.target);
console.log('INP interaction type:', inpEntry.name);
console.log('INP time:', inpEntry.startTime);
}
মনে রাখবেন, এই কোডটি দেখায় না যে কীভাবে নির্ধারণ করতে হয় যে কোন event এন্ট্রি হল INP
এন্ট্রি, কারণ সেই লজিক আরও বেশি জটিল। তবে, নিম্নলিখিত বিভাগে
web-vitals জাভাস্ক্রিপ্ট লাইব্রেরি ব্যবহার করে
এই তথ্য কীভাবে পাবেন তা ব্যাখ্যা করা হয়েছে।
web-vitals জাভাস্ক্রিপ্ট লাইব্রেরির সাথে ব্যবহার
আগের বিভাগে, আপনার অ্যানালিটিক্স টুলে পাঠানো ডেটাতে অন্তর্ভুক্ত করার জন্য ডিবাগ সংক্রান্ত তথ্য ক্যাপচার করার কিছু সাধারণ সাজেশন ও কোডের উদাহরণ দেওয়া হয়েছে।
ভার্সন ৩ থেকে, web-vitals JavaScript লাইব্রেরিতে একটি অ্যাট্রিবিউশন বিল্ড অন্তর্ভুক্ত থাকে যা এইসব তথ্য এবং কিছু অতিরিক্ত সিগন্যালও দেখায়।
পারফর্ম্যান্স সমস্যার মূল কারণ শনাক্ত করতে সাহায্য করার জন্য একটি ডিবাগ স্ট্রিং সহ অতিরিক্ত ইভেন্ট প্যারামিটার (বা কাস্টম ডাইমেনশন) কীভাবে সেট করতে পারেন তা নিম্নলিখিত কোডের উদাহরণ থেকে জানতে পারবেন।
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'CLS':
eventParams.debug_target = attribution.largestShiftTarget;
break;
case 'LCP':
eventParams.debug_target = attribution.element;
break;
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
break;
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
এই কোডটি Google Analytics-এর জন্য নির্দিষ্ট, তবে সাধারণ ধারণাটি অন্যান্য অ্যানালিটিক্স টুলের ক্ষেত্রেও প্রযোজ্য।
এই কোডটি শুধুমাত্র একটি ডিবাগ সিগন্যাল সম্পর্কে কীভাবে রিপোর্ট করতে হয় তা দেখায়, তবে এটি প্রতিটি মেট্রিকের জন্য একাধিক আলাদা সিগন্যাল সংগ্রহ ও রিপোর্ট করতে পারলে ভাল হয়।
যেমন, INP ডিবাগ করার জন্য, আপনি ইন্ট্যার্যাক্ট করা এলিমেন্ট, ইন্টার্যাকশনের ধরন, সময়, loadState, ইন্টার্যাকশন ফেজ ও আরও অনেক কিছু (যেমন দীর্ঘ অ্যানিমেশন ফ্রেম ডেটা) সংগ্রহ করতে পারেন।
web-vitals অ্যাট্রিবিউশন বিল্ড অতিরিক্ত অ্যাট্রিবিউশন তথ্য প্রকাশ করে,
যেমন INP-এর জন্য নিম্নলিখিত উদাহরণে দেখানো হয়েছে:
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
eventParams.debug_type = attribution.interactionType;
eventParams.debug_time = attribution.interactionTime;
eventParams.debug_load_state = attribution.loadState;
eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
eventParams.debug_presentation_delay = Math.round(attribution.presentationDelay);
break;
// Additional metric logic...
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
প্রকাশিত ডিবাগ সিগন্যালের সম্পূর্ণ তালিকা পেতে, ওয়েব-ভাইটাল অ্যাট্রিবিউশন ডকুমেন্টেশন দেখুন।
ডেটা সম্পর্কে রিপোর্ট করা ও তা ভিজ্যুয়ালাইজ করা
মেট্রিক ভ্যালু সহ ডিবাগ তথ্য সংগ্রহ করা শুরু করার পরে, পরবর্তী ধাপ হল, প্যাটার্ন ও ট্রেন্ড খোঁজা শুরু করতে, আপনার সব ব্যবহারকারীর ডেটা একত্রিত করা।
আগে উল্লেখ করা হয়েছে, আপনার ব্যবহারকারীরা যেসব সমস্যার সম্মুখীন হচ্ছেন, আপনাকে সেগুলির প্রত্যেকটি সমাধান করতে হবে না। আপনি সেইসব সমস্যা সমাধান করতে চান—বিশেষ করে প্রথমে—যেগুলি সবচেয়ে বেশি সংখ্যক ব্যবহারকারীকে প্রভাবিত করছে এবং সেগুলি এমন সমস্যা হওয়া উচিত যেগুলি আপনার Core Web Vitals স্কোরের উপর সবচেয়ে বেশি নেতিবাচক প্রভাব ফেলে।
GA4-এর জন্য, BigQuery ব্যবহার করে কীভাবে ডেটা কোয়েরি ও ভিজ্যুয়ালাইজ করতে হয়সেই সম্পর্কিত নিবন্ধ দেখুন।
সারাংশ
আশা করি, এই পোস্টটি আপনাকে নির্দিষ্ট উপায়গুলি সম্পর্কে একটি ধারণা দিয়েছে যার মাধ্যমে আপনি
বিদ্যমান পারফর্ম্যান্স API এবং web-vitals লাইব্রেরি ব্যবহার করে ডিবাগ তথ্য পেতে পারেন।
এর ফলে ফিল্ডে আসল ব্যবহারকারীদের ভিজিটের উপর ভিত্তি করে পারফর্ম্যান্স ডায়াগনসিস করতে সাহায্য পাওয়া যায়। এই
নির্দেশিকাটি Core Web Vitals-এর উপর ফোকাস করলেও, JavaScript-এ পরিমাপযোগ্য
যেকোনও পারফর্ম্যান্স মেট্রিক ডিবাগ করার ক্ষেত্রেও এই ধারণাগুলি প্রযোজ্য।
আপনি যদি একজন অ্যানালিটিক্স ভেন্ডর হন এবং আপনার প্রোডাক্ট উন্নত করতে ও ব্যবহারকারীদের আরও বেশি ডিবাগিং সংক্রান্ত তথ্য প্রদান করতে চান, তাহলে এখানে বর্ণিত কিছু কৌশল বিবেচনা করুন, তবে এখানে উপস্থাপিত ধারণাগুলির মধ্যে নিজেকে সীমাবদ্ধ রাখবেন না। এই পোস্টটি সাধারণভাবে সমস্ত অ্যানালিটিক্স টুলের ক্ষেত্রে প্রযোজ্য হওয়ার উদ্দেশ্যে লেখা হয়েছে; তবে, স্বতন্ত্র অ্যানালিটিক্স টুল সম্ভবত আরও বেশি ডিবাগ তথ্য ক্যাপচার ও রিপোর্ট করতে পারে (এবং করা উচিত)।
সবশেষে, API-তে ফিচার বা তথ্য না থাকার কারণে এইসব মেট্রিক ডিবাগ করার ক্ষেত্রে কোনও সমস্যা হলে, আপনার মতামত web-vitals-feedback@googlegroups.com আইডিতে পাঠান।