কোর ওয়েব ভাইটাল মেট্রিক্স নিরীক্ষণকারী সরঞ্জামগুলি কেন বিভিন্ন সংখ্যার রিপোর্ট করতে পারে এবং সেই পার্থক্যগুলিকে কীভাবে ব্যাখ্যা করতে হয় তা জানুন।
সাইটের মালিকদের তাদের Core Web Vitals স্কোর নিরীক্ষণ করতে সাহায্য করার জন্য Google অনেকগুলি টুল সরবরাহ করে। এই সরঞ্জাম দুটি প্রধান বিভাগে পড়ে:
- সরঞ্জাম যা ল্যাব ডেটা রিপোর্ট করে — পূর্বনির্ধারিত ডিভাইস এবং নেটওয়ার্ক সেটিংস সহ একটি নিয়ন্ত্রিত পরিবেশে সংগ্রহ করা ডেটা।
- টুল যা ফিল্ড ডেটার রিপোর্ট করে — আপনার সাইটে আসা প্রকৃত ব্যবহারকারীদের কাছ থেকে সংগৃহীত ডেটা।
সমস্যা হল যে কখনও কখনও ল্যাব টুলস দ্বারা রিপোর্ট করা ডেটা ফিল্ড টুলস দ্বারা রিপোর্ট করা ডেটা থেকে বেশ কিছুটা আলাদা হতে পারে! আপনার ল্যাব ডেটা ইঙ্গিত দিতে পারে যে আপনার সাইটটি দুর্দান্ত পারফরম্যান্স করছে, তবে আপনার ফিল্ড ডেটা পরামর্শ দেয় যে এটির উন্নতি প্রয়োজন। বিকল্পভাবে, আপনার ফিল্ড ডেটা বলতে পারে আপনার সমস্ত পৃষ্ঠা ভাল, কিন্তু আপনার ল্যাব ডেটা খুব কম স্কোর রিপোর্ট করতে পারে।
web.dev থেকে পেজস্পিড ইনসাইটস রিপোর্টের নিম্নলিখিত বাস্তব উদাহরণ দেখায় যে কিছু ক্ষেত্রে ল্যাব এবং ফিল্ড ডেটা সমস্ত মূল ওয়েব ভাইটাল মেট্রিক্স জুড়ে আলাদা হতে পারে:
সরঞ্জামগুলির মধ্যে পার্থক্য বিকাশকারীদের জন্য বিভ্রান্তির একটি বোধগম্য উত্স। এই পোস্টটি ব্যাখ্যা করে যে এই পার্থক্যগুলি বিদ্যমান থাকতে পারে—কোর ওয়েব ভাইটাল মেট্রিক্সের প্রতিটি কভার করে নির্দিষ্ট উদাহরণ সহ—এবং আপনি যখন আপনার পৃষ্ঠাগুলিতে পার্থক্য খুঁজে পান তখন কী করবেন।
ল্যাব ডেটা বনাম ফিল্ড ডেটা
ল্যাব এবং ফিল্ড টুলগুলি কেন ভিন্ন মানের রিপোর্ট করতে পারে তা বোঝার জন্য-এমনকি একই ওয়েব পৃষ্ঠার জন্যও-আপনাকে ল্যাব এবং ফিল্ড ডেটার মধ্যে পার্থক্য বুঝতে হবে।
ল্যাব ডেটা
ল্যাব ডেটা একটি নিয়ন্ত্রিত পরিবেশে একটি পূর্বনির্ধারিত নেটওয়ার্ক এবং ডিভাইস শর্তাবলী সহ একটি ওয়েব পৃষ্ঠা লোড করার মাধ্যমে নির্ধারিত হয়। এই অবস্থাগুলি একটি ল্যাব পরিবেশ হিসাবে পরিচিত, কখনও কখনও একটি সিন্থেটিক পরিবেশ হিসাবেও উল্লেখ করা হয়।
ল্যাব ডেটা রিপোর্ট করে এমন ক্রোম টুলগুলি সাধারণত লাইটহাউস চালায়।
একটি ল্যাব পরীক্ষার উদ্দেশ্য হল আপনি যতটা সম্ভব অনেকগুলি কারণকে নিয়ন্ত্রণ করতে পারেন, তাই ফলাফলগুলি (যতটা সম্ভব) ধারাবাহিক এবং পুনরুত্পাদনযোগ্য হয় দৌড় থেকে দৌড়ে।
ক্ষেত্রের তথ্য
একটি পৃষ্ঠা পরিদর্শনকারী সমস্ত ব্যবহারকারীদের নিরীক্ষণ করে এবং সেই ব্যবহারকারীদের প্রত্যেকের ব্যক্তিগত অভিজ্ঞতার জন্য একটি নির্দিষ্ট কর্মক্ষমতা মেট্রিক্স পরিমাপ করে ফিল্ড ডেটা নির্ধারণ করা হয়। যেহেতু ফিল্ড ডেটা বাস্তব-ব্যবহারকারীর পরিদর্শনের উপর ভিত্তি করে, এটি আপনার ব্যবহারকারীদের প্রকৃত ডিভাইস, নেটওয়ার্ক অবস্থা এবং ভৌগলিক অবস্থানগুলিকে প্রতিফলিত করে।
ফিল্ড ডেটা সাধারণত রিয়েল ইউজার মনিটরিং (RUM) ডেটা নামেও পরিচিত; দুটি পদ বিনিময়যোগ্য।
ক্রোম টুলগুলি যেগুলি ফিল্ড ডেটা রিপোর্ট করে সাধারণত সেই ডেটা Chrome ব্যবহারকারীর অভিজ্ঞতা রিপোর্ট (CrUX) থেকে পায়৷ সাইটের মালিকদের নিজেরাই ফিল্ড ডেটা সংগ্রহ করাও সাধারণ (এবং প্রস্তাবিত) কারণ এটি শুধুমাত্র CrUX ব্যবহার করার চেয়ে আরও কার্যকর অন্তর্দৃষ্টি প্রদান করতে পারে।
ফিল্ড ডেটা সম্পর্কে বোঝার সবচেয়ে গুরুত্বপূর্ণ বিষয় হল এটি শুধুমাত্র একটি সংখ্যা নয়, এটি সংখ্যাগুলির একটি বিতরণ। অর্থাৎ, কিছু লোক যারা আপনার সাইটে ভিজিট করে, তাদের জন্য এটি খুব দ্রুত লোড হতে পারে, অন্যদের জন্য এটি খুব ধীরে ধীরে লোড হতে পারে। আপনার সাইটের ফিল্ড ডেটা হল আপনার ব্যবহারকারীদের থেকে সংগ্রহ করা সমস্ত পারফরম্যান্স ডেটার সম্পূর্ণ সেট।
উদাহরণ হিসেবে, CrUX রিপোর্টগুলি 28-দিনের মেয়াদে প্রকৃত Chrome ব্যবহারকারীদের থেকে কর্মক্ষমতা মেট্রিক্সের একটি বিতরণ দেখায়। আপনি যদি প্রায় কোনও CrUX রিপোর্ট দেখেন তবে আপনি দেখতে পাবেন যে কিছু ব্যবহারকারী যারা একটি সাইট পরিদর্শন করেন তাদের খুব ভাল অভিজ্ঞতা থাকতে পারে যখন অন্যদের খুব খারাপ অভিজ্ঞতা থাকতে পারে।
যদি একটি টুল একটি প্রদত্ত মেট্রিকের জন্য একটি একক সংখ্যা রিপোর্ট করে, তবে এটি সাধারণত বিতরণে একটি নির্দিষ্ট বিন্দু প্রতিনিধিত্ব করবে। যে টুলগুলি কোর ওয়েব ভাইটাল ফিল্ড স্কোর রিপোর্ট করে 75তম পার্সেন্টাইল ব্যবহার করে তা করে।
উপরের স্ক্রিনশটে ফিল্ড ডেটা থেকে এলসিপির দিকে তাকিয়ে, আপনি একটি বিতরণ দেখতে পারেন যেখানে:
- 88% ভিজিট 2.5 সেকেন্ড বা তার কম (ভাল) একটি LCP দেখেছে।
- 8% ভিজিট 2.5 থেকে 4 সেকেন্ডের মধ্যে একটি LCP দেখেছে (উন্নতি প্রয়োজন)।
- 4% ভিজিট 4 সেকেন্ডের বেশি (খারাপ) একটি LCP দেখেছে।
75 তম শতাংশে, LCP ছিল 1.8 সেকেন্ড:
একই পৃষ্ঠা থেকে ল্যাব ডেটা 3.0 সেকেন্ডের একটি LCP মান দেখায়। যদিও এই মানটি ফিল্ড ডেটাতে দেখানো 1.8 সেকেন্ডের চেয়ে বেশি, তবুও এটি এই পৃষ্ঠার জন্য একটি বৈধ LCP মান—এটি অনেকগুলি মানগুলির মধ্যে একটি যা লোড অভিজ্ঞতার সম্পূর্ণ বন্টন তৈরি করে৷
কেন ল্যাব এবং ফিল্ড ডেটা আলাদা
উপরের বিভাগটি ব্যাখ্যা করে, ল্যাব ডেটা এবং ফিল্ড ডেটা আসলে খুব আলাদা জিনিস পরিমাপ করে।
ফিল্ড ডেটার মধ্যে রয়েছে বিভিন্ন ধরনের নেটওয়ার্ক এবং ডিভাইসের অবস্থার পাশাপাশি ব্যবহারকারীর বিভিন্ন ধরনের আচরণের অগণিত। এতে ব্যবহারকারীর অভিজ্ঞতাকে প্রভাবিত করে এমন অন্য কোনো কারণও রয়েছে, যেমন ব্যাক/ফরোয়ার্ড ক্যাশে (bfcache), বা AMP ক্যাশের মতো প্ল্যাটফর্ম অপ্টিমাইজেশনের মতো ব্রাউজার অপ্টিমাইজেশান।
বিপরীতে, ল্যাব ডেটা ইচ্ছাকৃতভাবে জড়িত ভেরিয়েবলের সংখ্যা সীমিত করে। একটি ল্যাব পরীক্ষা গঠিত:
- একটি একক ডিভাইস…
- একটি একক নেটওয়ার্কের সাথে সংযুক্ত…
- একটি একক ভৌগলিক অবস্থান থেকে চালানো.
কোনো প্রদত্ত ল্যাব পরীক্ষার বিবরণ একটি প্রদত্ত পৃষ্ঠা বা সাইটের জন্য ফিল্ড ডেটার 75 তম শতাংশকে সঠিকভাবে উপস্থাপন করতে পারে বা নাও করতে পারে।
ল্যাবের নিয়ন্ত্রিত পরিবেশ সমস্যাগুলি ডিবাগ করার সময় বা প্রোডাকশনে মোতায়েন করার আগে বৈশিষ্ট্যগুলি পরীক্ষা করার সময় উপযোগী, কিন্তু আপনি যখন এই কারণগুলির জন্য নিয়ন্ত্রণ করেন তখন আপনি স্পষ্টভাবে সমস্ত ধরণের নেটওয়ার্ক, ডিভাইসের ক্ষমতা, বা জুড়ে বাস্তব বিশ্বে যে বৈচিত্র্য দেখতে পান তা উপস্থাপন করছেন না। ভৌগলিক অবস্থান। এছাড়াও আপনি সাধারণত বাস্তব-ব্যবহারকারীর আচরণের কার্যক্ষমতার প্রভাব ক্যাপচার করছেন না, যেমন স্ক্রোল করা, পাঠ্য নির্বাচন করা বা পৃষ্ঠায় উপাদান ট্যাপ করা।
ল্যাবের অবস্থা এবং বেশিরভাগ বাস্তব-বিশ্ব ব্যবহারকারীদের অবস্থার মধ্যে সম্ভাব্য সংযোগ বিচ্ছিন্ন হওয়ার পাশাপাশি, আরও কিছু সূক্ষ্ম পার্থক্য রয়েছে যা আপনার ল্যাব এবং ফিল্ড ডেটা থেকে সবচেয়ে বেশি বোঝার জন্য বোঝা গুরুত্বপূর্ণ। কোন পার্থক্য হিসাবে আপনি খুঁজে পেতে পারেন.
কোর ওয়েব ভাইটালস মেট্রিক্সের প্রতিটির জন্য ল্যাব ডেটা এবং ফিল্ড ডেটার মধ্যে পার্থক্য থাকতে পারে এমন সবচেয়ে সাধারণ কারণগুলিকে হাইলাইট করে পরবর্তী কয়েকটি বিভাগে বিশদ বিবরণ দেওয়া হয়েছে:
এলসিপি
বিভিন্ন LCP উপাদান
একটি ল্যাব পরীক্ষায় শনাক্ত এলসিপি উপাদানটি ব্যবহারকারীরা আপনার পৃষ্ঠা দেখার সময় দেখতে একই LCP উপাদান নাও হতে পারে।
আপনি যদি একটি প্রদত্ত পৃষ্ঠার জন্য একটি লাইটহাউস রিপোর্ট চালান, তাহলে এটি প্রতিবার একই LCP উপাদানটি ফিরিয়ে দেবে। কিন্তু আপনি যদি একই পৃষ্ঠার জন্য ফিল্ড ডেটা দেখেন, আপনি সাধারণত বিভিন্ন LCP উপাদান খুঁজে পাবেন, যা প্রতিটি পৃষ্ঠা পরিদর্শনের জন্য নির্দিষ্ট কিছু পরিস্থিতির উপর নির্ভর করে।
উদাহরণস্বরূপ, নিম্নলিখিত কারণগুলি একই পৃষ্ঠার জন্য একটি ভিন্ন LCP উপাদান নির্ধারণে অবদান রাখতে পারে:
- বিভিন্ন ডিভাইসের পর্দার আকারের ফলে ভিউপোর্টের মধ্যে বিভিন্ন উপাদান দৃশ্যমান হয়।
- যদি ব্যবহারকারী লগ ইন করে থাকেন, অথবা যদি ব্যক্তিগতকৃত বিষয়বস্তু কোনোভাবে দেখানো হয়, তাহলে LCP উপাদানটি ব্যবহারকারী থেকে ব্যবহারকারীতে খুব আলাদা হতে পারে।
- পূর্ববর্তী পয়েন্টের মতো, যদি একটি A/B পরীক্ষা পৃষ্ঠায় চলমান থাকে তবে এর ফলে খুব ভিন্ন উপাদান প্রদর্শিত হতে পারে।
- ব্যবহারকারীর সিস্টেমে ইনস্টল করা ফন্টের সেট পৃষ্ঠার পাঠ্যের আকারকে প্রভাবিত করতে পারে (এবং এইভাবে কোন উপাদানটি এলসিপি উপাদান)।
- ল্যাব পরীক্ষাগুলি সাধারণত একটি পৃষ্ঠার "বেস" URL-এ চালিত হয়—কোনো কোয়েরি প্যারামিটার বা হ্যাশ টুকরা যোগ না করে। কিন্তু বাস্তব জগতে, ব্যবহারকারীরা প্রায়ই একটি খণ্ড শনাক্তকারী বা টেক্সট ফ্র্যাগমেন্ট ধারণকারী URL শেয়ার করে, তাই LCP উপাদানটি আসলে পৃষ্ঠার মাঝখানে বা নীচে হতে পারে ("ভাঁজের উপরে" না হয়ে)।
যেহেতু ক্ষেত্রের LCP একটি পৃষ্ঠায় সমস্ত ব্যবহারকারীর ভিজিটের 75 তম শতাংশ হিসাবে গণনা করা হয়, যদি সেই ব্যবহারকারীদের একটি বড় শতাংশের একটি LCP উপাদান থাকে যা খুব দ্রুত লোড হয়—উদাহরণস্বরূপ, একটি সিস্টেম ফন্টের সাথে রেন্ডার করা পাঠ্যের একটি অনুচ্ছেদ—তারপরেও এই ব্যবহারকারীদের মধ্যে কিছু তাদের LCP উপাদান হিসাবে একটি বড়, ধীর-লোডিং ইমেজ ছিল, এটি সেই পৃষ্ঠার স্কোরকে প্রভাবিত নাও করতে পারে যদি এটি 25% এর কম দর্শকের ক্ষেত্রে ঘটে।
বিকল্পভাবে, বিপরীত সত্য হতে পারে. একটি ল্যাব টেস্ট LCP উপাদান হিসাবে পাঠ্যের একটি ব্লককে সনাক্ত করতে পারে কারণ এটি একটি Moto G4 ফোনকে অনুকরণ করছে যার একটি অপেক্ষাকৃত ছোট ভিউপোর্ট রয়েছে এবং আপনার পৃষ্ঠার হিরো ইমেজ প্রাথমিকভাবে অফ-স্ক্রীন রেন্ডার করা হয়েছে। আপনার ফিল্ড ডেটা, যদিও, বড় স্ক্রীন সহ বেশিরভাগ Pixel XL ব্যবহারকারীদের অন্তর্ভুক্ত করতে পারে, তাই তাদের জন্য স্লো-লোডিং হিরো ইমেজ হল তাদের LCP উপাদান।
এলসিপিতে ক্যাশে অবস্থার প্রভাব
ল্যাব পরীক্ষাগুলি সাধারণত একটি কোল্ড ক্যাশে সহ একটি পৃষ্ঠা লোড করে, কিন্তু যখন প্রকৃত ব্যবহারকারীরা সেই পৃষ্ঠাটি দেখেন তখন তাদের ইতিমধ্যেই এর কিছু সম্পদ ক্যাশে থাকতে পারে।
প্রথমবার যখন কোনো ব্যবহারকারী একটি পৃষ্ঠা লোড করে তখন এটি ধীরে ধীরে লোড হতে পারে, কিন্তু যদি পৃষ্ঠাটির সঠিক ক্যাশিং কনফিগার করা থাকে, পরের বার ব্যবহারকারী যখন পৃষ্ঠাটি ফেরত দেন তখনই লোড হতে পারে৷
যদিও কিছু ল্যাব টুল একই পৃষ্ঠার একাধিক রান সমর্থন করে (ফিরে আসা দর্শকদের অভিজ্ঞতা অনুকরণ করার জন্য), নতুন বনাম ফিরে আসা ব্যবহারকারীদের কাছ থেকে বাস্তব-বিশ্বের কত শতাংশ ভিজিট হয়েছে তা একটি ল্যাব টুলের পক্ষে জানা সম্ভব নয়।
ভাল-অপ্টিমাইজ করা ক্যাশে কনফিগারেশন সহ সাইট এবং প্রচুর পুনরাবৃত্তি দর্শকরা আবিষ্কার করতে পারে যে তাদের বাস্তব-বিশ্বের LCP তাদের ল্যাব ডেটা নির্দেশ করে তার চেয়ে অনেক দ্রুত।
এএমপি বা সাইনড এক্সচেঞ্জ অপ্টিমাইজেশান
এএমপি দিয়ে তৈরি বা সাইনড এক্সচেঞ্জ (SXG) ব্যবহার করে এমন সাইটগুলিকে Google সার্চের মতো কন্টেন্ট অ্যাগ্রিগেটরদের দ্বারা প্রিলোড করা যেতে পারে। এর ফলে সেই প্ল্যাটফর্মগুলি থেকে আপনার পৃষ্ঠাগুলি পরিদর্শনকারী ব্যবহারকারীদের জন্য উল্লেখযোগ্যভাবে ভাল লোড কর্মক্ষমতা হতে পারে।
ক্রস-অরিজিন প্রিলোডিং ছাড়াও, সাইটগুলি নিজেরাই তাদের সাইটে পরবর্তী পৃষ্ঠাগুলির জন্য সামগ্রী প্রিলোড করতে পারে, যা সেই পৃষ্ঠাগুলির জন্য LCP-কেও উন্নত করতে পারে৷
ল্যাব সরঞ্জামগুলি এই অপ্টিমাইজেশানগুলি থেকে দেখা লাভগুলিকে অনুকরণ করে না, এবং এমনকি যদি তারা করেও তবে তারা জানতে পারে না যে অন্যান্য উত্সের তুলনায় Google অনুসন্ধানের মতো প্ল্যাটফর্ম থেকে আপনার ট্র্যাফিকের কত শতাংশ আসে৷
LCP-তে bfcache এর প্রভাব
যখন bfcache থেকে পৃষ্ঠাগুলি পুনরুদ্ধার করা হয়, লোডের অভিজ্ঞতা তাত্ক্ষণিক কাছাকাছি হয় এবং এই অভিজ্ঞতাগুলি আপনার ক্ষেত্রের ডেটাতে অন্তর্ভুক্ত করা হয় ।
ল্যাব পরীক্ষাগুলি bfcache বিবেচনা করে না, তাই যদি আপনার পৃষ্ঠাগুলি bfcache-বান্ধব হয়, তাহলে সম্ভবত এটি ক্ষেত্রে দ্রুত LCP স্কোর রিপোর্ট করা হবে।
এলসিপি-তে ব্যবহারকারীর মিথস্ক্রিয়া প্রভাব
LCP ভিউপোর্টে সবচেয়ে বড় ইমেজ বা টেক্সট ব্লকের রেন্ডার টাইম শনাক্ত করে, কিন্তু পৃষ্ঠাটি লোড হওয়ার সাথে সাথে অথবা নতুন কন্টেন্ট ভিউপোর্টে গতিশীলভাবে যুক্ত হলে সেই বৃহত্তম উপাদানটি পরিবর্তিত হতে পারে।
ল্যাবে, ব্রাউজারটি LCP উপাদানটি কী ছিল তা নির্ধারণ করার আগে পৃষ্ঠাটি সম্পূর্ণ লোড না হওয়া পর্যন্ত অপেক্ষা করবে। কিন্তু ক্ষেত্রটিতে, ব্যবহারকারী স্ক্রল করার পরে বা পৃষ্ঠার সাথে ইন্টারঅ্যাক্ট করার পরে ব্রাউজারটি বৃহত্তর উপাদানগুলির জন্য নিরীক্ষণ বন্ধ করবে।
এটি বোধগম্য (এবং প্রয়োজনীয়) কারণ ব্যবহারকারীরা সাধারণত একটি পৃষ্ঠার সাথে ইন্টারঅ্যাক্ট করার জন্য অপেক্ষা করে যতক্ষণ না এটি "প্রতীয়মান হয়" লোড করা হয়, যা LCP মেট্রিক সনাক্ত করার লক্ষ্য রাখে। ব্যবহারকারীর ইন্টারঅ্যাক্ট করার পরে ভিউপোর্টে যোগ করা উপাদানগুলি বিবেচনা করাও অর্থপূর্ণ হবে না কারণ সেই উপাদানগুলি শুধুমাত্র ব্যবহারকারীর কিছু করার কারণে লোড হয়েছে।
যদিও এর অন্তর্নিহিত অর্থ হল একটি পৃষ্ঠার ফিল্ড ডেটা দ্রুত LCP বার রিপোর্ট করতে পারে, ব্যবহারকারীরা সেই পৃষ্ঠায় কীভাবে আচরণ করে তার উপর নির্ভর করে।
এফআইডি
FID-এর জন্য বাস্তব-ব্যবহারকারীর মিথস্ক্রিয়া প্রয়োজন
FID মেট্রিক পরিমাপ করে যে কোনও পৃষ্ঠা ব্যবহারকারীর ইন্টারঅ্যাকশনের জন্য কতটা প্রতিক্রিয়াশীল, সেই সময়ে যখন ব্যবহারকারীরা প্রকৃতপক্ষে এটির সাথে ইন্টারঅ্যাক্ট করতে বেছে নেন।
এই বাক্যটির দ্বিতীয় অংশটি গুরুত্বপূর্ণ কারণ ল্যাব পরীক্ষা, এমনকি যেগুলি স্ক্রিপ্ট ব্যবহারকারীর আচরণকে সমর্থন করে, তারা সঠিকভাবে ভবিষ্যদ্বাণী করতে পারে না যে ব্যবহারকারীরা কখন একটি পৃষ্ঠার সাথে ইন্টারঅ্যাক্ট করতে বেছে নেবে, এবং এইভাবে FID সঠিকভাবে পরিমাপ করতে পারে না।
TBT ব্যবহারকারীর আচরণ বিবেচনা করে না
টোটাল ব্লকিং টাইম (TBT) ল্যাব মেট্রিক FID এর সমস্যাগুলি নির্ণয় করতে সাহায্য করার উদ্দেশ্যে কারণ এটি পৃষ্ঠা লোডের সময় মূল থ্রেডটি কতটা ব্লক করা হয়েছে তা পরিমাপ করে।
ধারণাটি হল যে প্রচুর সিঙ্ক্রোনাস জাভাস্ক্রিপ্ট বা অন্যান্য নিবিড় রেন্ডারিং কাজ সহ পৃষ্ঠাগুলিতে ব্যবহারকারীর প্রথম ইন্টারঅ্যাক্ট করার সময় একটি ব্লক করা প্রধান থ্রেড থাকার সম্ভাবনা বেশি থাকে। যাইহোক, যদি ব্যবহারকারীরা জাভাস্ক্রিপ্ট কার্যকর করা শেষ না হওয়া পর্যন্ত পৃষ্ঠার সাথে ইন্টারঅ্যাক্ট করার জন্য অপেক্ষা করে, FID খুব কম হতে পারে।
ব্যবহারকারীরা কখন একটি পৃষ্ঠার সাথে ইন্টারঅ্যাক্ট করতে চান তা মূলত এটি ইন্টারেক্টিভ দেখায় কি না তার উপর নির্ভর করে এবং এটি টিবিটি দিয়ে পরিমাপ করা যায় না।
টিবিটি ট্যাপ বিলম্ব বিবেচনা করে না
যদি কোনো সাইট মোবাইলে দেখার জন্য অপ্টিমাইজ করা না হয়, তাহলে ইভেন্ট হ্যান্ডলার চালানোর আগে যেকোনো ট্যাপ করার পরে ব্রাউজারগুলি 300 ms বিলম্ব যোগ করবে। তারা এটি করে কারণ তারা মাউস ফায়ার বা ইভেন্টে ক্লিক করার আগে ব্যবহারকারী জুম করতে ডবল-ট্যাপ করার চেষ্টা করছে কিনা তা নির্ধারণ করতে হবে।
এই বিলম্বটি একটি পৃষ্ঠার FID এর দিকে গণনা করা হয় কারণ এটি ব্যবহারকারীদের অভিজ্ঞতার প্রকৃত ইনপুট লেটেন্সিতে অবদান রাখে। কিন্তু যেহেতু এই বিলম্ব টেকনিক্যালি একটি লং টাস্ক নয়, তাই এটি একটি পৃষ্ঠার TBT-কে প্রভাবিত করে না। এর মানে খুব ভালো TBT স্কোর থাকা সত্ত্বেও একটি পৃষ্ঠার FID খারাপ থাকতে পারে।
FID-তে ক্যাশে স্টেট এবং bfcache-এর প্রভাব
একইভাবে সঠিক ক্যাশিং ক্ষেত্রে এলসিপি উন্নত করতে পারে, এটি এফআইডিও উন্নত করতে পারে।
বাস্তব জগতে, একজন ব্যবহারকারীর কাছে ইতিমধ্যেই তাদের ক্যাশে থাকা একটি সাইটের জন্য জাভাস্ক্রিপ্ট থাকতে পারে, তাই এটি প্রক্রিয়াকরণে কম সময় লাগতে পারে এবং এর ফলে কম বিলম্ব হতে পারে।
bfcache থেকে পুনরুদ্ধার করা পৃষ্ঠাগুলির ক্ষেত্রেও একই কথা প্রযোজ্য। এই ক্ষেত্রে জাভাস্ক্রিপ্ট মেমরি থেকে পুনরুদ্ধার করা হয়, তাই খুব কম বা কোন প্রক্রিয়াকরণ সময় থাকতে পারে।
সিএলএস
CLS-এ ব্যবহারকারীর মিথস্ক্রিয়া প্রভাব
ল্যাবে পরিমাপ করা CLS শুধুমাত্র লেআউট পরিবর্তনগুলি বিবেচনা করে যা ভাঁজের উপরে এবং লোডের সময় ঘটে, কিন্তু এটি CLS আসলে যা পরিমাপ করে তার একটি উপসেট।
ক্ষেত্রে, CLS সমস্ত অপ্রত্যাশিত লেআউট পরিবর্তনগুলি বিবেচনা করে যা পৃষ্ঠার জীবনকাল জুড়ে ঘটে, যার মধ্যে এমন সামগ্রী যা ব্যবহারকারীর স্ক্রোল করার সময় বা ব্যবহারকারীর ইন্টারঅ্যাকশনের পরে ধীর নেটওয়ার্ক অনুরোধের প্রতিক্রিয়া হিসাবে পরিবর্তন হয়।
উদাহরণস্বরূপ, মাত্রা ছাড়াই পৃষ্ঠাগুলি অলস-লোড করা চিত্র বা আইফ্রেমগুলির জন্য খুবই সাধারণ এবং এটি লেআউট পরিবর্তনের কারণ হতে পারে যখন কোনও ব্যবহারকারী পৃষ্ঠার সেই বিভাগে স্ক্রোল করে৷ কিন্তু এই পরিবর্তনগুলি শুধুমাত্র তখনই ঘটতে পারে যখন ব্যবহারকারী নীচে স্ক্রোল করে, যা প্রায়শই ল্যাব পরীক্ষায় ধরা পড়ে না।
ব্যক্তিগতকৃত বিষয়বস্তু
ব্যক্তিগতকৃত সামগ্রী—লক্ষ্যযুক্ত বিজ্ঞাপন এবং A/B পরীক্ষা সহ—একটি পৃষ্ঠায় কী উপাদান লোড করা হয় তা প্রভাবিত করে৷ এটি কীভাবে সেগুলি লোড করা হয় তাও প্রভাবিত করে কারণ ব্যক্তিগতকৃত সামগ্রীগুলি প্রায়শই পরে লোড হয় এবং একটি পৃষ্ঠার প্রধান সামগ্রীতে ঢোকানো হয়, যার ফলে লেআউট পরিবর্তন হয়৷
ল্যাবে, একটি পৃষ্ঠা সাধারণত ব্যক্তিগতকৃত বিষয়বস্তু ছাড়াই লোড করা হয় বা সাধারণ "পরীক্ষাকারী ব্যবহারকারী" এর জন্য সামগ্রী সহ লোড করা হয়, যা প্রকৃত ব্যবহারকারীরা যে পরিবর্তনগুলি দেখছেন তা ট্রিগার করতে পারে বা নাও করতে পারে৷
যেহেতু ফিল্ড ডেটাতে সমস্ত ব্যবহারকারীর অভিজ্ঞতা অন্তর্ভুক্ত থাকে, তাই কোন প্রদত্ত পৃষ্ঠায় লেআউট পরিবর্তনের পরিমাণ (এবং ডিগ্রী) কোন বিষয়বস্তু লোড করা হয়েছে তার উপর নির্ভর করে।
CLS-এ ক্যাশে স্টেট এবং bfcache-এর প্রভাব
লোডের সময় লেআউট পরিবর্তনের দুটি সাধারণ কারণ হল মাত্রা ছাড়াই ছবি এবং আইফ্রেম (উপরে উল্লিখিত) এবং ধীর গতিতে লোডিং ওয়েব ফন্ট , এবং এই দুটি সমস্যাই ব্যবহারকারীর প্রথমবার কোনো সাইট দেখার অভিজ্ঞতাকে প্রভাবিত করার সম্ভাবনা বেশি, যখন তাদের ক্যাশে খালি।
যদি একটি পৃষ্ঠার সংস্থানগুলি ক্যাশে করা হয়, বা যদি পৃষ্ঠাটি নিজেই bfcache থেকে পুনরুদ্ধার করা হয়, ব্রাউজার সাধারণত ছবি এবং ফন্টগুলি ডাউনলোড করার জন্য অপেক্ষা না করে সরাসরি রেন্ডার করতে পারে৷ এটি একটি ল্যাব টুল যা রিপোর্ট করতে পারে তার তুলনায় ক্ষেত্রের CLS মান কম হতে পারে।
ফলাফল ভিন্ন হলে কি করবেন
একটি সাধারণ নিয়ম হিসাবে, যদি আপনার কাছে একটি প্রদত্ত পৃষ্ঠার জন্য ফিল্ড ডেটা এবং ল্যাব ডেটা উভয়ই থাকে, তাহলে ফিল্ড ডেটা হল আপনার প্রচেষ্টাকে অগ্রাধিকার দেওয়ার জন্য যা ব্যবহার করা উচিত৷ যেহেতু ফিল্ড ডেটা প্রকৃত ব্যবহারকারীরা কী অনুভব করছে তা প্রতিনিধিত্ব করে, তাই আপনার ব্যবহারকারীরা কীসের সাথে লড়াই করছে এবং কী উন্নত করা দরকার তা বোঝার সবচেয়ে সঠিক উপায়।
অন্যদিকে, যদি আপনার ফিল্ড ডেটা বোর্ড জুড়ে ভাল স্কোর দেখায়, কিন্তু আপনার ল্যাব ডেটা পরামর্শ দেয় যে উন্নতির জন্য এখনও জায়গা আছে, তাহলে আরও কী অপ্টিমাইজেশন করা যেতে পারে তা বোঝার মতো।
উপরন্তু, যদিও ফিল্ড ডেটা বাস্তব-ব্যবহারকারীর অভিজ্ঞতা ক্যাপচার করে, এটি শুধুমাত্র সেই ব্যবহারকারীদের জন্যই করে যারা সফলভাবে আপনার সাইট লোড করতে সক্ষম । ল্যাব ডেটা কখনও কখনও আপনার সাইটের নাগাল প্রসারিত করার সুযোগগুলি সনাক্ত করতে এবং এটিকে ধীর নেটওয়ার্ক বা নিম্ন-সম্পন্ন ডিভাইসগুলির ব্যবহারকারীদের কাছে আরও অ্যাক্সেসযোগ্য করে তুলতে সহায়তা করতে পারে।
সামগ্রিকভাবে, ল্যাব ডেটা এবং ফিল্ড ডেটা উভয়ই কার্যকর কর্মক্ষমতা পরিমাপের গুরুত্বপূর্ণ অংশ। তাদের উভয়েরই তাদের শক্তি এবং সীমাবদ্ধতা রয়েছে এবং আপনি যদি শুধুমাত্র একটি ব্যবহার করেন তবে আপনি আপনার ব্যবহারকারীদের জন্য অভিজ্ঞতা উন্নত করার একটি সুযোগ মিস করতে পারেন।