ওয়েবসাইট স্পিড অপটিমাইজেশন: হাতে-কলমে পূর্ণ গাইড

ঢাকার একটা গয়নার দোকানের WooCommerce সাইট আমাদের কাছে এসেছিল। ডেস্কটপে দিব্যি চলে, কিন্তু মোবাইলে ৪জি-তে প্রথম ছবিটা আসতে সাড়ে আট সেকেন্ড লাগত। মালিক বললেন, ফেসবুক অ্যাডে ক্লিক আসে, বিক্রি আসে না। অ্যানালিটিক্সে দেখা গেল মোবাইল ভিজিটরদের ৬১ শতাংশ প্রোডাক্ট পেজ লোড হওয়ার আগেই বেরিয়ে যাচ্ছেন। বিজ্ঞাপনের টাকাটা আক্ষরিক অর্থেই লোডিং স্পিনারের পেছনে খরচ হচ্ছিল।

website speed optimization নিয়ে বেশিরভাগ লেখায় যা পাবেন — ছবি কম্প্রেস করুন, ক্যাশ প্লাগইন বসান, CDN নিন — সেগুলো ভুল নয়, কিন্তু অসম্পূর্ণ। আসল কাজটা হলো ঠিক কোন জায়গায় সময় নষ্ট হচ্ছে সেটা মাপা, তারপর শুধু সেই জায়গায় হাত দেওয়া। নিচে আমরা সেভাবেই এগোব — প্রতিটা ধাপে কী কনফিগার করবেন, কোথায় ফাঁদ পাতা আছে, আর কাজটা আসলে হয়েছে কিনা সেটা কীভাবে যাচাই করবেন।

আগে মাপুন — এবং ল্যাব ডেটাকে বিশ্বাস করবেন না

PageSpeed Insights দুই ধরনের তথ্য দেখায়। উপরে থাকে ফিল্ড ডেটা, যেটা আসল ব্যবহারকারীদের ক্রোম থেকে গত ২৮ দিনে জোগাড় করা (CrUX)। নিচে থাকে ল্যাব ডেটা, যেটা গুগলের একটা সার্ভার একবার সিমুলেট করে বের করে। মানুষ ওই নিচের রঙিন স্কোরটা নিয়ে মাথা ঘামায়, অথচ র‍্যাংকিংয়ে গুগল ব্যবহার করে উপরেরটা। যে তিনটা মেট্রিক আসলে গোনা হয়, ৭৫তম পার্সেন্টাইলে সেগুলোর থাকতে হবে: LCP ২.৫ সেকেন্ডের নিচে, INP ২০০ মিলিসেকেন্ডের নিচে, CLS ০.১-এর নিচে।

নতুন সাইটে ফিল্ড ডেটা দেখাবেই না — যথেষ্ট ট্রাফিক না থাকলে CrUX-এ ডেটা জমা হয় না। সেক্ষেত্রে Web Vitals ক্রোম এক্সটেনশন বসিয়ে নিজের ফোনে সাইটটা ব্যবহার করুন, ওটাই সত্যের সবচেয়ে কাছাকাছি। আর WebPageTest-এ টেস্ট করার সময় লোকেশন হিসেবে বাংলাদেশ পাবেন না — Mumbai বা Singapore বেছে নিন, কানেকশন প্রোফাইলে 4G সেট করুন। ঢাকার একজন মোবাইল ব্যবহারকারীর অভিজ্ঞতার সবচেয়ে কাছাকাছি ওটাই।

ধাপ ১: TTFB — সার্ভার কতক্ষণ চুপ করে বসে থাকে

কোনো CSS-JS অপটিমাইজেশনেই লাভ হবে না, যদি সার্ভার নিজেই প্রথম বাইট পাঠাতে দেড় সেকেন্ড নেয়। তাই সবার আগে এই কমান্ডটা চালান: curl -o /dev/null -s -w "ttfb: %{time_starttransfer}s | total: %{time_total}s\n" https://yoursite.com। ক্যাশড পেজে TTFB ২০০ মিলিসেকেন্ডের নিচে থাকা উচিত; ৬০০ পার হলে সমস্যা; এক সেকেন্ডের বেশি হলে হোস্টিং বদলানোর কথা ভাবুন।

বাংলাদেশে এখানে একটা বাস্তব সিদ্ধান্ত আছে। সস্তা মার্কিন শেয়ার্ড হোস্টিংয়ে সার্ভার আমেরিকায় বসে থাকে, ঢাকা থেকে প্রতিটা রাউন্ড-ট্রিপে ২৫০-৩০০ মিলিসেকেন্ড শুধু দূরত্বেই চলে যায়। সিঙ্গাপুর বা মুম্বাই ডেটাসেন্টার বেছে নিলে সেটা ৬০-৯০ মিলিসেকেন্ডে নেমে আসে — একটা টাকাও বেশি খরচ না করে, শুধু সাইনআপের সময় ঠিক লোকেশনটা বেছে। সার্ভার সাইডে আরও দুটো জিনিস নিশ্চিত করুন: PHP ৮.২ বা ৮.৩ (৭.৪-এ চললে শুধু ভার্সন বদলেই ৩০-৪০ শতাংশ দ্রুত হবে), আর OPcache চালু আছে কিনা। ভার্সন বদলালে পুরোনো থিম-প্লাগইন ভাঙতে পারে, তাই স্টেজিংয়ে আগে টেস্ট করুন।

ধাপ ২: ক্যাশ লেয়ার — একটাই, দুটো নয়

সবচেয়ে সাধারণ ভুল হলো দুটো পেজ ক্যাশ প্লাগইন একসঙ্গে চালানো। LiteSpeed Cache আর WP Rocket একসাথে থাকলে দুটোই আউটপুট বাফার দখল করতে চায়, ফল হয় অদ্ভুত সাদা পেজ বা পুরোনো কনটেন্ট আটকে থাকা। আপনার হোস্ট যদি LiteSpeed বা OpenLiteSpeed চালায় (বাংলাদেশের বেশিরভাগ ভালো হোস্ট চালায়), LiteSpeed Cache-ই ব্যবহার করুন — এটা সার্ভার লেভেলে ক্যাশ করে, তাই রিকোয়েস্ট PHP পর্যন্ত পৌঁছায়ই না। Apache বা Nginx হলে WP Rocket কিংবা FlyingPress।

যাচাই: curl -I https://yoursite.com চালিয়ে হেডার দেখুন। LiteSpeed-এ x-litespeed-cache: hit আসা উচিত (প্রথমবার miss, দ্বিতীয়বার hit), Cloudflare-এ cf-cache-status: HIT। সবসময় miss বা DYNAMIC এলে আপনার ক্যাশ আসলে কাজই করছে না — স্কোর যাই দেখাক না কেন।

এখানে সবচেয়ে ভয়ংকর ফাঁদটা হলো ডাইনামিক পেজ ক্যাশ হয়ে যাওয়া। Cart, Checkout, My Account আর যেকোনো লগইন-নির্ভর পেজ ক্যাশ থেকে বাদ দিতেই হবে। না দিলে একজন গ্রাহকের কার্ট আরেকজনের ব্রাউজারে দেখা যেতে পারে — এটা কাল্পনিক বিপদ নয়, লাইভ সাইটে আমরা এটা ঘটতে দেখেছি। WooCommerce-এ LiteSpeed Cache-এর ESI ফিচার চালু রাখলে কার্ট উইজেটটা আলাদা করে ফেচ হয় আর বাকি পেজ ক্যাশড থাকে, অর্থাৎ দুটোই পাওয়া যায়।

ধাপ ৩: পেমেন্ট গেটওয়ে ভাঙার গল্প

"Delay JS" বা "Defer JS" অপশনগুলো স্কোর অনেক বাড়ায়, আর ঠিক এখানেই সবচেয়ে বেশি সাইট ভাঙে। bKash, SSLCOMMERZ বা aamarPay-এর চেকআউট স্ক্রিপ্ট ডিলে হয়ে গেলে ব্যবহারকারী Pay বাটনে চাপ দেবেন আর কিছুই হবে না। কনসোলে কোনো এররও থাকবে না — শুধু নীরব ব্যর্থতা, আর আপনি জানতেও পারবেন না যতক্ষণ না কেউ ফোন করে বলে টাকা কাটছে না।

তাই ক্যাশ প্লাগইনের JS Excluded বা Delay Excluded তালিকায় গেটওয়ে ডোমেইনগুলো হাতে যোগ করুন, আর চেকআউট পেজটা অপটিমাইজেশন থেকে পুরোপুরি বাদ দিন। এরপর ১০ টাকার একটা টেস্ট প্রোডাক্ট বানিয়ে একটা আসল লেনদেন করুন — স্যান্ডবক্স নয়, লাইভ। প্রতিটা অপটিমাইজেশন সেটিং বদলানোর পর এই টেস্টটা আবার করুন। এক ঘণ্টার কাজ, কিন্তু এটা না করে আমরা অনেক দোকানকে তিন দিনের বিক্রি হারাতে দেখেছি, আর সাইট তখন হাসিমুখে ৯৬ স্কোর দেখিয়ে যাচ্ছিল।

ধাপ ৪: বাংলা ফন্ট — সবচেয়ে বড় লুকানো ওজন

এই জিনিসটা ইংরেজি টিউটোরিয়ালে কখনো পাবেন না, অথচ বাংলা সাইটের জন্য এটাই প্রায়ই সবচেয়ে বড় বাধা। Noto Sans Bengali বা Hind Siliguri-র পুরো ফাইল ৩০০ থেকে ৫০০ কিলোবাইট পর্যন্ত হয়। দুটো ওয়েট (regular আর bold) নিলে প্রায় এক মেগাবাইট শুধু ফন্টেই চলে গেল — অথচ পুরো পেজের HTML হয়তো ৫০ কিলোবাইট। ব্যবহারকারী টেক্সট দেখার জন্য বসে আছেন, আর ব্রাউজার ফন্ট নামাচ্ছে।

সমাধান হলো সাবসেটিং। fonttools-এর pyftsubset দিয়ে শুধু বাংলা ইউনিকোড রেঞ্জ (U+0980–09FF) আর প্রয়োজনীয় ল্যাটিন অক্ষর রেখে বাকি সব ফেলে দিন, আউটপুট woff2 ফরম্যাটে। ফাইলটা প্রায়ই ৬০-৯০ কিলোবাইটে নেমে আসে। এরপর ফন্টটা নিজের সার্ভারে হোস্ট করুন, Google Fonts থেকে টানবেন না — তাতে একটা বাড়তি DNS লুকআপ আর TLS হ্যান্ডশেক বাঁচে। CSS-এ font-display: swap; দিন, নাহলে ফন্ট নামা পর্যন্ত টেক্সট অদৃশ্য থাকবে। আর ফোল্ডের উপরে যে একটামাত্র ওয়েট দেখা যায়, শুধু সেটাই প্রিলোড করুন — সবগুলো প্রিলোড করলে হিতে বিপরীত হয়।

যাচাই: DevTools খুলে Network ট্যাবে Font ফিল্টার দিন। কয়টা ফাইল আসছে আর মোট কত কিলোবাইট — এই দুটো সংখ্যা দেখলেই বুঝে যাবেন কাজ হয়েছে কিনা। তিনটার বেশি ফন্ট ফাইল এলে বুঝবেন কোথাও একটা থিম বা প্লাগইন নিজের ফন্ট আলাদা করে লোড করছে।

ধাপ ৫: LCP ইমেজ — যেটাকে কখনো লেজি-লোড করবেন না

LCP এলিমেন্ট বেশিরভাগ পেজে একটা বড় ছবি — ব্যানার বা প্রোডাক্টের প্রধান ইমেজ। প্লাগইন দিয়ে ঢালাওভাবে সব ছবিতে lazy loading চালু করলে ঠিক এই ছবিটাও লেজি হয়ে যায়, আর LCP এক সেকেন্ড পিছিয়ে যায়। উল্টো কাজটা করুন: এই একটামাত্র ছবিতে loading="eager" আর fetchpriority="high" দিন, বাকি সবগুলোয় lazy রাখুন।

ছবিগুলো WebP-তে বদলান (ShortPixel বা Imagify, দুটোরই ফ্রি টিয়ারে মাসে ১০০-১৫০টা ছবি হয়ে যায়), আর srcset ব্যবহার করুন যাতে মোবাইলে ২০০০ পিক্সেল চওড়া ছবি না নামে। প্রতিটা <img> ট্যাগে width আর height অ্যাট্রিবিউট রাখুন — এটাই CLS ঠিক রাখার সবচেয়ে সহজ উপায়, কারণ ব্রাউজার তখন আগেভাগেই জায়গাটা ফাঁকা রাখতে পারে, আর ছবি এসে বাকি কনটেন্টকে নিচে ঠেলে দেয় না।

যাচাই: DevTools → Performance প্যানেলে রেকর্ড করুন, তারপর Timings সারিতে LCP মার্কারে হোভার করলে ঠিক কোন এলিমেন্টটা LCP, সেটা দেখাবে — অনুমান করার দরকার নেই। আর Network ট্যাবে ছবির রেসপন্স হেডারে content-type: image/webp না থাকলে বুঝবেন WebP আসলে সার্ভ হচ্ছে না, শুধু বানানো হয়ে সার্ভারে পড়ে আছে।

ধাপ ৬: Elementor-এর CSS বোঝা আর ডেটাবেসের ময়লা

Elementor প্রতিটা পেজে প্রায় ২০০ কিলোবাইট CSS পাঠায়, যার বেশিরভাগ ওই পেজে ব্যবহৃতই হয় না। ক্যাশ প্লাগইনের "Remove Unused CSS" ফিচার এটা অনেকটা কমায়, কিন্তু এখানেও ফাঁদ আছে — যেসব এলিমেন্ট ক্লিকের পর দেখা যায় (পপআপ, অ্যাকর্ডিয়ন, স্লাইডারের পরের স্লাইড), টুল তাদের CSS খুঁজে পায় না এবং কেটে ফেলে। ফলাফল: পপআপ খুললে ডিজাইন ভেঙে যায়। তাই এই ফিচার চালু করার পর সাইটের প্রতিটা ইন্টারঅ্যাকটিভ অংশ হাতে ক্লিক করে দেখা ছাড়া উপায় নেই।

ডেটাবেসের দিকেও একবার তাকান। wp_options টেবিলে autoload = yes করা ডেটার পরিমাণ ৮০০ কিলোবাইট ছাড়ালে প্রতিটা পেজ লোডে ওই পুরোটা মেমরিতে ওঠে — এবং পুরোনো প্লাগইন মুছে ফেললেও তাদের অপশনগুলো রয়ে যায়, বছরের পর বছর। Query Monitor প্লাগইন বসিয়ে দেখুন কোন কোয়েরি বা কোন প্লাগইন সবচেয়ে বেশি সময় নিচ্ছে। অনুমান করবেন না, ডেটা দেখুন — প্রায়ই দোষী প্লাগইনটা সেটাই হয় যেটাকে আপনি সবচেয়ে নিরীহ ভাবতেন।

চূড়ান্ত যাচাই চেকলিস্ট

• ক্যাশড পেজে TTFB ৩০০ মিলিসেকেন্ডের নিচে, curl দিয়ে দুইবার মেপে নিশ্চিত করা
• হেডারে x-litespeed-cache: hit অথবা cf-cache-status: HIT আসছে
• চেকআউটে ১০ টাকার একটা আসল লেনদেন সফলভাবে সম্পন্ন হয়েছে
• আসল ফোনে, ৪জি-তে, Web Vitals এক্সটেনশনে LCP ২.৫ সেকেন্ডের নিচে
• পপআপ, স্লাইডার আর মোবাইল মেনু — প্রতিটা হাতে ক্লিক করে দেখা হয়েছে

কয়েকটা জরুরি প্রশ্ন, সোজাসাপ্টা উত্তর

প্রশ্ন: PageSpeed-এ ১০০ স্কোর পাওয়া কি জরুরি? উত্তর: না, এবং এর পেছনে ছুটলে ক্ষতিই বেশি। ৯০+ স্কোর নিয়ে অনেক সাইট আসল ব্যবহারকারীর কাছে ধীর, আবার ৭২ স্কোরের সাইট দ্রুত মনে হতে পারে। CrUX ফিল্ড ডেটায় LCP, INP আর CLS সবুজ থাকলেই যথেষ্ট — বাকিটা ভ্যানিটি মেট্রিক।

প্রশ্ন: Cloudflare-এর ফ্রি প্ল্যানে কি সত্যিই কাজ হয়? উত্তর: হ্যাঁ, বিশেষ করে বাংলাদেশি ভিজিটরদের জন্য, কারণ Cloudflare-এর ঢাকায় পপ আছে — স্ট্যাটিক ফাইল দেশের ভেতর থেকেই সার্ভ হবে। তবে ফ্রি প্ল্যানে HTML ডিফল্টে ক্যাশ হয় না, শুধু ছবি-CSS-JS হয়। HTML ক্যাশ করাতে চাইলে Cache Rules সেট করতে হবে, আর তখনই কার্ট-চেকআউট বাদ দেওয়ার নিয়মগুলোও লিখতে হবে।

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

প্রশ্ন: হোস্টিং না বদলে কি সবচেয়ে বড় লাভটা পাওয়া যায়? উত্তর: বেশিরভাগ ক্ষেত্রে না। TTFB এক সেকেন্ডের বেশি হলে ছবি বা CSS নিয়ে যত কাজই করুন, শুরুর ওই এক সেকেন্ড কমবে না — ওটা ব্রাউজারের হাতেই নেই। আগে সার্ভার ঠিক করুন, তারপর ফ্রন্টএন্ড। উল্টো ক্রমে কাজ করলে অনেক পরিশ্রম করে সামান্য ফল পাবেন।

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