ওয়েবসাইট স্পিড অপটিমাইজেশন: ৬টি ভুল ধারণা যা আপনার সাইট ধীর করে রাখছে

ক্লায়েন্ট ফোন করে বলেন, “ভাই, সাইটটা স্লো” — আর পরের দুই ঘণ্টা কেটে যায় প্লাগইন খুঁজতে খুঁজতে। একটা ক্যাশ প্লাগইন বসে, একটা ইমেজ অপটিমাইজার বসে, PageSpeed স্কোর ৪৮ থেকে লাফিয়ে ৮৯ হয়, সবাই খুশি। অথচ তিন মাস পর কাস্টমার এখনো বলছেন সাইট খুলতে দেরি হয়। কারণটা সহজ: স্কোর বেড়েছে, সাইট দ্রুত হয়নি।

website speed optimization নিয়ে আমাদের ইন্ডাস্ট্রিতে এমন কিছু ধারণা চালু আছে যেগুলো হয় অর্ধসত্য, নয়তো এক দশক আগের সত্য। নিচে ছয়টা ধরে ধরে ভাঙা হলো — প্রতিটার সাথে কী মাপবেন আর কী করবেন সেটাসহ।

ভুল ধারণা ১: “PageSpeed-এ ১০০ পেলেই সাইট ফাস্ট”

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

গুরুত্ব দিন ফিল্ড ডেটার তিনটি মেট্রিকে: LCP (সবচেয়ে বড় কনটেন্টটা কত সেকেন্ডে দেখা যাচ্ছে — লক্ষ্য ২.৫ সেকেন্ডের নিচে), INP (ক্লিক বা ট্যাপের পর সাইট কত দ্রুত সাড়া দিচ্ছে — লক্ষ্য ২০০ মিলিসেকেন্ডের নিচে), আর CLS (পেজ লোড হওয়ার সময় লেখা লাফাচ্ছে কি না — লক্ষ্য ০.১ এর নিচে)। ঢাকার বাইরে একজন কাস্টমার ৪জি-তে যখন সাইট খোলেন, তার অভিজ্ঞতা এই তিনটা সংখ্যায় ধরা পড়ে — ল্যাব স্কোরে নয়।

স্কোর ৯৫ কিন্তু ফিল্ড LCP ৪.৮ সেকেন্ড — এমনটা হরহামেশা দেখি। এর মানে টেস্ট মেশিনে সব ঠিক, আপনার আসল ইউজারের ফোনে নয়।

ভুল ধারণা ২: “একটা ভালো ক্যাশ প্লাগইন বসালেই সব সমাধান”

ক্যাশিং দারুণ জিনিস, কিন্তু এটা যা করে সেটা হলো — একবার তৈরি করা HTML ফাইল বারবার পরিবেশন করা। ফলে সার্ভারের কাজ কমে, TTFB নামে। কিন্তু ক্যাশিং আপনার ভারী ইমেজ ছোট করে না, রেন্ডার-ব্লকিং CSS সরায় না, তৃতীয় পক্ষের স্ক্রিপ্ট বন্ধ করে না, আর লগইন করা ইউজার বা কার্ট-চেকআউট পেজের কোনো উপকারও করে না — ওগুলো ক্যাশ করা যায় না।

মানে ক্যাশ প্লাগইন হলো ভিত, সম্পূর্ণ ঘর নয়। WP Rocket, LiteSpeed Cache বা FlyingPress — যেটাই ব্যবহার করুন, তারপরেও আলাদা করে দেখতে হবে ইমেজ, ফন্ট, JavaScript আর সার্ভার রেসপন্স টাইম। শুধু প্লাগইন বসিয়ে হাত ধুয়ে ফেললে স্কোর বাড়বে, কাস্টমারের অভিজ্ঞতা বদলাবে না।

ভুল ধারণা ৩: “প্লাগইনের সংখ্যা কমালেই সাইট দ্রুত হবে”

“২০টা প্লাগইন! এজন্যই সাইট স্লো” — কথাটা শুনতে যুক্তিসঙ্গত, কিন্তু ভুল। প্লাগইনের সংখ্যা নয়, ওজন গুরুত্বপূর্ণ। কুড়িটা হালকা প্লাগইন — যেগুলো শুধু অ্যাডমিনে কাজ করে বা সামান্য ফাংশন যোগ করে — মিলে যতটা ক্ষতি করে, একটামাত্র ভারী স্লাইডার বা পেজ-বিল্ডার অ্যাডঅন তার চেয়ে বেশি করতে পারে। একটা খারাপভাবে লেখা প্লাগইন প্রতিটা পেজ লোডে ৩০০টা ডেটাবেজ কোয়েরি চালাতে পারে, কিংবা সব পেজে নিজের ২০০ কিলোবাইট CSS লোড করাতে পারে যদিও সেটা লাগে শুধু কন্টাক্ট পেজে।

সঠিক পদ্ধতি: Query Monitor প্লাগইন বসিয়ে দেখুন কোন প্লাগইন কত কোয়েরি আর কত PHP সময় খাচ্ছে। অনুমান করে প্লাগইন ডিলিট করবেন না — মেপে দেখুন, তারপর কাটুন। আর যেটা ডিঅ্যাক্টিভেট করেছেন কিন্তু ডিলিট করেননি, সেটা এখনো সার্ভারে পড়ে আছে — নিরাপত্তার ঝুঁকি হিসেবে।

ভুল ধারণা ৪: “ইমেজ কমপ্রেস করলেই ইমেজের কাজ শেষ”

কমপ্রেশন গল্পের এক-তৃতীয়াংশ মাত্র। বাকি দুই-তৃতীয়াংশ হলো মাপ আর অগ্রাধিকার। ক্যামেরা থেকে তোলা ৪০০০ পিক্সেল চওড়া ছবি কমপ্রেস করে ৮০০ কেবি করলেন — কিন্তু সেটা যদি সাইটে দেখানো হয় ৪০০ পিক্সেল চওড়া থাম্বনেইল হিসেবে, তাহলে ব্রাউজার এখনো পুরো ছবিটাই নামাচ্ছে, শুধু ছোট করে দেখাচ্ছে। মোবাইল ডেটায় এটা সরাসরি অপচয়।

• ছবিকে যে আকারে দেখাবেন সেই আকারেই আপলোড করুন — প্রোডাক্ট ছবির জন্য সাধারণত ৮০০–১২০০ পিক্সেল যথেষ্ট।
• WebP বা AVIF ফরম্যাটে সার্ভ করুন; একই মানে JPEG-এর তুলনায় সাধারণত ২৫–৩৫% ছোট হয়।
• নিচের ছবিগুলোয় lazy loading রাখুন, কিন্তু হিরো ইমেজে কখনোই নয় — ওটাই সাধারণত আপনার LCP এলিমেন্ট। ওতে fetchpriority="high" দিন, lazy নয়।
• ব্যাকগ্রাউন্ড ইমেজ CSS-এ বসালে ব্রাউজার দেরিতে খুঁজে পায়। হিরো সেকশনের ছবি সম্ভব হলে সরাসরি HTML-এ রাখুন।

ভুল ধারণা ৫: “CDN দিলেই বাংলাদেশে সাইট দ্রুত হবে”

Cloudflare-এর ফ্রি প্ল্যান চালু করে অনেকে ভাবেন কাজ শেষ। বাস্তবে ফ্রি CDN ডিফল্টভাবে শুধু স্ট্যাটিক ফাইল (ছবি, CSS, JS) ক্যাশ করে — আপনার HTML নয়। তার মানে প্রতিবার হোমপেজ চাওয়ার জন্য রিকোয়েস্ট এখনো আপনার মূল সার্ভার পর্যন্ত যাচ্ছে। সেই সার্ভার যদি যুক্তরাষ্ট্রে হয়, ঢাকা থেকে শুধু যাওয়া-আসাতেই ২০০ মিলিসেকেন্ডের বেশি চলে যায় — CDN থাকা সত্ত্বেও।

কাজের কথা: সার্ভার লোকেশন আগে ঠিক করুন। বাংলাদেশি ট্রাফিকের জন্য সিঙ্গাপুর, মুম্বাই বা লোকাল ডেটাসেন্টার — এগুলোর লেটেন্সি ইউরোপ/আমেরিকার চেয়ে অনেক কম। তারপর CDN বসান, আর সম্ভব হলে HTML-ও ক্যাশ করার ব্যবস্থা করুন (Cloudflare-এর “cache everything” রুল বা হোস্টের এজ ক্যাশ)। TTFB ২০০ মিলিসেকেন্ডের নিচে না নামলে বাকি অপটিমাইজেশনের ফল সীমিত থাকবে, কারণ ব্রাউজার প্রথম বাইটটাই দেরিতে পাচ্ছে।

ভুল ধারণা ৬: “ডেস্কটপে তো ফাস্ট, মোবাইল স্কোর নিয়ে চিন্তা নেই”

বাংলাদেশে বেশিরভাগ সাইটের ট্রাফিকের সিংহভাগ আসে মোবাইল থেকে, আর তার একটা বড় অংশ ৪জি বা তারও ধীর সংযোগে। গুগলও পেজ মূল্যায়ন করে মোবাইল ভার্সন দেখে। তাই ডেস্কটপে ১.৮ সেকেন্ডে লোড হচ্ছে বলে নিশ্চিন্ত থাকার সুযোগ নেই — আপনার আসল পাঠক ৫.৫ সেকেন্ড অপেক্ষা করছেন।

গুগলের নিজস্ব গবেষণা বলে, লোড টাইম ১ সেকেন্ড থেকে ৩ সেকেন্ডে গেলে ভিজিটরের বেরিয়ে যাওয়ার সম্ভাবনা প্রায় এক-তৃতীয়াংশ বেড়ে যায়। ই-কমার্স সাইটে এই সেকেন্ডগুলোর দাম সরাসরি টাকায় মাপা যায় — অর্ডার হারানো মানে টাকাই হারানো।

যেভাবে সঠিকভাবে মাপবেন

নিজের সাইটে ঢুকে “আমার তো দ্রুতই লাগছে” বলা সবচেয়ে বড় ফাঁদ — আপনার ব্রাউজার সব ফাইল আগে থেকেই ক্যাশ করে রেখেছে। ইনকগনিটো উইন্ডো খুলুন, DevTools-এ Network ট্যাব থেকে থ্রটলিং “Slow 4G” করে দিন, তারপর হোমপেজ খুলুন। এবার যা দেখবেন সেটাই আপনার কাস্টমারের বাস্তবতা।

GTmetrix বা WebPageTest ব্যবহার করলে টেস্ট লোকেশনটা অবশ্যই বদলে নিন। GTmetrix ডিফল্টে টেস্ট চালায় কানাডার ভ্যাঙ্কুভার থেকে — আপনার সার্ভার সিঙ্গাপুরে হলে ওই রিপোর্ট আপনাকে এমন একটা খারাপ TTFB দেখাবে যেটা কোনো বাংলাদেশি ভিজিটর কোনোদিন পাবে না, আর আপনি ভুল সমস্যার পিছনে দৌড়াবেন। যত কাছের রিজিয়ন পাওয়া যায় (মুম্বাই, সিঙ্গাপুর, হংকং) সেখান থেকে টেস্ট করুন, তাহলে সংখ্যাগুলো অন্তত আপনার কাস্টমারের বাস্তবতার কাছাকাছি হবে।

এরপর সার্চ কনসোলের Core Web Vitals রিপোর্ট দেখুন — সেখানে আসল ইউজারের ডেটা আছে, আর কোন URL গ্রুপ খারাপ করছে সেটাও বলা থাকে। রিপোর্টে URL-গুলো গ্রুপ করা থাকে বলে বোঝা যায় সমস্যা পুরো সাইটে নাকি শুধু প্রোডাক্ট পেজে — এই একটা তথ্যই ঘণ্টার পর ঘণ্টা অনুমান বাঁচিয়ে দেয়। মাসে একবার এই দুটো কাজ করলেই স্পিড আর হুট করে নষ্ট হয়ে যাবে না।

সাধারণ প্রশ্ন

সাইট কত সেকেন্ডে লোড হওয়া উচিত? এক সংখ্যায় উত্তর নেই, তবে বাস্তব ইউজারের LCP ২.৫ সেকেন্ডের নিচে রাখতে পারলে আপনি ভালো অবস্থানে আছেন। ৪ সেকেন্ড পেরোলে ভিজিটর হারানো শুরু।

শেয়ার্ড হোস্টিংয়ে ভালো স্পিড পাওয়া সম্ভব? সাধারণ ব্লগ বা কর্পোরেট সাইটে সম্ভব, যদি হোস্ট ভালো হয় এবং পেজ ক্যাশিং চালু থাকে। ভারী ডাইনামিক সাইটে (ই-কমার্স, মেম্বারশিপ) TTFB সমস্যা করবেই।

পেজ বিল্ডার ব্যবহার করলে কি সাইট ধীর হবেই? বাধ্যতামূলক নয়, তবে বিল্ডার বাড়তি HTML আর CSS যোগ করে। বিল্ডার ব্যবহার করলে অন্তত অপ্রয়োজনীয় উইজেট বন্ধ রাখুন, গ্লোবাল ফন্ট সীমিত রাখুন, আর প্রতিটা সেকশনে অ্যানিমেশন দেবেন না।

অপটিমাইজ করার পর আবার ধীর হয়ে যায় কেন? নতুন প্লাগইন, নতুন ট্র্যাকিং স্ক্রিপ্ট, ক্লায়েন্টের আপলোড করা ৫ মেগাবাইটের ছবি — স্পিড একবারের কাজ নয়, রক্ষণাবেক্ষণের কাজ। মাসে একবার মেপে দেখাই সবচেয়ে সস্তা সমাধান।

স্ট্যাক অ্যালিক্স-এ আমরা স্কোরের পিছনে দৌড়াই না, ফিল্ড ডেটা ধরে কাজ করি — সার্ভার রেসপন্স, ইমেজ, ফন্ট আর স্ক্রিপ্ট, এই ক্রমে। আপনার সাইটের LCP কোথায় আটকে আছে জানতে চাইলে একবার দেখিয়ে দিতে পারি।