ওয়েবসাইট স্পিড অপটিমাইজেশন: নম্বরগুলো আসলে কী বলছে

গত মাসে ঢাকার একটা ছোট ফার্নিচার ব্র্যান্ডের মালিক ফোন করে বললেন, “ভাই, সাইট তো ঠিকই আছে, কিন্তু কাস্টমাররা বলছে খোলে না।” আমরা তাঁর সাইটটা খুললাম — অফিসের ফাইবার লাইনে, ডেস্কটপে, দেড় সেকেন্ডে ঝকঝকে। এরপর একটা সাধারণ ৪জি ফোনে, বনশ্রীর গলিতে দাঁড়িয়ে একই লিংক খুললাম। প্রথম ছবিটা চোখে পড়ল সাড়ে আট সেকেন্ড পর। ওয়েবসাইট স্পিড অপটিমাইজেশন নিয়ে যত কথা হয়, তার বেশিরভাগই আসলে এই ফাঁকটার গল্প — আপনি যা দেখছেন আর আপনার কাস্টমার যা পাচ্ছে, দুটো এক জিনিস না।

এই লেখাটা কোনো চেকলিস্ট না, প্লাগইনের তালিকাও না। এখানে সেই প্রশ্নগুলোর উত্তর দেওয়ার চেষ্টা করেছি যেগুলো ক্লায়েন্ট মিটিংয়ে, ফেসবুক গ্রুপে আর ফ্রিল্যান্সারদের ইনবক্সে ঘুরেফিরে আসে। কারণ কিছু ঠিক করার আগে বোঝা দরকার — টুলগুলো যে নম্বর দেখাচ্ছে সেগুলো আসলে কী মাপছে, আর কোনটা নিয়ে আসলে দুশ্চিন্তা করারই দরকার নেই।

“সাইট স্লো” বলতে আমরা আসলে কী বোঝাই?

স্পিড একটা সংখ্যা না, তিনটা আলাদা অভিজ্ঞতা। এক, কিছু একটা চোখে পড়তে কত সময় লাগল। দুই, দেখা যাওয়ার পর সেটা ব্যবহারযোগ্য হতে কত সময় লাগল — মানে বাটনে চাপ দিলে সাড়া দিচ্ছে কি না। তিন, পড়তে গিয়ে পাতাটা লাফাচ্ছে কি না। একটা সাইট প্রথম পরীক্ষায় দারুণ, দ্বিতীয়টায় ভয়ংকর — এমন হওয়া খুবই স্বাভাবিক। তাই “সাইট স্লো” অভিযোগটা পেলে প্রথম কাজ প্রশ্ন করা: কোন জায়গায় স্লো?

আরেকটা ব্যাপার আছে যেটা কোনো টুল মাপে না — অনুভূত গতি। যে পাতাটা ০.৮ সেকেন্ডে একটা ফাঁকা কাঠামো (স্কেলিটন) দেখিয়ে দেয়, সেটা ব্যবহারকারীর কাছে দ্রুত মনে হয়; আর যে পাতাটা আড়াই সেকেন্ড সাদা স্ক্রিন ধরে রেখে হঠাৎ সবকিছু একসাথে ছুড়ে দেয়, সেটা ধীর মনে হয় — যদিও মোট লোড টাইম দুটোরই সমান। মানুষ ঘড়ি দেখে না, মানুষ অপেক্ষা টের পায়।

PageSpeed Insights-এ ৪৫ দেখাচ্ছে — এটা কি বিপর্যয়?

না। ওই স্কোরটা ছয়টা ল্যাব-মেট্রিকের একটা ওজনভিত্তিক গড়, যেটা বের করা হয় একটা সিমুলেটেড মিড-রেঞ্জ অ্যান্ড্রয়েড ফোনে, ইচ্ছে করে ধীর করে দেওয়া নেটওয়ার্কে চালিয়ে। এটা স্মোক অ্যালার্ম, ডায়াগনোসিস না। ৪৫ মানে কোথাও ধোঁয়া উঠছে — কোথায় উঠছে সেটা স্কোর বলে না, রিপোর্টের নিচের “Opportunities” আর “Diagnostics” অংশ বলে। বেশিরভাগ মানুষ স্কোরটা দেখে স্ক্রিনশট নেয় আর বাকিটুকু আর স্ক্রল করে না।

আর ১০০ পাওয়ার পেছনে ছোটাটা একটা ফাঁদ। বড় বড় নামকরা সাইটও মোবাইলে ৬০-৭০-এ ঘোরাফেরা করে, তাদের ব্যবসা দিব্যি চলছে। গুগল নিজেও র‍্যাঙ্কিংয়ের জন্য এই স্কোরটা ব্যবহার করে না — ব্যবহার করে কোর ওয়েব ভাইটালসের পাস/ফেইল অ্যাসেসমেন্ট, যেটা আসে বাস্তব ব্যবহারকারীদের ডেটা থেকে।

স্কোর একটা লক্ষণ, রোগ না। ৪৫ থেকে ৯০-এ ওঠা মানে সবসময় কাস্টমারের অভিজ্ঞতা ভালো হওয়া না — আবার ৭২-এ থেকেও একটা সাইট দুর্দান্ত ফিল করতে পারে।

ল্যাব ডেটা আর ফিল্ড ডেটা: রিপোর্টের উপর আর নিচ

PageSpeed Insights খুললে উপরে থাকে বাস্তব ব্যবহারকারীদের ডেটা — গত ২৮ দিনে যারা ক্রোম দিয়ে আপনার সাইটে ঢুকেছে, তাদের আসল অভিজ্ঞতা। আর নিচে থাকে ল্যাব রান — একটা কৃত্রিম পরিবেশে চালানো একটামাত্র টেস্ট। দুটো মিলবে না, মেলার কথাও না। যদি সাইটে ট্রাফিক কম হয়, উপরের অংশে লেখা উঠবে যে যথেষ্ট ডেটা নেই — তখন ল্যাব রানই ভরসা, কিন্তু সেটাকে ধ্রুব সত্য ভাবা যাবে না।

বাংলাদেশি সাইটের বেলায় ফিল্ড ডেটা প্রায় সবসময় ল্যাব ডেটার চেয়ে কঠোর হয়। কারণ বাস্তব ভিজিটর ম্যাকবুকে বসে নেই — সে আছে ৳১২,০০০ টাকার একটা অ্যান্ড্রয়েড ফোনে, চার-পাঁচটা ট্যাব খোলা অবস্থায়, বিকেলবেলা যখন মোবাইল নেটওয়ার্কে চাপ সবচেয়ে বেশি। আপনার ল্যাপটপ আপনাকে মিথ্যা বলে। ফিল্ড ডেটাকে বিশ্বাস করুন, আর ল্যাব ডেটাকে ব্যবহার করুন শুধু “কোন জিনিসটা ঠিক করব” সেটা খুঁজে বের করতে।

LCP, INP, CLS — তিনটা সংক্ষিপ্ত রূপ, তিনটা আলাদা প্রশ্ন

• LCP (Largest Contentful Paint) — পাতার সবচেয়ে বড় জিনিসটা, সাধারণত হিরো ইমেজ বা বড় হেডলাইন, কখন চোখে পড়ল। ভালো ধরা হয় ২.৫ সেকেন্ডের নিচে। এটা যে প্রশ্নের উত্তর দেয়: “কিছু কি দেখা যাচ্ছে?”
• INP (Interaction to Next Paint) — ভিজিটর মেনু বা বাটনে ট্যাপ করার পর স্ক্রিনে কিছু বদলাতে কত সময় লাগল। ভালো ধরা হয় ২০০ মিলিসেকেন্ডের নিচে। প্রশ্নটা: “সাইট কি সাড়া দিচ্ছে?” ২০২৪-এর মার্চে এটা পুরোনো FID-এর জায়গা নিয়েছে, আর এটা অনেক বেশি কড়া পরীক্ষক।
• CLS (Cumulative Layout Shift) — পড়ার মাঝপথে লেখা বা বাটন লাফিয়ে সরে যাচ্ছে কি না। ভালো ধরা হয় ০.১-এর নিচে। প্রশ্নটা: “পাতাটা কি স্থির?” দেরিতে লোড হওয়া ব্যানার, বিজ্ঞাপন আর ওয়েব ফন্ট — এই তিনটাই সবচেয়ে বড় অপরাধী।

তিনটা আলাদা মেট্রিক কেন দরকার, সেটা একটা উদাহরণেই পরিষ্কার হয়। একটা ই-কমার্স প্রোডাক্ট পাতা ১.৮ সেকেন্ডে দেখা গেল — LCP চমৎকার। কিন্তু ভিজিটর “কার্টে যোগ করুন” বাটনে চাপ দেওয়ার পর ৬০০ মিলিসেকেন্ড কিছুই হলো না, কারণ ব্যাকগ্রাউন্ডে তিনটা ট্র্যাকিং স্ক্রিপ্ট ব্রাউজারের মূল থ্রেড আটকে বসে আছে। ইউজার ভাবল চাপ লাগেনি, আবার চাপ দিল — দুটো প্রোডাক্ট কার্টে ঢুকে গেল। মেট্রিক বলছে সাইট ফাস্ট; কাস্টমার বলছে সাইট নষ্ট।

পাতা লোড শুরুই হয় না — TTFB নিয়ে সত্যি কথা

TTFB মানে Time To First Byte — অর্থাৎ ব্রাউজার অনুরোধ পাঠানোর পর সার্ভার থেকে প্রথম বাইটটা আসতে কত সময় লাগল। এটা ঘটে একটা পিক্সেলও আঁকার আগে। এখানেই দেশি সাইটের সবচেয়ে বড় লুকানো ক্ষত। মাসে ১০০-১৫০ টাকার শেয়ার্ড হোস্টিং প্যাকেজে একটা সার্ভারে তিন-চারশো সাইট গাদাগাদি করে থাকে; সেখানে TTFB ১.২ থেকে ২ সেকেন্ড হওয়া অস্বাভাবিক না।

হিসাবটা নিষ্ঠুর: TTFB যদি ১.৫ সেকেন্ড হয়, তাহলে আপনি ছবি যত খুশি কম্প্রেস করুন, LCP কোনোদিন ২.৫ সেকেন্ডের নিচে নামবে না। মেঝেটাই যদি উঁচু হয়, ঘরের ছাদ নিচু করে লাভ নেই। সার্ভার কোথায় বসানো সেটাও গুরুত্বপূর্ণ — ঢাকা থেকে যুক্তরাষ্ট্রের সার্ভারে শুধু যাওয়া-আসাতেই ২৫০-৩০০ মিলিসেকেন্ড চলে যায়, সিঙ্গাপুরে ৬০-৯০ মিলিসেকেন্ড। অনেক “বাংলাদেশি” হোস্টিং কোম্পানির সার্ভার আসলে সিঙ্গাপুর বা জার্মানিতে। ধরে নেবেন না, জিজ্ঞেস করে নিন।

প্লাগইনের সংখ্যা কি সত্যিই দোষী?

“প্লাগইন ২০টার নিচে রাখুন” — এই পরামর্শটা শুনতে ভালো, কিন্তু এটা অলস পরামর্শ। ত্রিশটা ভালোভাবে লেখা প্লাগইন, যেগুলো ফ্রন্ট-এন্ডে কিছুই লোড করে না, আটটা বাজে প্লাগইনের চেয়ে অনেক হালকা হতে পারে — যেখানে প্রতিটা আলাদা করে নিজের jQuery স্লাইডার টেনে আনছে। আসল প্রশ্ন সংখ্যা না; আসল প্রশ্ন হলো প্রতিটা পাতায় কয়টা অতিরিক্ত CSS/JS ফাইল যোগ হচ্ছে, প্রতি রিকোয়েস্টে কয়টা ডেটাবেস কোয়েরি চলছে, আর প্লাগইনটা তার জিনিসপত্র পুরো সাইটে ছড়াচ্ছে কি না যখন সেটা দরকার মাত্র একটা পাতায়।

এটা অনুমান করার দরকার নেই, মেপে ফেলা যায়। Query Monitor প্লাগইনটা বিনামূল্যে দেখিয়ে দেয় কোন স্ক্রিপ্টের মালিক কে, কয়টা কোয়েরি চলছে, কোনটা ধীর। একটা ক্লায়েন্ট সাইটে আমরা দেখেছিলাম একটা কন্টাক্ট ফর্ম প্লাগইন ৯০ কিলোবাইটের CSS আর reCAPTCHA লোড করছে সাইটের ৩৪০টা পাতাতেই — যেখানে ফর্ম আছে মাত্র একটাতে। শুধু ওই একটা পাতায় সীমাবদ্ধ করে দেওয়ায় মোবাইলে LCP থেকে ১.১ সেকেন্ড কমে গিয়েছিল। কোনো নতুন প্লাগইন কেনা লাগেনি।

“৩ সেকেন্ড পেরোলেই ৫৩% ভিজিটর চলে যায়” — কতটা মানব?

এই পরিসংখ্যানটা এসেছে গুগল আর SOASTA-র ২০১৬-১৭ সালের একটা গবেষণা থেকে, যেটা করা হয়েছিল মোবাইল ল্যান্ডিং পেজের ওপর। আর সেটাকে এখন ধর্মগ্রন্থের আয়াতের মতো উদ্ধৃত করা হয়। দিকটা ঠিক আছে, কিন্তু নিখুঁত সংখ্যাটা ভুয়া। বাস্তবে দেশি ক্লায়েন্টদের ডেটায় আমরা যা দেখি: ৩.০ সেকেন্ডে কোনো খাদ নেই, আছে একটা ঢাল। বাউন্স রেট ধাপে ধাপে বাড়ে। আর ধৈর্যও এক রকম না — ফেসবুক অ্যাডে ইচ্ছে করে ক্লিক করে আসা মানুষটা একটা প্রোডাক্ট পাতার জন্য যতটা অপেক্ষা করবে, সার্চ থেকে আসা মানুষ একটা ব্লগ পোস্টের জন্য ততটা করবে না।

কাজের কথাটা হলো: কোনো সংখ্যার পেছনে না দৌড়ে, আপনার সবচেয়ে ধীর বাস্তব অংশটার দিকে তাকান। PageSpeed-এর ফিল্ড ডেটায় মোবাইল সেগমেন্ট দেখুন। যদি ৭৫তম পার্সেন্টাইল LCP ৪.৬ সেকেন্ড হয়, তার মানে প্রতি চারজন ভিজিটরের একজন প্রায় পাঁচ সেকেন্ড তাকিয়ে বসে আছে। ওই সংখ্যাটাই নড়ানোর মতো সংখ্যা।

যে প্রশ্নগুলো ক্লায়েন্টরা সবচেয়ে বেশি করেন

শেয়ার্ড হোস্টিংয়ে থেকেও কি ভালো স্পিড পাওয়া সম্ভব?

একটা সীমা পর্যন্ত, হ্যাঁ। ভালো পেজ ক্যাশিং বসানো থাকলে PHP প্রায় চলেই না — সার্ভার শুধু আগে থেকে বানানো HTML ফাইলটা ছুড়ে দেয়, আর একটা মোটামুটি শেয়ার্ড প্ল্যানও সেটা ২০০-৪০০ মিলিসেকেন্ডে করতে পারে। সমস্যা শুরু হয় WooCommerce-এর কার্ট, চেকআউট আর অ্যাকাউন্ট পাতায় — এগুলো ক্যাশ করা যায় না, প্রতিবার নতুন করে PHP আর MySQL চালাতে হয়। তখন সার্ভারের আসল ক্ষমতা বেরিয়ে পড়ে। সহজ নিয়ম: ব্রোশিওর টাইপ সাইট হলে শেয়ার্ড যথেষ্ট; দিনে ১০০+ অর্ডারের দোকান হলে VPS বা LiteSpeed প্ল্যানে যান।

ছবি কম্প্রেস করলাম, তবু LCP কমছে না কেন?

কারণ LCP-র চারটা অংশ: সার্ভারের সময় (TTFB), ছবিটা খুঁজে পেতে দেরি, ছবিটা ডাউনলোড হতে সময়, আর আঁকতে দেরি। কম্প্রেশন শুধু তৃতীয় অংশটাকে ছোঁয়। যদি হিরো ইমেজটা একটা স্লাইডারের জাভাস্ক্রিপ্ট দিয়ে আসে, অথবা লেজি-লোডের আড়ালে থাকে, তাহলে ব্রাউজার সেটা ডাউনলোড করাই শুরু করে দুই সেকেন্ড পর। ছবি ৮০০ কিলোবাইট না হয়ে ৮০ কিলোবাইট হলেও ওই দুই সেকেন্ডের দেরিটা রয়েই যায়। সমাধান: হিরো ইমেজ সরাসরি HTML-এ রাখুন, তাতে fetchpriority="high" দিন, আর স্ক্রিনের প্রথম অংশের কোনো ছবিতে কখনোই লেজি-লোড দেবেন না।

মোবাইল আর ডেস্কটপের স্কোরে এত বিশাল ফারাক কেন?

কারণ ডেস্কটপ টেস্টে ব্রাউজারকে ধরে নেওয়া হয় শক্তিশালী প্রসেসর আর ভালো নেটওয়ার্কে চলছে, আর মোবাইল টেস্টে ধরা হয় একটা মাঝারি মানের ফোন। জাভাস্ক্রিপ্ট চালাতে ওই ফোনের সিপিইউ আপনার ল্যাপটপের চেয়ে চার থেকে ছয় গুণ বেশি সময় নেয়। তাই ভারী জাভাস্ক্রিপ্টওয়ালা সাইটে ডেস্কটপে ৯৫ আর মোবাইলে ৩৮ — এটা কোনো বাগ না, এটাই বাস্তবতা। আর বাংলাদেশে ট্রাফিকের বড় অংশ মোবাইল, তাই মোবাইল স্কোরটাই আপনার আসল স্কোর।

স্পিড ঠিক না করলে কি গুগল র‍্যাঙ্কিং পড়ে যাবে?

কোর ওয়েব ভাইটালস একটা সত্যিকারের র‍্যাঙ্কিং সিগন্যাল, কিন্তু ছোট একটা — সমান প্রাসঙ্গিকতার দুটো পাতার মধ্যে টাই-ব্রেকারের মতো। খারাপ কনটেন্ট দ্রুত হলেই র‍্যাঙ্ক করবে না। ধীর সাইটের আসল ক্ষতিটা র‍্যাঙ্কিংয়ে না, ক্ষতিটা হলো সেই মানুষটা যে আপনার পাতাটা কোনোদিন দেখলই না। দারাজের সাথে প্রতিযোগিতা করা একটা প্রোডাক্ট পাতায় তিন সেকেন্ডের সাদা স্ক্রিন মানে হারিয়ে যাওয়া একটা অর্ডার — গুগল সেটা খেয়াল করুক বা না করুক।

শেষ কথা

স্পিড অপটিমাইজেশনের সবচেয়ে বড় ভুলটা হলো টুল খোলার আগেই সমাধান ঠিক করে ফেলা। আগে মাপুন, তারপর বুঝুন কোন জায়গাটা সবচেয়ে বেশি খরচ করছে, তারপর একটা করে জিনিস বদলে আবার মাপুন। এই তিনটা ধাপ ছাড়া বাকি সব আন্দাজ। স্ট্যাক অ্যালিক্স-এ আমরা ক্লায়েন্ট সাইটে ঠিক এভাবেই কাজ করি — একটা রিপোর্ট দিয়ে শুরু, যেখানে লেখা থাকে সমস্যাটা কোথায় আর সেটা ঠিক করলে কত মিলিসেকেন্ড ফেরত পাবেন। আপনার সাইট নিয়ে সন্দেহ থাকলে একবার কথা বলে দেখুন; অন্তত জানবেন নম্বরটা কীসের।