এসপিএ, কোর ওয়েব ভাইটাল এবং বর্তমান পরিমাপের সীমাবদ্ধতাগুলি সমাধান করার জন্য Google এর পরিকল্পনা সম্পর্কে সাধারণ প্রশ্নের উত্তর।
2020 সালের মে মাসে প্রথমবার ওয়েব ভাইটাল উদ্যোগটি চালু করার পর থেকে, আমরা Chrome টিমে এই প্রোগ্রাম সম্পর্কে প্রচুর প্রশ্ন এবং প্রতিক্রিয়া পেয়েছি।
সম্ভবত আমরা যে বিষয়ে সবচেয়ে বেশি প্রশ্ন পেয়েছি, যেটির উত্তর দেওয়া সম্ভবত সবচেয়ে কঠিন প্রশ্ন, তা হল কিভাবে একটি একক-পৃষ্ঠা অ্যাপ্লিকেশনে (SPA) কোর ওয়েব ভাইটাল পরিমাপ করা যায়, সেইসাথে কীভাবে SPA আর্কিটেকচারগুলি কোর ওয়েব ভাইটাল স্কোরগুলিকে প্রভাবিত করে .
এই প্রশ্নগুলির উত্তর দেওয়া কঠিন কারণ সমস্যাটি বেশ সূক্ষ্ম, তাই এই পোস্টে আমরা সবচেয়ে সাধারণ প্রশ্নের উত্তর দেওয়ার জন্য আমাদের যথাসাধ্য চেষ্টা করব, যতটা সম্ভব বিস্তারিত এবং প্রসঙ্গ প্রদান করব।
সুনির্দিষ্টভাবে জানার আগে, যদিও, এটা বলা গুরুত্বপূর্ণ যে একটি সাইট তৈরি করতে কী আর্কিটেকচার বা প্রযুক্তি ব্যবহার করা হয় সে বিষয়ে Google-এর কোনো পছন্দ নেই। আমরা বিশ্বাস করি যে এসপিএ এবং মাল্টি-পেজ অ্যাপ্লিকেশন (এমপিএ) উভয়ই ব্যবহারকারীদের কাছে উচ্চ মানের অভিজ্ঞতা প্রদান করতে সক্ষম এবং ওয়েব ভাইটালস উদ্যোগের সাথে আমাদের উদ্দেশ্য হল মেট্রিক্স প্রদান করা যা প্রযুক্তি থেকে স্বাধীন অভিজ্ঞতা পরিমাপ করে। যদিও এটি আজ প্রতিটি ক্ষেত্রে সম্ভব নয় (ওয়েব প্ল্যাটফর্মের সীমাবদ্ধতার কারণে), আমরা সক্রিয়ভাবে সেই ফাঁকগুলি বন্ধ করার জন্য কাজ করছি ৷
সচরাচর জিজ্ঞাস্য
কোর ওয়েব ভাইটাল মেট্রিক্স কি SPA রুট ট্রানজিশন অন্তর্ভুক্ত করে?
না। প্রতিটি কোর ওয়েব ভাইটাল মেট্রিক্স বর্তমান, শীর্ষ-স্তরের পৃষ্ঠা নেভিগেশনের সাপেক্ষে পরিমাপ করা হয়। যদি একটি পৃষ্ঠা গতিশীলভাবে নতুন বিষয়বস্তু লোড করে এবং ঠিকানা বারে পৃষ্ঠার URL আপডেট করে, তাহলে কোর ওয়েব ভাইটাল মেট্রিকগুলি কীভাবে পরিমাপ করা হয় তার উপর এটি কোন প্রভাব ফেলবে না। মেট্রিক মান রিসেট করা হয় না, এবং প্রতিটি মেট্রিক পরিমাপের সাথে যুক্ত URL হল সেই URL যেটিতে ব্যবহারকারী নেভিগেট করে পৃষ্ঠা লোড শুরু করে।
কোর ওয়েব ভাইটালস মেট্রিক্স কি ঐতিহ্যগত পৃষ্ঠা লোডের মতো SPA রুট পরিবর্তন করতে পারে?
দুর্ভাগ্যক্রমে না। যাইহোক এখনও না.
আজ একটি এসপিএ তৈরির কোন প্রমিত উপায় নেই, এমনকি জনপ্রিয় এসপিএ এবং রাউটিং লাইব্রেরিগুলির মধ্যেও ব্যবহারকারীর অভিজ্ঞতা অ্যাপ থেকে অ্যাপে বেশ আলাদা হতে পারে:
- কিছু SPA শুধুমাত্র নতুন "সম্পূর্ণ পৃষ্ঠা" বিষয়বস্তু লোড করার সময় URL আপডেট করে, যেখানে অন্যান্য সাইটগুলি ক্ষুদ্র বিষয়বস্তুর পরিবর্তন বা এমনকি শুধুমাত্র UI অবস্থার পরিবর্তনের জন্য URL আপডেট করে।
- কিছু SPA ইতিহাস API ব্যবহার করে URL আপডেট করে, অন্যরা পুরানো ব্রাউজারগুলিকে সমর্থন করার জন্য হ্যাশ পরিবর্তন ব্যবহার করে (এবং অন্যরা একেবারেই URL আপডেট করে না)।
- কিছু SPA কন্টেন্ট লোড করে তারপর URL আপডেট করে, অন্যরা কন্টেন্ট লোড করার আগে URL আপডেট করে।
- কিছু SPA একক জাভাস্ক্রিপ্ট টাস্কে একযোগে, সিঙ্ক্রোনাসভাবে কন্টেন্ট লোড করে, যেখানে অন্যরা একাধিক টাস্ক জুড়ে (কোনও স্পষ্ট ট্রানজিশন শেষ ইভেন্ট ছাড়াই) কনটেন্ট ট্রানজিশন করে, অ্যাসিঙ্ক্রোনাসভাবে।
- কিছু SPA সর্বদা নেটওয়ার্ক থেকে বিষয়বস্তু লোড করে, যেখানে অন্যরা সমস্ত সামগ্রী অগ্রিম লোড করে যাতে রুট মেমরি থেকে তাৎক্ষণিকভাবে লোড হয়ে যায়।
এই পার্থক্যগুলি একটি SPA রুট পরিবর্তন, বা এমনকি একটি SPA নিজেই, যা স্কেলে করা খুব কঠিন তা সংজ্ঞায়িত করা এবং সনাক্ত করা।
কিছু ক্ষেত্রে একটি SPA রুট পরিবর্তন যৌক্তিকভাবে MPA পৃষ্ঠা লোডের সাথে অভিন্ন এবং এই ধরনের ক্ষেত্রে বিদ্যমান কোর ওয়েব ভাইটাল মেট্রিক্স প্রয়োগ করা গেলে এটি দুর্দান্ত হবে।
যাইহোক, অন্যান্য সমস্ত ইউআরএল পরিবর্তন থেকে "বাস্তব" রুট পরিবর্তনগুলিকে নির্ভরযোগ্যভাবে সনাক্ত করার জন্য দৃঢ় হিউরিস্টিকস ছাড়াই - সেইসাথে এই ধরনের ট্রানজিশনের শুরু এবং শেষ চিহ্নিতকারী স্পষ্ট সংকেতগুলি - এই ক্ষেত্রে কোর ওয়েব ভাইটাল মেট্রিক্স রিপোর্ট করা ডেটাকে মলিন করবে এবং এটি কম উপযোগী করে তুলবে। অথবা সাইটে প্রকৃত ব্যবহারকারীর অভিজ্ঞতার প্রতিনিধি।
কোর ওয়েব ভাইটালগুলিতে এমপিএগুলির চেয়ে এসপিএগুলির পক্ষে ভাল করা কি কঠিন?
এসপিএ আর্কিটেকচারে এমন কিছু নেই যা একটি এসপিএ-তে একটি পৃষ্ঠাকে যত দ্রুত লোড হতে বাধা দেবে—এবং সমস্ত কোর ওয়েব ভাইটাল মেট্রিক্সে ঠিক একইভাবে স্কোর করতে পারবে—এমপিএ-তে একই পৃষ্ঠার মতো।
যাইহোক, সঠিকভাবে অপ্টিমাইজ করা এমপিএগুলির কোর ওয়েব ভাইটাল থ্রেশহোল্ডগুলি পূরণ করার ক্ষেত্রে কিছু সুবিধা রয়েছে যা SPAগুলি বর্তমানে করে না৷ কারণ হল MPA আর্কিটেকচারের সাথে, প্রতিটি "পৃষ্ঠা" একটি পূর্ণ-পৃষ্ঠা নেভিগেশন হিসাবে লোড হয় (গতিশীলভাবে বিষয়বস্তু আনয়ন করা এবং এটি বিদ্যমান পৃষ্ঠায় ঢোকানোর পরিবর্তে), যার মানে যে ব্যবহারকারীরা MPA পরিদর্শন করেন তাদের লোড হওয়ার সম্ভাবনা বেশি। সাইট থেকে একটি পৃষ্ঠা, যার মানে হল একটি MPA-এর জন্য সমস্ত পৃষ্ঠা লোডের বিতরণের একটি বড় শতাংশের মধ্যে কিছু বা সমস্ত সাব-রিসোর্স ক্যাশে করা হবে।
এটা ঠিক যে, একটি MPA-এর জন্য SPA-এর তুলনায় কোর ওয়েব ভাইটাল মেট্রিক্সে আরও ভাল পারফর্ম করার জন্য কিছু জিনিস সত্য হওয়া প্রয়োজন:
- MPA-এর অপ্টিমাইজ করা সাব-রিসোর্স ক্যাশিং থাকা দরকার যাতে নিশ্চিত করা যায় যে একই-অরিজিন পৃষ্ঠা লোডগুলি 75 তম শতাংশে ক্রস-অরিজিন পৃষ্ঠা লোডের চেয়ে দ্রুততর হয়।
- যেসব ব্যবহারকারী এমপিএ পরিদর্শন করেন তাদের একাধিক পৃষ্ঠা পরিদর্শন করতে হবে যাতে সাইট ক্যাশিং সুবিধা পেতে পারে যার ফলে দ্রুত পৃষ্ঠা লোড হয়।
যেহেতু কোর ওয়েব ভাইটাল মূল্যায়ন পৃষ্ঠা পরিদর্শনের 75 তম পার্সেন্টাইল বিবেচনা করে , তাই ডেটাসেটে আরও বেশি, ভাল-পারফর্মিং পৃষ্ঠা ভিজিটগুলি বিতরণের 75 তম শতাংশে পরিদর্শন প্রস্তাবিত থ্রেশহোল্ডের মধ্যে হওয়ার সম্ভাবনা বাড়িয়ে তুলবে৷
মনে রাখবেন যে কোর ওয়েব ভাইটাল স্কোর তুলনা করার সময় বিবেচনা করা একটি গুরুত্বপূর্ণ বিষয় হল ডেটা কীভাবে একত্রিত হয়—অর্থাৎ, বিতরণের ডেটাসেটে আপনার সাইট বা মূলের সমস্ত পৃষ্ঠা অন্তর্ভুক্ত আছে কিনা, বা শুধুমাত্র একটি নির্দিষ্ট পৃষ্ঠার URL-এর জন্য পৃষ্ঠা লোড হচ্ছে।
একটি মূলের সমস্ত পৃষ্ঠার স্কোর একত্রিত করার সময়, স্বতন্ত্র দ্রুত পৃষ্ঠাগুলি সম্পূর্ণরূপে উত্সের জন্য 75 তম পার্সেন্টাইল উন্নত করতে পারে। যাইহোক, পৃথক পৃষ্ঠাগুলির দ্বারা একত্রিত করার সময়, একটি পৃষ্ঠার স্কোর পরবর্তী স্কোরগুলিকে প্রভাবিত করবে না। অন্য কথায়, পৃষ্ঠা অনুসারে একটি MPA-এর স্কোর একত্রিত করার সময়, চেকআউট পৃষ্ঠায় দেখা দ্রুত ক্যাশে লোড সাইটের ল্যান্ডিং পৃষ্ঠায় অভিজ্ঞ ধীর প্রাথমিক লোডের স্কোরকে উন্নত করবে না ।
আপনি PageSpeed Insights বা Chrome User Experience Report API ব্যবহার করে বিভিন্ন একত্রীকরণ পদ্ধতির জন্য আপনার সাইটের স্কোর পরীক্ষা করতে পারেন, যা পৃথক পৃষ্ঠার URL এবং সমগ্র উৎস উভয়ের জন্যই স্কোর রিপোর্ট করে।
SPA আর্কিটেকচার কোর ওয়েব ভাইটাল স্কোরকে প্রভাবিত করতে পারে এমন আরেকটি উপায় হল মেট্রিক্সের জন্য যা একটি পৃষ্ঠার সম্পূর্ণ জীবনকাল বিবেচনা করে। যেহেতু এসপিএ পরিদর্শনকারী ব্যবহারকারীরা পুরো সেশনের জন্য একই "পৃষ্ঠায়" থাকার প্রবণতা রাখে, তাই সময়ের সাথে জমা হওয়া মেট্রিকগুলি এমপিএগুলির তুলনায় এসপিএগুলিতে কঠোর হতে পারে৷
এপ্রিল 2021-এ, আমরা CLS মেট্রিকের পরিবর্তনগুলি ঘোষণা করেছি যা আংশিকভাবে এই সমস্যার সমাধান করেছে। পূর্বে সিএলএস সমগ্র পৃষ্ঠার আয়ুষ্কাল জুড়ে জমা হত, যেখানে এখন এটি শুধুমাত্র একটি নির্দিষ্ট উইন্ডোতে জমা হয় - মূলত একটি প্রদত্ত পৃষ্ঠায় লেআউট পরিবর্তনের সবচেয়ে খারাপ বিস্ফোরণ।
যাইহোক, নতুন CLS সংজ্ঞার সাথেও, SPAগুলি এখনও একটি অসুবিধার মধ্যে রয়েছে কারণ CLS মানটি একটি রুট ট্রানজিশনের পরে "রিসেট" হয় না যেমন এটি একটি MPA-তে সম্পূর্ণ পৃষ্ঠা লোডের সাথে করে। এটি বিভ্রান্তির দিকেও যেতে পারে কারণ একটি রুট ট্রানজিশনের পরে ঘটে যাওয়া লেআউট শিফটগুলি পৃষ্ঠার URL লোড করার সময় দায়ী করা হবে, শিফটের সময় ঠিকানা বারে URL নয় ( নীচে আরও বিশদ বিবরণ )৷
যদি SPA আর্কিটেকচারগুলি ব্যবহারকারীর অভিজ্ঞতাকে উন্নত করে, তবে সেই উন্নতি কি মেট্রিক্সে প্রতিফলিত হওয়া উচিত নয়?
হ্যাঁ, এটা উচিত. যদিও পূর্বে উল্লিখিত হয়েছে, বর্তমানে ওয়েবে SPA গুলি যেভাবে প্রয়োগ করা হয় সেগুলির পরিপ্রেক্ষিতে, অভিজ্ঞতা কতটা উন্নত হয়েছে তা পরিমাপ করা স্কেলে করা কঠিন।
সত্য হল ওয়েব পারফরম্যান্স ইন্ডাস্ট্রি (গুগল অন্তর্ভুক্ত) ঐতিহাসিকভাবে একটি পৃষ্ঠার পোস্ট-লোড পারফরম্যান্সের জন্য ব্যবহারকারী-কেন্দ্রিক মেট্রিক্স বিকাশে প্রায় ততটা সময় এবং প্রচেষ্টা বিনিয়োগ করেনি যতটা পৃষ্ঠা লোডের জন্য রয়েছে। এটি এই কারণে নয় যে পোস্ট-লোড পারফরম্যান্স গুরুত্বপূর্ণ নয়, এটি কারণ পোস্ট-লোড ইউএক্স এবং মিথস্ক্রিয়াগুলি অনেক বেশি বৈচিত্র্যময় এবং কম সু-সংজ্ঞায়িত—তাদের জন্য মেট্রিক্স ডিজাইন করা কঠিন করে তোলে।
কিন্তু SPA পারফরম্যান্স পরিমাপ করার জন্য আমাদের কাছে লোড-পরবর্তী মেট্রিক্স ভালোভাবে সংজ্ঞায়িত থাকলেও, আমরা লোডের অভিজ্ঞতা উপেক্ষা করতে চাই না কারণ পোস্ট লোড অভিজ্ঞতা আরও ভালো হয়েছে।
ওয়েব ভাইটালস উদ্যোগের অন্যতম লক্ষ্য হল ওয়েব পেজ লোড করার এবং ব্যবহার করার বিভিন্ন দিক জুড়ে ভাল ব্যবহারকারীর অভিজ্ঞতাকে প্রচার করা এবং উৎসাহিত করা। আমরা এমন পরিস্থিতিতে উত্সাহিত করতে চাই না যেখানে খারাপ অভিজ্ঞতাগুলি যুক্তিযুক্ত হয় যদি আপনি সেগুলির জন্য যথেষ্ট ভাল অভিজ্ঞতা পেতে পারেন। ব্যবহারকারীরা চান পৃষ্ঠাগুলি দ্রুত লোড হোক এবং দ্রুত নতুন সামগ্রীতে রূপান্তরিত হোক, এবং আমরা সেই ধরনের অভিজ্ঞতার অনুকূল মেট্রিক ডিজাইন করার চেষ্টা করেছি৷
তাই যদিও এটি সত্য যে একটি সাইটের এমপিএ সংস্করণ কোর ওয়েব ভাইটালস মেট্রিক্সে 75 তম পার্সেন্টাইলে সঠিক একই সাইটের একটি SPA সংস্করণের তুলনায় ভাল হতে পারে, SPA সংস্করণটি এখনও "ভাল" থ্রেশহোল্ড পূরণ করার জন্য প্রচেষ্টা করা উচিত। যদি SPA সংস্করণটি বেশিরভাগ ব্যবহারকারীর জন্য "ভাল" থ্রেশহোল্ড পূরণ না করে, তাহলে প্রাথমিক লোড অভিজ্ঞতা সম্ভবত এখনও ভাল হিসাবে অনুভূত হয় না—এমনকি যদি পরবর্তী, ইন-পেজ নেভিগেশন অভিজ্ঞতা চমৎকার হয়।
ভবিষ্যতে আমরা এমন মেট্রিক্স তৈরি করার পরিকল্পনা করি যা দুর্দান্ত, লোড-পরবর্তী অভিজ্ঞতাকে উত্সাহিত করে এবং আমরা বিশ্বাস করি যে এটি প্রাথমিক লোড অভিজ্ঞতার সাথে আপস না করে এমনভাবে উচ্চ-মানের SPA-কে উৎসাহিত করার সর্বোত্তম পথ। আমরা ইতিমধ্যেই ইন্টারঅ্যাকশন টু নেক্সট পেইন্ট (INP) নামে একটি নতুন মেট্রিক সরবরাহ করেছি যা সমগ্র পৃষ্ঠার জীবনচক্র জুড়ে ইন্টারঅ্যাকশন লেটেন্সি পরিমাপ করে, এবং আমরা সক্রিয়ভাবে অন্যান্য পোস্ট-লোড মেট্রিক্সের সাথেও কাজ করছি, যার মধ্যে মেট্রিকগুলি রয়েছে যা SPA রুট ট্রানজিশন পরিমাপ করে ( নীচে দেখুন )
আমরা আমাদের সাইটকে এমপিএ থেকে একটি এসপিএ-তে পরিবর্তন করেছি এবং আমাদের স্কোর ফিরে গেছে। যে প্রত্যাশিত?
এটা নির্ভর করে। একটি বড় আর্কিটেকচার মাইগ্রেশনের পরে আপনার স্কোর পরিবর্তন হতে পারে এমন অনেকগুলি কারণ রয়েছে, তবে উষ্ণ ক্যাশে লোডের সংখ্যা হ্রাস কিছু পরিবর্তনের জন্য দায়ী হতে পারে।
চেক করার একটি দ্রুত উপায় হল Lighthouse এর সাথে আপনার ল্যান্ডিং পৃষ্ঠাগুলির একটি MPA এবং SPA উভয় সংস্করণ পরীক্ষা করা। SPA সংস্করণের জন্য যেকোনও কোর ওয়েব ভাইটাল মেট্রিকে লাইটহাউস স্কোর কম হলে, আপডেটের পরে লোড অভিজ্ঞতা আরও খারাপ হওয়ার সম্ভাবনা রয়েছে।
কোর ওয়েব ভাইটালগুলিতে আরও ভাল স্কোর করতে আমার কি আমার সাইটকে একটি SPA থেকে MPA-তে পরিবর্তন করা উচিত?
সম্ভবত না। যদি আপনি আপনার SPA স্ট্যাকের সাথে খুশি না হন এবং আপনার বিশ্বাস করার কারণ থাকে যে একটি MPA একটি ভাল ব্যবহারকারীর অভিজ্ঞতা প্রদান করবে তবেই আপনাকে একটি SPA থেকে MPA-তে পরিবর্তন করতে হবে৷
সময়ের সাথে সাথে, যেহেতু Core Web Vitals মেট্রিক্স উন্নত হয় এবং সম্পূর্ণ ব্রাউজিং অভিজ্ঞতাকে কভার করে, ভালভাবে নির্মিত SPA সহ যে দলগুলি দুর্দান্ত UX প্রদান করে তাদের কোর ওয়েব ভাইটাল স্কোরগুলি তা প্রতিফলিত করার আশা করা উচিত।
যদি কোর ওয়েব ভাইটাল স্কোরগুলি শুধুমাত্র একটি SPA-এর ল্যান্ডিং পৃষ্ঠাগুলির জন্য রিপোর্ট করা হয়, তাহলে আমি কীভাবে একটি রুট ট্রানজিশনের পরে "পৃষ্ঠাগুলিতে" হওয়া সমস্যাগুলি ডিবাগ করতে পারি?
কোর ওয়েব ভাইটাল মেট্রিক (যেমন সার্চ কনসোল এবং পেজস্পিড ইনসাইট) এর ফিল্ড ডেটা রিপোর্ট করে এমন Google টুলগুলি Chrome ব্যবহারকারীর অভিজ্ঞতা রিপোর্ট (CrUX) থেকে তাদের ডেটা পায়। এবং CrUX উৎপত্তি বা পৃষ্ঠা URL দ্বারা ডেটা একত্রিত করে (অর্থাৎ, লোডের সময় পৃষ্ঠা URL)।
উপরে তালিকাভুক্ত সমস্ত কারণের জন্য, CrUX SPA রুট দ্বারা ডেটা একত্রিত করতে সক্ষম নয়। যাইহোক, আপনার নিজের আর্কিটেকচারের সাথে পরিচিত একজন সাইটের মালিক হিসাবে, এটি নিজেই পরিমাপ করা সম্ভব, এবং অনেক বিশ্লেষণ সরঞ্জাম আপনাকে SPA রুট পরিবর্তনের সময় সংকেত দেওয়ার অনুমতি দেয় এবং তারা সেই অনুযায়ী আপনার পরিমাপের ডেটা আপডেট করে।
একটি বিশ্লেষণ টুল দিয়ে ওয়েব ভাইটাল মেট্রিক্স পরিমাপ করার সময়, নিশ্চিত করুন যে আপনি বর্তমান রুট URL এবং মূল পৃষ্ঠার URL উভয়ই পরিমাপ করছেন৷ এটি আপনাকে পৃষ্ঠার লাইফসাইকেল জুড়ে ঘটে যাওয়া পৃথক সমস্যাগুলি ডিবাগ করার পাশাপাশি মূল পৃষ্ঠার URL দ্বারা একত্রিত করার অনুমতি দেবে যাতে Google টুলগুলি মেট্রিক্সে কীভাবে পরিমাপ করে এবং রিপোর্ট করে।
এই বিষয়ে আরও বিশদ এবং সর্বোত্তম অনুশীলনের জন্য, দেখুন: ক্ষেত্রের ডিবাগ কর্মক্ষমতা ।
SPA-এর তুলনায় MPA-এর অন্যায্য সুবিধা নেই তা নিশ্চিত করতে Google কী করছে?
উপরে উল্লিখিত হিসাবে, একটি সঠিকভাবে-অপ্টিমাইজ করা MPA, কিছু ক্ষেত্রে, 75 তম পার্সেন্টাইলে আরও ভাল ওয়েব ভাইটাল স্কোর রিপোর্ট করতে পারে কারণ এটিতে ক্যাশে করা পৃষ্ঠা ভিজিটগুলির একটি উচ্চ শতাংশ থাকবে। বিপরীতভাবে, সঠিকভাবে-অপ্টিমাইজ করা এসপিএ-তে ব্যবহারকারীর অভিজ্ঞতার প্রকৃত উন্নতিগুলি বর্তমানে কোর ওয়েব ভাইটাল মেট্রিক্সের কোনও দ্বারা ধরা হচ্ছে না।
Google-এ, আমরা স্বীকার করি যে এটি এমন প্রণোদনা তৈরি করে যা ওয়েব ভাইটালস উদ্যোগের লক্ষ্যগুলির সাথে সম্পূর্ণভাবে সারিবদ্ধ নয় এবং আমরা সক্রিয়ভাবে এটি ঠিক করার উপায়গুলি খুঁজছি। বর্তমানে, আমরা দুটি সম্ভাব্য সমাধান অন্বেষণ করছি, একটি স্বল্পমেয়াদী এবং একটি দীর্ঘমেয়াদী:
- ক্রস-অরিজিন এবং একই-অরিজিন পেজ ভিজিট আলাদাভাবে মূল্যায়ন করুন।
- নতুন API গুলি ডিজাইন করুন যা আরও ভাল SPA পরিমাপ সক্ষম করে৷
ক্রস-অরিজিন এবং একই-অরিজিন পেজ ভিজিট আলাদাভাবে মূল্যায়ন করুন
আজ কোর ওয়েব ভাইটাল মেট্রিক্স সমস্ত পৃষ্ঠা ভিজিটকে একটি একক বালতিতে একত্রিত করে—এগুলি নতুন বনাম রিটার্নিং ভিজিট বা ল্যান্ডিং পৃষ্ঠা বনাম চেকআউট পৃষ্ঠা বা অন্য যেকোন একত্রীকরণ প্রকারের মধ্যে পার্থক্য করে না যেখানে ক্যাশ স্টেট কর্মক্ষমতার উপর প্রভাব ফেলতে পারে।
SPA এবং MPA পারফরম্যান্সের মধ্যে পার্থক্যকে স্বাভাবিক করার একটি উপায় হল বিভিন্ন ধরনের ভিজিটের ক্ষেত্রে ভিন্ন ভিন্ন ওজন প্রয়োগ করা, সম্ভাব্য এমনকি সম্পূর্ণ ভিন্ন থ্রেশহোল্ড সুপারিশের সাথেও।
যদিও আমরা অবশ্যই কার্যকর ক্যাশে বাস্তবায়নকে পুরস্কৃত করতে চাই, আমরা চাই না যে দ্রুত ইন্ট্রা-সাইট নেভিগেশনগুলি ধীর ল্যান্ডিং পৃষ্ঠা লোডের জন্য কভার করতে সক্ষম হোক। আমরা শুধু মেট্রিক স্কোর উন্নত করার জন্য দীর্ঘ পৃষ্ঠাগুলিকে ছোট পৃষ্ঠাগুলির সংগ্রহে বিভক্ত করার জন্য সাইটগুলিকে উৎসাহিত করতে চাই না৷
পৃথকভাবে ক্রস-অরিজিন এবং একই-অরিজিন পৃষ্ঠা ভিজিট মূল্যায়ন করে আমরা নিশ্চিত করতে সাহায্য করতে পারি যে প্রদত্ত সাইটে এক ধরনের আপেক্ষিক জনপ্রিয়তাকে কোনো নির্দিষ্ট মেট্রিকের বন্টনে বাধা না দিয়ে উভয় ধরনের অভিজ্ঞতাই গুরুত্বপূর্ণ।
নতুন API গুলি ডিজাইন করুন যা আরও ভাল SPA পরিমাপ সক্ষম করে৷
আরেকটি সমাধান যা সক্রিয়ভাবে কাজ করা হচ্ছে (উপরের সমান্তরালে) একটি নতুন অ্যাপ হিস্ট্রি এপিআই , যা বর্তমান এসপিএ প্যাটার্নকে মানসম্মত করতে সাহায্য করবে এবং স্কেলে এসপিএ ব্যবহার পরিমাপ ও বোঝা সহজ করে তুলবে।
অ্যাপ হিস্ট্রি এপিআই একটি নতুন navigate ইভেন্ট প্রবর্তন করে, যার দুটি মূল বৈশিষ্ট্য রয়েছে SPA পরিমাপের জন্য নির্দিষ্ট:
- একটি
userInitiatedপতাকা, যা শুধুমাত্র সত্য হিসাবে সেট করা হবে যদি একটি লিঙ্ক ক্লিক, ফর্ম জমা বা ব্রাউজারের পিছনে বা ফরোয়ার্ড UI এর মাধ্যমে নেভিগেশন শুরু করা হয়। - একটি
transitionWhile()পদ্ধতি, যা একটি প্রতিশ্রুতি নেয় যা বিকাশকারীকে সংকেত দেওয়ার অনুমতি দেয় যখন তারা নেভিগেশন সম্পাদনের জন্য শুরু করেছে কাজটি সম্পূর্ণ হয়।
userInitiated পতাকাটি একটি SPA রুট ট্রানজিশনের জন্য একটি শব্দার্থিক সূচনা পয়েন্ট নির্ধারণ করতে ব্যবহার করা যেতে পারে, স্পষ্ট ব্যবহারকারীর অভিপ্রায় নির্দেশ করে। transitionWhile() প্রতিশ্রুতি মীমাংসা ব্রাউজারকে নির্দিষ্ট রুট ট্রানজিশনের সাথে পেইন্টগুলিকে সম্পর্কযুক্ত করতে সাহায্য করতে পারে, যেমন এটি সেই ট্রানজিশনের সাথে সম্পর্কিত সবচেয়ে বড় বিষয়বস্তু পেইন্ট নির্ধারণ করতে সক্ষম হতে পারে।
পূর্ববর্তী বিভাগে উপস্থাপিত ধারণার উপরে বিল্ডিং, এটি একটি এমপিএ-তে একই-অরিজিন পৃষ্ঠা লোড হওয়ার মতো একই বালতিতে SPA রুট ট্রানজিশন সময়কে একত্রিত করাও সম্ভব হতে পারে। এটি উত্তেজনাপূর্ণ কারণ এটি একটি এমপিএ থেকে একটি SPA তে স্থানান্তরিত একটি সাইটকে প্রকৃতপক্ষে আগে এবং পরে কার্যক্ষমতা তুলনা করার অনুমতি দেবে৷
অবশ্যই, আমরা এই সিদ্ধান্তগুলি সঠিকভাবে করতে পারি কিনা তা জানার আগে আরও গবেষণা প্রয়োজন। এই প্রস্তাবগুলিতে আপনার যদি পরামর্শ বা প্রতিক্রিয়া থাকে, অনুগ্রহ করে web-vitals-feedback@googlegroups.com ইমেল করুন।
সর্বশেষ ভাবনা
Google Web Vitals মেট্রিক্স উন্নত করতে এবং ব্যবহারকারীদের জন্য গুরুত্বপূর্ণ উচ্চ-মানের অভিজ্ঞতা পরিমাপ ও উৎসাহিত করার বিষয়টি নিশ্চিত করতে গভীরভাবে প্রতিশ্রুতিবদ্ধ। বলা হচ্ছে, আমরা স্বীকার করি যে পরিমাপের ফাঁক আজ বিদ্যমান। মেট্রিক্স বর্তমানে ব্যবহারকারীর অভিজ্ঞতার প্রতিটি দিককে কভার করে না, তবে আমরা এই ফাঁকগুলি বন্ধ করার জন্য সক্রিয়ভাবে কাজ করছি।
বর্তমান সীমাবদ্ধতা সত্ত্বেও, আমরা বিশ্বাস করি যে বিদ্যমান মেট্রিক্সগুলি যে ক্ষেত্রগুলি ক্যাপচার করে তা ওয়েবের স্বাস্থ্য এবং সাফল্যের জন্য গুরুত্বপূর্ণ এবং সাইটগুলি (স্থাপত্য নির্বিশেষে) প্রস্তাবিত থ্রেশহোল্ডগুলি পূরণ করে না, আমরা বিশ্বাস করি যে উন্নতির জন্য জায়গা রয়েছে .
আমি আশা করি এই পোস্টটি এই জটিল এবং সংক্ষিপ্ত বিষয়ে কিছু আলোকপাত করতে সাহায্য করেছে। বরাবরের মতো, যদি আপনার বর্তমান বা ভবিষ্যতের ওয়েব ভাইটাল মেট্রিক্স সম্পর্কে প্রতিক্রিয়া থাকে, তাহলে অনুগ্রহ করে web-vitals-feedback@googlegroups.com এ ইমেল করুন।