ওয়েবসাইট খুলতে দেরি হলে পাঠক প্রথমে কী করেন? অনেক পাঠক অপেক্ষা না করে পিছনে চলে যেতে পারেন, বিশেষ করে মোবাইল ইন্টারনেটে। ধীর পৃষ্ঠা শুধু বিরক্তি তৈরি করে না; পড়া, কেনাকাটা, যোগাযোগ বা ফর্ম পূরণের মতো কাজও কঠিন করে। তাই গতি মানে শুধু কোনো পরীক্ষার স্কোর নয়—এটি দর্শকের সময়, ডেটা খরচ এবং আস্থার বিষয়। এই গাইডে অল্প প্রযুক্তিগত জ্ঞান থাকা বাংলাদেশি ব্লগ বা ব্যবসার সাইট-মালিকরা ধাপে ধাপে সমস্যা খুঁজে বাস্তবসম্মত উন্নতি করতে পারবেন।
আগে বুঝুন: Core Web Vitals কী
Google-এর Web Vitals নির্দেশিকা ওয়েব অভিজ্ঞতার গুরুত্বপূর্ণ দিক মাপতে তিনটি Core Web Vitals ব্যবহার করে। LCP (Largest Contentful Paint) মাপে প্রধান দৃশ্যমান কনটেন্ট—সাধারণত বড় শিরোনাম, হিরো ছবি বা পণ্যের ছবি—কত দ্রুত দেখা যায়। ভালো লক্ষ্য হলো পৃষ্ঠা লোড শুরুর ২.৫ সেকেন্ডের মধ্যে LCP। INP (Interaction to Next Paint) মাপে ব্যবহারকারী ক্লিক, ট্যাপ বা টাইপ করার পর পরের দৃশ্যমান আপডেট কত দ্রুত আসে; ভালো মান ২০০ মিলিসেকেন্ড বা কম। CLS (Cumulative Layout Shift) মাপে লোডের সময় কনটেন্ট অপ্রত্যাশিতভাবে সরে যায় কি না; ভালো মান ০.১ বা কম।
এগুলো আলাদা সমস্যার ছবি দেয়: LCP হলো লোডিং, INP হলো প্রতিক্রিয়াশীলতা, আর CLS হলো স্থিরতা। তিনটির ফলই সাধারণত ব্যবহারকারীর বাস্তব ভিজিটের ৭৫তম পার্সেন্টাইলে, মোবাইল ও ডেস্কটপ আলাদা করে, দেখা হয়। অর্থাৎ ৭৫ শতাংশ ভিজিট ভালো সীমার মধ্যে থাকলে অভিজ্ঞতাকে ভালো বলা যায়। গড় সময় দেখলেই হবে না—কয়েকটি খুব ধীর মোবাইল ভিজিট গড়ে লুকিয়ে যেতে পারে। বিস্তারিত ব্যাখ্যা Google Search-এর Core Web Vitals পাতা-তেও আছে।
কেন সাইট ধীর হয়
প্রথম কারণ সার্ভার। কম ক্ষমতার হোস্টিং, দূরের ডেটা সেন্টার, ধীর ডেটাবেস বা অতিরিক্ত প্লাগইন HTML পাঠাতে দেরি করায়। একে TTFB বা প্রথম বাইট আসার সময় দিয়ে বোঝা যায়। দ্বিতীয় কারণ বড় সম্পদ: মোবাইলে দরকার নেই এমন ৩০০০ পিক্সেলের ছবি, অপ্রয়োজনীয় ভিডিও, ভারী ফন্ট এবং বিজ্ঞাপনের স্ক্রিপ্ট। তৃতীয় কারণ ব্রাউজারের কাজ—অনেক JavaScript ডাউনলোড, পার্স ও চালাতে গিয়ে মূল থ্রেড আটকে রাখে; এতে ক্লিকের উত্তর দেরি হয় এবং INP খারাপ হয়।
আরেকটি সাধারণ সমস্যা হলো নকশা পরে বদলানো। বিজ্ঞাপন, এমবেড, ব্যানার বা ছবির জন্য জায়গা আগে ঠিক না থাকলে কনটেন্ট লোড হওয়ার সময় নিচে সরে যায়, অর্থাৎ CLS বাড়ে। আবার ক্যাশ না থাকলে একই CSS, JavaScript ও ছবি প্রতিটি ভিজিটে নতুন করে নামাতে হয়। রিডাইরেক্টের শৃঙ্খল, অকারণ ট্র্যাকার, সামাজিক মাধ্যমের উইজেট এবং একসঙ্গে বহু থার্ড-পার্টি ট্যাগও বাধা সৃষ্টি করে। সমস্যার ধরন না জেনে শুধু প্লাগইন ইনস্টল করলে কখনও গতি কমেও যেতে পারে।
প্রথমে মাপুন, অনুমান করবেন না
একটি পৃষ্ঠা বেছে PageSpeed Insights-এ URL দিন। এটি সাধারণত পরীক্ষাগারের Lighthouse ফলের পাশাপাশি Chrome User Experience Report বা CrUX থেকে পাওয়া ফিল্ড ডেটা দেখায়, যদি পর্যাপ্ত বাস্তব ডেটা থাকে। ‘Field’ মানে বিভিন্ন ডিভাইস, নেটওয়ার্ক ও ব্যবহার-পদ্ধতিতে বাস্তব মানুষের অভিজ্ঞতা; ‘Lab’ মানে নির্দিষ্ট পরীক্ষামূলক ডিভাইস ও নেটওয়ার্কে পুনরুৎপাদিত পরীক্ষা। ল্যাব ফল দ্রুত পরিবর্তন পরীক্ষা ও ডিবাগিংয়ের জন্য দারুণ, কিন্তু বাস্তব ভিজিটের সম্পূর্ণ বিকল্প নয়।
PageSpeed-এ মোবাইল ও ডেস্কটপ ট্যাব আলাদা দেখুন। LCP-র উপাদান, render-blocking resource, দীর্ঘ JavaScript task এবং layout shift-এর কারণ চিহ্নিত করতে Diagnostics ও Opportunities পড়ুন। একই URL কয়েকবার চালালে ভিন্ন ফল আসতে পারে—সার্ভার লোড, নেটওয়ার্ক, বিজ্ঞাপন এবং পরীক্ষার অবস্থার কারণে। Score-কে লক্ষ্য না বানিয়ে কোন পরিবর্তন ব্যবহারকারীর অভিজ্ঞতা ভালো করবে তা লিখে রাখুন।
Search Console-এর Core Web Vitals report-এ সাইটের বিভিন্ন URL-এর দলগত বাস্তব অবস্থা দেখুন। ‘Poor’ বা ‘Needs improvement’ গোষ্ঠীর কয়েকটি উদাহরণ URL খুলে একই টেমপ্লেট বা উপাদান আছে কি না মিলিয়ে দেখুন। নতুন সাইট বা কম ভিজিটে CrUX ডেটা নাও থাকতে পারে; তখন নিজের RUM (Real User Monitoring) বা web-vitals লাইব্রেরি দিয়ে ডেটা সংগ্রহ করা যায়। ৭৫তম পার্সেন্টাইল, মোবাইল-ডেস্কটপ এবং ভালো-মাঝারি-খারাপ স্তর—এই তিনটি একসঙ্গে দেখাই বেশি অর্থবহ।
LCP ভালো করার বাস্তব পদক্ষেপ
প্রথমে মোবাইল স্ক্রিনে প্রথম যে বড় কনটেন্ট দেখা যায় সেটি শনাক্ত করুন। সেটি ছবি হলে সঠিক মাপের সংস্করণ দিন: ফোনের পর্দার CSS প্রস্থ, ছবির প্রদর্শিত মাপ ও device pixel ratio মিলিয়ে সংস্করণ বাছুন; সবার কাছে অকারণে একই বিশাল ফাইল পাঠাবেন না। width ও height নির্দিষ্ট করে অনুপাত ঠিক রাখুন। JPEG বা WebP ছবি-নির্ভর ছবির জন্য, PNG স্বচ্ছতা দরকার হলে, এবং আধুনিক ব্রাউজারে AVIF ছোট হতে পারে—তবে আগে কয়েকটি ডিভাইসে লেখা ও মান যাচাই করুন। গুণমান সামান্য কমিয়ে ও metadata বাদ দিয়ে বাস্তবসম্মত কমপ্রেশন করুন।
ছবির responsive সংস্করণ বানিয়ে srcset ও sizes ব্যবহার করলে ব্রাউজার স্ক্রিন অনুযায়ী উপযুক্ত ফাইল বেছে নেয়। LCP-র প্রধান ছবি সাধারণত loading="lazy" দেবেন না। Lazy loading নিচের, পরে দেখা যাবে এমন ছবির জন্য; প্রথম দৃশ্যের ছবি দেরিতে চাইলে LCP আরও পিছোয়। প্রধান ছবির জন্য preload কখনও সহায়ক হতে পারে, কিন্তু একাধিক বড় ছবি preload করলে উল্টো প্রতিযোগিতা হয়। CSS background-এ লুকানো হিরো ছবিও সহজে আবিষ্কৃত নাও হতে পারে—সম্ভব হলে অর্থপূর্ণ img ব্যবহার করুন।
সার্ভার দ্রুত HTML পাঠাবে এমন ক্যাশিং, Brotli বা Gzip কমপ্রেশন, HTTP/2 বা HTTP/3 এবং কম রিডাইরেক্ট কাজে দেয়। তবে হোস্টিংয়ের সীমা, লগইন পৃষ্ঠা ও ব্যক্তিগত কনটেন্টে পূর্ণ-পৃষ্ঠা ক্যাশ দেওয়ার আগে পরীক্ষা করুন। CDN কাছের edge location থেকে স্থির ফাইল পাঠাতে পারে, তাই বাংলাদেশ ও বিদেশি পাঠক একসঙ্গে থাকলে লাভ হয়; কিন্তু ভুল cache rule-এ পুরোনো CSS, কুকি-নির্ভর কনটেন্ট বা নিরাপত্তা-সংক্রান্ত সমস্যা হতে পারে। CDN কিনলেই সব ধীরতা সারে না—origin server, DNS, ছবি ও স্ক্রিপ্টও ঠিক করতে হবে।
INP: ক্লিকের পর সাইট যেন থেমে না থাকে
INP খারাপের বড় কারণ দীর্ঘ JavaScript task। অ্যানালিটিক্স, চ্যাট বক্স, পপ-আপ, স্লাইডার, বিজ্ঞাপন ও অপ্রয়োজনীয় লাইব্রেরি গুনে দেখুন। যে ফিচার কেউ ব্যবহার করে না সেটি সরান। দরকারি স্ক্রিপ্টে defer ব্যবহার করলে HTML পার্সিং আটকে থাকে না; তৃতীয় পক্ষের স্ক্রিপ্টে async বা tag manager-এর trigger ব্যবহার করা যায়, কিন্তু অন্ধভাবে সব স্ক্রিপ্ট async করলে নির্ভরতা নষ্ট হতে পারে। গুরুত্বপূর্ণ কাজ আগে, নিচের কাজ পরে—এই অগ্রাধিকার ঠিক করুন।
একটি ক্লিকে অনেক কাজ করলে JavaScript-কে ছোট অংশে ভাঙুন, অপ্রয়োজনীয় DOM পরিবর্তন কমান এবং ফলাফল দেখানোর আগে পুরো পৃষ্ঠা পুনরায় আঁকাবেন না। মেনু, সার্চ বা কমেন্টের মতো প্রয়োজনীয় ফিচার মোবাইল ডিভাইসে বাস্তবে পরীক্ষা করুন। ল্যাবে Total Blocking Time (TBT) INP সমস্যার ইঙ্গিত দিতে পারে, কিন্তু INP নিজে বাস্তব ব্যবহারকারীর ইন্টারঅ্যাকশন থেকে বোঝা যায়। তাই শুধু ডেস্কটপে দ্রুত দেখে সন্তুষ্ট হবেন না।
CLS কমাতে স্থির জায়গা রাখুন
প্রতিটি ছবি ও ভিডিওর জন্য HTML-এ width এবং height, অথবা CSS-এ aspect-ratio দিন। ব্রাউজার তাহলে আগে থেকেই জায়গা সংরক্ষণ করবে। বিজ্ঞাপন বা iframe-এর সম্ভাব্য আকার নির্ধারণ করে ফাঁকা জায়গা রাখুন; বিজ্ঞাপন না এলেও নকশা যেন ভেঙে না পড়ে। পরে উপরে ঢুকে পড়া নিউজবার, কুকি ব্যানার বা পপ-আপ বাদ দিন, অথবা নির্দিষ্ট জায়গার মধ্যে দেখান। নতুন ফন্ট আসার সময় লেখা বদলে যাওয়াও layout shift তৈরি করতে পারে। প্রয়োজনীয় font preload সীমিত রাখুন, fallback-এর মাপ কাছাকাছি বাছুন এবং অল্প font weight ব্যবহার করুন।
ফন্ট, স্ক্রিপ্ট ও ক্যাশের ভারসাম্য
বাংলা ফন্টে অক্ষর বেশি হওয়ায় ফাইল বড় হতে পারে। একটি ভারী পরিবারের সব weight না নিয়ে প্রয়োজনীয় ৪০০ ও ৭০০-তে সীমাবদ্ধ থাকুন। WOFF2 ব্যবহার করুন, subset সম্ভব হলে করুন, এবং font-display: swap বিবেচনা করুন। তবে অদলবদলের সময় লেখা খুব বদলে গেলে CLS মাপুন। ফন্ট স্থানীয়ভাবে রাখলে তৃতীয় পক্ষের DNS বা গোপনীয়তার নির্ভরতা কমে, আবার আপডেট ও লাইসেন্স আপনাকেই সামলাতে হবে।
স্থির CSS, JS, ছবি ও ফন্টে দীর্ঘ cache lifetime এবং ফাইলনামে version/hash দিন—যেমন style.v3.css—যাতে নতুন ফাইল এলে ক্যাশ পরিষ্কার না করেও পাওয়া যায়। HTML-এ তুলনামূলক ছোট cache ব্যবহার করুন, নয়তো পরিবর্তিত লেখা পাঠকের কাছে আটকে থাকবে। CDN cache-control header সম্মান করছে কি না পরীক্ষা করুন। ক্যাশের নিয়মে লগইন, কার্ট, ব্যক্তিগত ড্যাশবোর্ড বা লোকেশনভিত্তিক পৃষ্ঠা কখনও ভুল করে শেয়ার করবেন না।
Blogger ব্যবহারকারীদের বাস্তব সীমা
Blogger-এ সার্ভার, CDN, response header বা template build pipeline-এর নিয়ন্ত্রণ WordPress বা নিজস্ব হোস্টিংয়ের মতো নয়। তাই প্রথমে থিমের অতিরিক্ত widget, slideshow, auto-play video, webfont এবং বাহ্যিক tracking কমান। পোস্টের ছবির আসল মাপ আগে ঠিক করুন, অপ্রয়োজনীয় বড় ছবি আপলোড করবেন না, এবং template-এ ছবি ও iframe-এর dimension নিশ্চিত করুন। Blogger-এর ডিফল্ট সুবিধা যেখানে সীমিত, সেখানে নিজের JavaScript দিয়ে জটিল cache বা preload কৌশল চাপিয়ে না দিয়ে হালকা template বেছে নিন।
Blogger-এ তৃতীয় পক্ষের script পুরোপুরি নিয়ন্ত্রণ করা যায় না; বিজ্ঞাপন নেটওয়ার্ক ও analytics পরিবর্তনেও field ফল ওঠানামা করবে। তাই একবারে একটি widget বন্ধ করে PageSpeed ও বাস্তব ব্যবহার পরীক্ষা করুন। নিরাপত্তা, লেখা পড়া, বিজ্ঞাপন আয় এবং গতি—সব কিছুর ভারসাম্য দরকার। এমন কোনো কোড মুছবেন না যার উদ্দেশ্য বোঝেন না; আগে template backup রাখুন।
৩০ দিনের ছোট পরিকল্পনা
প্রথম দিনগুলোতে মোবাইল PageSpeed, Search Console এবং কয়েকটি বাস্তব ফোনে সমস্যা তালিকা করুন। প্রথম সপ্তাহে LCP ছবি, অপ্রয়োজনীয় widget এবং layout dimension ঠিক করুন। দ্বিতীয় সপ্তাহে স্ক্রিপ্ট ও font কমিয়ে defer/async-এর পর ফল পরীক্ষা করুন। তৃতীয় সপ্তাহে server cache, CDN ও compression কনফিগার করুন; cache hit এবং পুরোনো ফাইলের আচরণ দেখুন। চতুর্থ সপ্তাহে একই URL আবার মেপে field ডেটার পরিবর্তন নোট করুন। প্রতিটি পরিবর্তনের আগে-পরে তারিখ, URL, LCP, INP, CLS ও ব্যবসায়িক প্রভাব লিখুন।
শেষ কথা হলো, ভালো Core Web Vitals পাঠকের জন্য মূল্যবান, কিন্তু ভালো স্কোর বা Search Console-এর সবুজ ফল শীর্ষ র্যাঙ্কিং নিশ্চিত করে না। Google-এর page experience নির্দেশিকা বলছে, প্রাসঙ্গিকতা, সহায়ক কনটেন্ট, নিরাপত্তা, মোবাইল ব্যবহারযোগ্যতা, বিজ্ঞাপনের ভারসাম্যসহ সামগ্রিক অভিজ্ঞতা গুরুত্বপূর্ণ; একক কোনো page-experience signal নেই। তাই পরীক্ষাকে ভয় না পেয়ে মাপুন, সবচেয়ে বড় বাধা আগে সরান, ধীরে ধীরে পুনরায় যাচাই করুন—লক্ষ্য হবে দ্রুত, স্থির ও সহজে ব্যবহারযোগ্য ওয়েবসাইট।
রিপোর্ট পড়ার সহজ পদ্ধতি
রিপোর্টে লাল ফল দেখলেই আতঙ্কিত হওয়ার দরকার নেই। আগে কোন পৃষ্ঠা, কোন ডিভাইস এবং কোন মেট্রিক সমস্যা করছে তা আলাদা করুন। একই সাইটে হোমপেজের LCP ভালো হলেও পোস্টের LCP খারাপ হতে পারে, কারণ পোস্টে আলাদা বিজ্ঞাপন, টেবিল বা বড় ছবি থাকে। তাই সাইটের সামগ্রিক শতাংশ দেখে নির্দিষ্ট URL-এর উপাদানও খুলে দেখুন। একটি সমস্যার সম্ভাব্য কারণ তিন ভাগে লিখুন: সার্ভার থেকে HTML দেরি, ব্রাউজারে সম্পদ দেরি, অথবা ব্যবহারকারীর কাজের সময় JavaScript ব্যস্ত। এতে ভুল সমাধান বেছে নেওয়ার ঝুঁকি কমে।
PageSpeed-এর ‘diagnose performance issues’ তালিকা অগ্রাধিকারের ইঙ্গিত দেয়, চূড়ান্ত রায় নয়। ‘Reduce unused JavaScript’ দেখালেই সব কোড মুছে ফেলবেন না; আগে দেখুন সেটি মেনু, বিজ্ঞাপন, মাপজোক বা কোনো প্রয়োজনীয় ফিচারের অংশ কি না। ‘Properly size images’ দেখালে প্রতিটি ছবির প্রদর্শিত মাপ এবং ডাউনলোড মাপ তুলনা করুন। ‘Eliminate render-blocking resources’ দেখালে critical CSS, defer এবং inline করার প্রভাব মেপে নিন—অতিরিক্ত inline CSS আবার HTML ভারী করতে পারে।
ছবি ও মিডিয়ার ছোট চেকলিস্ট
ছবি প্রকাশের আগে তিনটি প্রশ্ন করুন: এটি কি সত্যিই এই আকারে দরকার, এটি কি দৃশ্যমান হওয়ার আগে দরকার, এবং ফাইলটি কি সংকুচিত? পোস্টের thumbnail ও ভেতরের পূর্ণ ছবির জন্য একই বড় ফাইল ব্যবহার না করে আলাদা সংস্করণ বানান। srcset না জানলে অন্তত সম্পাদনা সফটওয়্যারে মোবাইলের জন্য ছোট ফাইল তৈরি করুন। ছবির নাম বর্ণনামূলক রাখুন এবং অর্থপূর্ণ alt লিখুন—এটি accessibility-এর জন্য, গতি বাড়ানোর কোনো জাদুকাঠি নয়।
নিচের গ্যালারি, related post এবং footer-এর ছবিতে lazy loading ব্যবহার করুন, কিন্তু প্রথম viewport-এর LCP ছবিতে নয়। ভিডিও autoplay বন্ধ রেখে poster ছবি ও ব্যবহারকারীর ক্লিকের পর প্লে করার কৌশল নিন। YouTube বা Maps iframe দরকার হলে নিচে রাখুন এবং viewport-এর কাছে এলে লোড করার কথা ভাবুন। এমবেডের জায়গাও আগে থেকে নির্দিষ্ট রাখুন, না হলে iframe দেরিতে এসে CLS তৈরি করতে পারে।
থার্ড-পার্টি কোড বাছাই
প্রতিটি analytics, pixel, chat, ad এবং social widget-এর একটি উদ্দেশ্য লিখে রাখুন। একই কাজের দুইটি tracker থাকলে একটি বাদ দিন। বাহ্যিক পরিষেবা আপনার নিয়ন্ত্রণের বাইরে লোড হয়; তাদের DNS, certificate, server response বা বিজ্ঞাপনের আকার বদলালে আপনার ফল বদলাতে পারে। প্রয়োজন না থাকলে সব পৃষ্ঠায় একই script না দিয়ে শুধু checkout, contact বা campaign পৃষ্ঠায় চালান। Consent ব্যবস্থাও হালকা রাখুন এবং ব্যবহারকারীকে বিরক্ত করা full-screen interstitial এড়ান।
Tag manager সুবিধাজনক, কিন্তু তার ভেতরে জমা tag-এর তালিকা নিয়মিত পরিষ্কার করুন। একটি tag-এর trigger খুব দেরিতে দেওয়াই সবসময় নিরাপদ নয়; ক্লিক বা conversion হারিয়ে গেলে ব্যবসায়িক ক্ষতি হতে পারে। তাই আগে analytics-এ event ঠিকমতো আসছে কি না যাচাই করুন, পরে performance পরিবর্তন তুলনা করুন। কোনো script সরানোর পর 404, JavaScript error এবং গুরুত্বপূর্ণ ফর্ম পরীক্ষা করা বাধ্যতামূলক।
হোস্টিং, HTTPS ও CDN নিয়ে সিদ্ধান্ত
বারবার TTFB বেশি হলে host-এর support-কে server location, CPU limit, caching এবং compression সম্পর্কে জিজ্ঞেস করুন। শুধু একটি ল্যাব পরীক্ষায় server বদলানোর সিদ্ধান্ত নেবেন না; একই সময়ে কয়েকটি URL এবং বাস্তব ব্যবহারকারীর দেশ দেখুন। বাংলাদেশের পাঠক বেশি হলে কাছের region-এর hosting বা CDN edge উপকারী হতে পারে, কিন্তু origin যদি প্রতিবার নতুন HTML তৈরি করে, CDN শুধু স্থির সম্পদে সাহায্য করবে। DNS lookup, TLS handshake এবং একাধিক redirect কমিয়ে পরিষ্কার HTTPS ঠিকানা রাখুন।
CDN নেওয়ার আগে খরচ, cache purge, support, privacy এবং invalidation পদ্ধতি বুঝুন। সংবাদ বা ঘন ঘন বদলানো হোমপেজে দীর্ঘ cache দিলে পাঠক পুরোনো তথ্য পেতে পারে। আবার ছবি, CSS ও font-এর immutable versioned ফাইলে দীর্ঘ cache নিরাপদতর। cache header দেখার জন্য ব্রাউজারের Network panel ব্যবহার করুন; শুধু provider-এর dashboard-এর সবুজ চিহ্ন বিশ্বাস করবেন না।
উন্নতি টেকসই রাখার অভ্যাস
নতুন থিম, বিজ্ঞাপন বা প্লাগইন যোগ করার আগে একটি baseline রাখুন। পরিবর্তনের পর cache পরিষ্কার করে একই ডিভাইস ও নেটওয়ার্কে ল্যাব পরীক্ষা করুন, তারপর কয়েক দিন field data জমতে দিন। আবহাওয়া, ঈদ বা প্রচারণার সময়ে ট্রাফিক ও বিজ্ঞাপন বদলায়; তাই এক দিনের ওঠানামাকে স্থায়ী উন্নতি ভাববেন না। প্রতি মাসে সবচেয়ে বেশি দেখা পাঁচটি template-এর LCP, INP ও CLS নোট করুন।
কনটেন্ট টিমকেও নিয়ম দিন: আপলোডের আগে ছবি resize, অকারণ animation নয়, embed সীমিত, এবং শিরোনাম বা ছবি লোডের পরে নড়বে না। ডেভেলপার না থাকলে host বা theme support-কে নির্দিষ্ট evidence দিন—URL, device, metric, screenshot নয় শুধু—যাতে তারা আন্দাজে plugin বিক্রি না করে। একবারে এক পরিবর্তন করলে কোন কাজ ফল দিয়েছে বোঝা যায়।
শেষে accessibility ও গতি একসঙ্গে দেখুন। ছোট ফন্ট, কম contrast বা অদৃশ্য loading state দিয়ে score বাড়ানো গ্রহণযোগ্য নয়। পাঠক যেন ধীর সংযোগেও লেখা পড়তে পারেন, বোতাম চিনতে পারেন এবং ফর্মের ফল বুঝতে পারেন—এই ব্যবহারিক লক্ষ্যই মেট্রিকের চেয়ে বড়। Core Web Vitals সেই অভিজ্ঞতা মাপার সহায়ক জানালা, পুরো ওয়েবসাইটের মানের একমাত্র সংজ্ঞা নয়।
No comments:
Post a Comment