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

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

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

ধাপ শূন্য: মেঝেটা কোথায়, সেটা আগে মাপুন

সার্ভার সাড়া দিতে কত সময় নিচ্ছে, সেটা না জেনে কিছু করবেন না। টার্মিনালে এক লাইনেই পাওয়া যায়, অথবা WebPageTest-এ ফ্রি টেস্ট চালিয়ে নিন। আমাদের ওই দোকানটার সার্ভার সাড়া দিচ্ছিল ৯৪০ মিলিসেকেন্ডে — মানে কাস্টমার প্রায় এক সেকেন্ড শুধু তাকিয়ে ছিল, তখনো একটা বাইটও আসেনি। যদি এই সংখ্যাটা ৬০০ মিলিসেকেন্ডের বেশি হয়, তাহলে নিচের কোনো ধাপই আপনাকে বাঁচাতে পারবে না। হোস্টিং আগে ঠিক করুন। ওই সাইটটা LiteSpeed চালানো একটা VPS-এ সরানোর পর সংখ্যাটা দাঁড়াল ২১০ মিলিসেকেন্ডে — এক ধাপেই প্রতিটা মেট্রিক থেকে ০.৭ সেকেন্ড উধাও।

ধাপ এক: পেজ ক্যাশ — একবার, ঠিকভাবে, একটাই

ওয়ার্ডপ্রেসে একটামাত্র পরিবর্তন যদি করতে দেওয়া হয়, সেটা পেজ ক্যাশ। ক্যাশ ছাড়া প্রতিটা ভিজিটের জন্য PHP চলে, ডেটাবেসে ২০-৮০টা কোয়েরি যায়, তারপর HTML তৈরি হয়। ক্যাশ থাকলে সার্ভার শুধু আগে থেকে বানিয়ে রাখা ফাইলটা ছুড়ে দেয়। পার্থক্যটা প্রায়ই এক সেকেন্ডের বেশি।

• কোন প্লাগইন: হোস্ট যদি LiteSpeed/OpenLiteSpeed চালায় (দেশে অনেক হোস্টই চালায়), LiteSpeed Cache — ফ্রি এবং সেরা। না চালালে WP Rocket (বছরে প্রায় $৫৯), FlyingPress, অথবা ফ্রিতে WP Super Cache। যেকোনো একটা।
• যে সেটিংগুলো আসলে কাজ করে: পেজ ক্যাশ চালু, ব্রাউজার ক্যাশ স্ট্যাটিক ফাইলের জন্য এক বছর, Brotli বা gzip কম্প্রেশন চালু।
• যেগুলো বাদ রাখতেই হবে: কার্ট, চেকআউট, মাই-অ্যাকাউন্ট আর যেকোনো লগইন-করা পাতা কখনোই ক্যাশ করবেন না — নাহলে একজনের কার্ট আরেকজন দেখবে। এটা কল্পনা না, এমন ঘটে।
• Redis অবজেক্ট ক্যাশ: শুধু তখনই, যখন সাইটে দোকান বা মেম্বারশিপ আছে। সাধারণ ব্লগে এটা বাড়তি ঝামেলা, বাড়তি লাভ নেই।

একসাথে দুটো ক্যাশ প্লাগইন চালালে সাইট দ্বিগুণ দ্রুত হয় না — সাইট ভাঙে। নতুনটা বসানোর আগে পুরোনোটা পুরোপুরি আনইনস্টল করুন, শুধু নিষ্ক্রিয় করে রাখলে হবে না।

ধাপ দুই: ছবি — এখানে একটা কাজ না, তিনটা কাজ

বেশিরভাগ মানুষ ছবির বেলায় শুধু কম্প্রেশনটা করে, আর ভাবে কাজ শেষ। আসলে তিনটা আলাদা কাজ আছে, আর তিনটাই না করলে অর্ধেক সুবিধা হাতছাড়া হয়।

• ফরম্যাট: JPEG/PNG থেকে WebP-তে যান। কোয়ালিটি ৮০-তে চোখে পার্থক্য ধরা পড়ে না, কিন্তু ফাইল ৬০-৭৫% ছোট হয়। AVIF আরও ছোট, তবে পুরোনো ব্রাউজারে সমস্যা করতে পারে — WebP-ই নিরাপদ পছন্দ।
• মাপ: ৮০০ পিক্সেল চওড়া জায়গার জন্য ৪০০০ পিক্সেলের ছবি আপলোড করবেন না। ব্রাউজারকে পুরোটা নামিয়ে তারপর ছোট করতে হয় — ডেটা আর সময় দুটোই নষ্ট। ওয়ার্ডপ্রেস নিজে থেকেই কয়েকটা সাইজ বানায়, srcset ঠিকমতো কাজ করলে ফোন ছোট ভার্সনটাই নেয়।
• ডেলিভারি: স্ক্রলের নিচের ছবিতে লেজি-লোড দিন, কিন্তু উপরের হিরো ইমেজে কক্ষনো না — ওটাতে বরং fetchpriority="high" দিন। আর প্রতিটা ছবিতে width আর height লিখে দিন; এই এক লাইনেই CLS-এর অর্ধেক সমস্যা মিটে যায়।

টুল হিসেবে ShortPixel (মাসে ১০০ ছবি ফ্রি), Imagify, বা হাতে করতে চাইলে Squoosh। আমাদের দোকানটার ২২০টা প্রোডাক্ট ছবির গড় ছিল ৩৮০ কিলোবাইট; WebP-তে নেমে দাঁড়াল ৭৪ কিলোবাইট। ক্যাটাগরি পাতার ওজন ১.৯ মেগাবাইট থেকে ৪৮০ কিলোবাইটে নামল। কোনো ডিজাইন বদলাতে হয়নি।

ধাপ তিন: যে থার্ড-পার্টি স্ক্রিপ্টগুলোর কথা আপনি ভুলে গেছেন

এটা সবচেয়ে অবহেলিত ধাপ, অথচ প্রায়ই সবচেয়ে বড় লাভ এখানেই। ওই দোকানটায় চালু ছিল: ফেসবুক পিক্সেল, GA4, গুগল ট্যাগ ম্যানেজার (যেটা আবার নিজের ভেতর দিয়ে ফেসবুক পিক্সেলটা দ্বিতীয়বার লোড করছিল), একটা লাইভ চ্যাট উইজেট, একটা হিটম্যাপ টুল আর একটা কারেন্সি কনভার্টার। সব মিলিয়ে ৭৮০ কিলোবাইট জাভাস্ক্রিপ্ট আর প্রায় ২ সেকেন্ড মেইন-থ্রেড টাইম — যার কোনোটাই কাস্টমার দেখেও না।

আমরা যা করলাম: ডুপ্লিকেট পিক্সেলটা মুছলাম, চ্যাট উইজেটটা এমনভাবে সেট করলাম যাতে ইউজার স্ক্রল বা ক্লিক করার আগে সেটা লোডই না হয়, আর হিটম্যাপ টুলটা বাদ দিলাম — কারণ চার মাসে কেউ একবারও ওটার রিপোর্ট খোলেনি। প্রতিটা মার্কেটিং ট্যাগের একজন মালিক থাকা উচিত আর একটা রিভিউ তারিখ থাকা উচিত। না থাকলে ওগুলো জমতেই থাকে, চিরকাল।

ধাপ চার: নিজের সাইটের অপ্রয়োজনীয় CSS ও JS ছাঁটাই

“রেন্ডার-ব্লকিং রিসোর্স সরান” সতর্কতাটার মানে হলো: ব্রাউজার কিছু আঁকার আগে কয়েকটা ফাইলের জন্য দাঁড়িয়ে আছে। সমাধান হলো জরুরি CSS ইনলাইন করা আর বাকিটা পরে লোড করা, আর জাভাস্ক্রিপ্টে defer বা async বসানো। ক্যাশ প্লাগইনগুলোতেই এই অপশনগুলো আছে।

তবে সাবধান — “Remove Unused CSS” অপশনটা স্লাইডার, ট্যাব বা পপআপ ভেঙে দিতে পারে, কারণ ওগুলোর CSS পাতা লোড হওয়ার সময় ব্যবহার হয় না, পরে হয়। চালু করার পর সাইটের অন্তত পাঁচটা আলাদা ধরনের পাতা নিজে হাতে ঘুরে দেখুন। আর যেসব প্লাগইন এক পাতায় দরকার অথচ সব পাতায় ফাইল ঢালছে, সেগুলোকে Perfmatters বা Asset CleanUp দিয়ে আটকান — এটা প্রায়ই ২০০-৩০০ কিলোবাইট বাঁচায়।

সৎ কথাটা হলো, Elementor বা WPBakery দিয়ে বানানো পাতা কখনোই হাতে লেখা কোডের মতো হালকা হবে না। ডিফল্ট ফন্ট আর আইকন বন্ধ করে, “Improved CSS Loading” চালু করে অনেকটা ছাঁটা যায় — কিন্তু একটা সীমা আছে। সিদ্ধান্তটা নিতে হয় সাইট বানানোর সময়, পরে না।

ধাপ পাঁচ: বাংলা ফন্ট — যেখানে দেশি সাইট সবচেয়ে বেশি ভোগে

এটা এমন একটা সমস্যা যেটা বিদেশি টিউটোরিয়ালে কেউ বলে না। SolaimanLipi, কালপুরুষ বা Hind Siliguri-র মতো একটা পূর্ণ বাংলা ফন্ট ফাইল ১৫০ থেকে ৪০০ কিলোবাইট পর্যন্ত হতে পারে — যুক্তাক্ষরের বিশাল গ্লিফ সেটের কারণে। একই মানের একটা ইংরেজি ফন্ট ২০-৩০ কিলোবাইট।

করণীয় সহজ: ফন্টটা নিজের সার্ভারে রাখুন (গুগল ফন্ট থেকে আনলে বাড়তি DNS আর TLS হ্যান্ডশেক লাগে), woff2 ফরম্যাট ব্যবহার করুন, CSS-এ font-display: swap দিন যাতে ফন্ট নামার আগেও লেখা দেখা যায়, আর শুধু যে ওয়েটটা আসলে ব্যবহার করছেন সেটাই লোড করুন। চারটা ওয়েট লোড করে দুটো ব্যবহার করা মানে বিনা কারণে অর্ধেক ওজন বয়ে বেড়ানো।

ধাপ ছয়: ডেটাবেস, যেটা কেউ কোনোদিন খুলে দেখে না

ওয়ার্ডপ্রেসের wp_options টেবিলে autoload করা ডেটা প্রতিটা রিকোয়েস্টে লোড হয় — প্রতিটা, ব্যতিক্রম ছাড়া। মুছে ফেলা প্লাগইনের ফেলে যাওয়া সেটিংস, পুরোনো transient, বছরের পর বছর জমা রিভিশন — সব মিলিয়ে এই টেবিল কয়েক মেগাবাইট হয়ে যায়, আর প্রতিটা পাতা লোডে সেটা টানতে হয়। ২ মেগাবাইট autoload ডেটা সহজেই TTFB-তে ১৫০-৩০০ মিলিসেকেন্ড যোগ করে দেয়।

WP-Optimize বা Advanced Database Cleaner দিয়ে transient মুছুন, রিভিশন ৫টায় সীমিত করুন (wp-config.php-তে এক লাইন), আর মুছে ফেলা প্লাগইনের অনাথ সারিগুলো পরিষ্কার করুন। ব্যাকআপ ছাড়া এই কাজে হাত দেবেন না — এটা একমাত্র ধাপ যেখানে ভুল হলে ফেরার পথ থাকে না।

যে প্রশ্নগুলো এখনো বাকি থেকে যায়

বাজেট ৳৫,০০০ — সবচেয়ে বেশি লাভ কোথায় পাব?

হোস্টিং। প্রায় সবসময়ই হোস্টিং। একটা ভালো LiteSpeed শেয়ার্ড প্ল্যান বা ছোট VPS-এ সরে গিয়ে তারপর ফ্রি LiteSpeed Cache ঠিকভাবে কনফিগার করলে আপনি বেশিরভাগ পেইড অপটিমাইজেশন সার্ভিসের চেয়ে বেশি ফল পাবেন। বাকি টাকা দিয়ে ছবিগুলো একবার ভালোভাবে WebP-তে নিয়ে যান। এই দুটোতেই সাধারণত মোট উন্নতির ৭০ শতাংশ চলে আসে।

সব করার পরেও মোবাইলে স্কোর কম কেন?

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

অপটিমাইজ করতে গিয়ে সাইট ভেঙে গেলে কী করব?

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

কত দিন পরপর এসব আবার করতে হবে?

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

শেষে

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