শেয়ার্ড হোস্টিংয়ে WordPress সাইট দ্রুত করবেন যেভাবে

শেয়ার্ড হোস্টিংয়ে ধীর WordPress সাইটের পেছনে কখনোই একটামাত্র কারণ থাকে না। সাধারণত চারটি কারণ থাকে, আর সেগুলো একে অন্যের ওপর চাপ বাড়ায়: পেজ ক্যাশ নেই, PHP-র পুরোনো ভার্সন, ফোনের ক্যামেরা থেকে সরাসরি তোলা ছবি, আর ২০১৯ সালের পর কেউ পরিষ্কার করেনি এমন একটা ডেটাবেস।

বেশিরভাগ স্পিড গাইডের সমস্যা হলো, সেগুলো সম্ভাব্য সব সমাধান এমনভাবে সাজায় যেন প্রতিটির গুরুত্ব সমান। সমান নয়। পেজ ক্যাশ চালু করলে লোড টাইম ৮০% পর্যন্ত কমতে পারে; একটা ফন্ট ডিফার করলে বাঁচে ৪০ মিলিসেকেন্ড। অথচ দুটোই কোথাও না কোথাও "টিপ #৭" হিসেবে থাকে।

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

আগে মাপুন — ঠিকভাবে

কিছু বদলানোর আগে দুটো সংখ্যা হাতে নিন।

Time to First Byte (TTFB) সার্ভারের দায়িত্ব। নিজের হোমপেজে চালান:

curl -o /dev/null -s -w "ttfb: %{time_starttransfer}s  total: %{time_total}s\n" https://yoursite.com/

পাঁচবার চালান। সেরাটা নয়, মধ্যমান নিন। ২০০ মিলিসেকেন্ডের নিচে হলে ভালো, ২০০–৫০০ হলে ঠিক করা যায়, ৮০০-র ওপরে মানে সার্ভার প্রতিটি রিকোয়েস্টে অনেক বেশি কাজ করছে — যেটার সমাধান ১ থেকে ৩ নম্বর ধাপে।

Largest Contentful Paint (LCP) হলো ভিজিটর যা অনুভব করেন। এটি PageSpeed Insights থেকে নিন, আর field data অংশটা দেখা গেলে সেটাই পড়ুন — ওটাই আসল ভিজিটরের ডেটা, ল্যাব সিমুলেশন নয়। ল্যাব স্কোর ডায়াগনস্টিক হিসেবে কাজের, লক্ষ্যমাত্রা হিসেবে বাজে।

একটা সতর্কতা: প্রতিবার একই পেজ পরীক্ষা করুন, লগআউট অবস্থায়, প্রাইভেট উইন্ডোতে। লগইন করা ব্যবহারকারীর জন্য WordPress পেজ ক্যাশ এড়িয়ে যায়, তাই অ্যাডমিনে লগইন করে পরীক্ষা করলে আপনি এমন একটা সাইট মাপছেন যা আর কেউ ব্যবহার করছে না।

ধাপ ১ — পেজ ক্যাশ চালু করুন

আপনার হাতে থাকা সবচেয়ে বড় পরিবর্তন এটাই, আর অনেক সাইটে এটাই একমাত্র যেটা গুরুত্বপূর্ণ।

ক্যাশ ছাড়া প্রতিটি ভিজিটে PHP চলে, MySQL-এ কয়েক ডজন কোয়েরি হয়, পেজ বানানো হয় আর পাঠানো হয়। ক্যাশ থাকলে প্রথম ভিজিটে এসব হয়, আর পরের প্রতিটি ভিজিট পায় জমা রাখা একটা HTML ফাইল। কাজের পরিমাণ প্রায় শূন্যে নেমে আসে।

কোন প্লাগইন লাগবে সেটা নির্ভর করে আপনার হোস্ট কী চালায় তার ওপর — আর এই জায়গাটাই বেশিরভাগ গাইড ভুল করে:

কোনটা আছে জানবেন যেভাবে: cPanel-এ লেখা থাকবে, অথবা curl -I https://yoursite.com/ চালিয়ে server হেডারটি দেখুন।

গুরুত্বপূর্ণ বিষয়: LiteSpeed Cache তার আসল পারফরম্যান্স দেয় কেবল LiteSpeed সার্ভারেই। Apache-তে বসালে এটি সাধারণ PHP-স্তরের ক্যাশিংয়ে নেমে আসে, তখন এটি আর দশটা প্লাগইনের মতোই। কোনো গাইড এই কথাটা না বলে এটিকে সবচেয়ে দ্রুত প্লাগইন বললে, তারা সেটি পরীক্ষা করে দেখেনি।

শেয়ার্ড হোস্টিংয়ে ডিফল্ট থেকে দুটো সেটিং বদলানো দরকার:

• ক্রলার বন্ধ রাখুন। এটি ব্যাকগ্রাউন্ডে নিজের সাইটেই সত্যিকারের HTTP রিকোয়েস্ট পাঠিয়ে ক্যাশ গরম রাখে, যা ঠিক সেই CPU আর এন্ট্রি-প্রসেস বাজেটই খরচ করে যেটিতে আপনার প্যাকেজের সীমা আছে।
• কার্ট, চেকআউট ও অ্যাকাউন্ট পেজ বাদ দিন, যদি WooCommerce চালান। ওগুলো ক্যাশ করলে এক ক্রেতাকে আরেক ক্রেতার ঝুড়ি দেখানো হয়।

ধাপ ২ — PHP আপডেট করুন

WordPress চলে PHP-তে, আর PHP নাটকীয়ভাবে দ্রুত হয়েছে। যে সাইটগুলো এখনো PHP 7.4-এ চলছে, তারা একই হার্ডওয়্যারে একই কোডে PHP 8.3-এর তুলনায় প্রায় অর্ধেক পারফরম্যান্স হাতছাড়া করছে।

cPanel-এ MultiPHP Manager বা Select PHP Version খুঁজুন। বদলান, তারপর গুরুত্বপূর্ণ প্রতিটি পেজ আর অ্যাডমিন লোড করে দেখুন।

দুটি নিয়ম মানলে এটি নিরাপদ:

1. একবারে এক ভার্সন এগোন, মাঝে পরীক্ষা করুন। 7.4 → 8.0 → 8.1, সরাসরি 7.4 → 8.3 নয়।
2. কীভাবে ফিরে আসবেন সেটা জেনে রাখুন। সিলেক্টর কয়েক সেকেন্ডে ফিরিয়ে দেয়, আর ঠিক এ কারণেই সিলেক্টরবিহীন হোস্ট একটা সমস্যা।

কিছু ভাঙলে সেটা প্রায় সবসময়ই পরিত্যক্ত কোনো প্লাগইন। সেই প্লাগইন যেকোনোভাবেই একদিন ভাঙত, আর এখন অন্তত জানলেন কোনটা।

ওখানে থাকতে থাকতেই OPcache চালু করুন, যদি হোস্ট সেটিংটি দেয়। এটি কম্পাইল করা PHP মেমোরিতে রাখে, প্রতিটি রিকোয়েস্টে আবার কম্পাইল করে না — বিনা খরচে পাওয়া গতি।

ধাপ ৩ — ছবিগুলো ঠিক করুন

বেশিরভাগ WordPress সাইটে পেজের ওজনের সিংহভাগ ছবি, আর সাধারণ কারণ হলো কেউ ফোন থেকে ৪ মেগাবাইটের, ৬০০০ পিক্সেল চওড়া একটা ছবি এমন জায়গায় আপলোড করেছেন যেখানে সেটি ৮০০ পিক্সেলে দেখানো হয়।

তিনটি কাজ, এই ক্রমে:

1. আপলোডের আগেই রিসাইজ করুন। বাইট না পাঠানোর চেয়ে ভালো কিছু নেই। থিমের সবচেয়ে চওড়া জায়গা ১৬০০ পিক্সেল হলে কোনো ছবিরই তার বেশি চওড়া হওয়ার দরকার নেই।
2. WebP বা AVIF দিন। একই দৃশ্যমান মানে এগুলো JPEG-এর চেয়ে ২৫–৫০% ছোট। বেশিরভাগ ক্যাশিং প্লাগইন নিজে থেকেই রূপান্তর করে দেয় — LiteSpeed Cache আর প্রচলিত ইমেজ প্লাগইনগুলো সবই পারে।
3. স্ক্রিনের নিচের ছবিগুলো লেজি-লোড করুন — WordPress এখন নিজেই করে — কিন্তু LCP ছবিটি স্পষ্টভাবে বাদ দিন। হিরো ছবিটি লেজি-লোড করা মানে LCP ঠিক যেটা মাপে সেটাকেই দেরি করানো, আর ভালো উদ্দেশ্যে করা অপ্টিমাইজেশন এভাবেই সবচেয়ে বেশি স্কোর খারাপ করে।

"মিডিয়া লাইব্রেরির ১০,০০০ ছবি অপ্টিমাইজ করুন" ধাপটা প্রথম তিনটির আগে করবেন না। ওই ছবিগুলোর বেশিরভাগই এমন কোনো পেজে নেই যেখানে কেউ যায়।

ধাপ ৪ — ডেটাবেস পরিষ্কার করুন

WordPress ডিফল্টভাবে প্রতিটি পোস্টের প্রতিটি রিভিশন চিরকাল জমিয়ে রাখে। দুইশ বার সম্পাদনা করা একটি পেজ মানে দুইশটি রো, আর wp_options-এ জমতে থাকে কখনো ইনস্টল করা প্রতিটি প্লাগইনের অনাথ রো।

এখানে সবচেয়ে কার্যকর সমাধানটি wp-config.php-তে এক লাইন:

define( 'WP_POST_REVISIONS', 5 );

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

আগে ব্যাকআপ নিন। এই তালিকার একমাত্র ধাপ যেটি সত্যিই সাইট ধ্বংস করতে পারে সেটি ডেটাবেস পরিষ্কার করা, আর প্লাগইনের "অপ্টিমাইজ" বোতাম সবসময় ফেরানো যায় না।

বিশেষ করে একটা জিনিস খুঁজবেন: অটোলোডেড অপশন। wp_options-এ autoload চিহ্নিত প্রতিটি রো প্রতিটি রিকোয়েস্টে মেমোরিতে ওঠে। কোনো প্লাগইন সেখানে বড় কিছু জমা করলে সাইটের প্রতিটি পেজ ভিউয়ে তার দাম দিতে হয়। সবচেয়ে বড়গুলো phpMyAdmin-এ খুঁজে পাবেন:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options WHERE autoload = 'yes'
ORDER BY size DESC LIMIT 20;

এই তালিকায় কয়েকশ কিলোবাইটের বেশি যা কিছু, তা খতিয়ে দেখার মতো।

ধাপ ৫ — প্লাগইন যাচাই করুন

সংখ্যা নয় — খরচ। ভালোভাবে লেখা ত্রিশটি প্লাগইন খারাপ তিনটির চেয়ে সস্তা হতে পারে।

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

সচরাচর অপরাধীরা: পেজ বিল্ডার, স্লাইডার, প্রতিটি লোডে ইনডেক্সহীন কোয়েরি চালানো রিলেটেড-পোস্ট প্লাগইন, প্রতিটি পেজ ভিউয়ে ডেটাবেসে লেখা স্ট্যাটিসটিক্স প্লাগইন, আর পেজ রেন্ডারের সময় বাইরের এপিআই-তে কল করা যেকোনো কিছু।

শেষেরটির ক্ষেত্রে ফিচার বাদ না দিয়ে কাজটা WP-Cron-এ সরিয়ে দেওয়াই সাধারণত সমাধান।

ধাপ ৬ — সামনে একটি সিডিএন বসান

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

Cloudflare-এর ফ্রি প্যাকেজই এখানে যথেষ্ট। শেয়ার্ড হোস্টিংয়ে Cloudflare গাইডে সেটআপ আছে, সঙ্গে সেই দুটি সেটিংও যেগুলোর কারণে মানুষ যেসব সমস্যার জন্য Cloudflare-কে দোষ দেয় তার বেশিরভাগ ঘটে।

যে তিনটি সমাধান শেয়ার্ড হোস্টিংয়ে কিছুই করে না

যে সময়টা নষ্ট হলো না, সেটাও বাঁচানো সময়।

• "PHP মেমোরি লিমিট ১ জিবি করে দিন।" মেমোরি এরর না পেলে এতে কিছুই বদলায় না। মেমোরি লিমিট একটা সর্বোচ্চ সীমা, বরাদ্দ নয়।
• Redis বা Memcached দিয়ে অবজেক্ট ক্যাশিং। চমৎকার পরামর্শ — ভিপিএসের জন্য। বেশিরভাগ শেয়ার্ড প্যাকেজে এর কোনোটিই থাকে না, আর ভাগাভাগি করা ডিস্কে ফাইল-ভিত্তিক অবজেক্ট ক্যাশ অবজেক্ট ক্যাশ না থাকার চেয়েও ধীর হতে পারে।
• প্রথমেই "দ্রুততর" থিমে চলে যাওয়া। ভারী থিম সত্যিই সমস্যা, কিন্তু সাইট নতুন করে বানানো বড় কাজ আর ফলাফল বুঝতে অনেক সময় লাগে। আগে ১ থেকে ৪ ধাপ করুন; বেশ প্রায়ই দেখা যায় থিমটা আসলে সমস্যা ছিল না।

কখন দোষটা সাইটের নয়, হোস্টের

পেজ ক্যাশ কাজ করছে নিশ্চিত হওয়ার পরেও TTFB বেশি থাকলে বাধাটা সার্ভারেই। বোঝার দুটি উপায়:

• রাত ৪টায় TTFB ঠিক, রাত ৯টায় ভয়াবহ। মেশিনটি ওভারসোল্ড। কোনো প্লাগইন এটা ঠিক করবে না।
• ক্যাশ করা স্ট্যাটিক HTML পেজও ধীর। আপনার কিছুই চলছে না। তাহলে সমস্যা সার্ভারে বা নেটওয়ার্কে।

দ্বিতীয়টির কারণ প্রায়ই চাপ নয়, দূরত্ব। যুক্তরাষ্ট্রের সার্ভার ঢাকার ভিজিটরকে সেবা দিলে প্রতিটি রিকোয়েস্টে পুরো একটা আন্তমহাদেশীয় রাউন্ড ট্রিপের দাম দিতে হয়, আর আমাদেরগুলো ঢাকায় BDIX-সংযুক্ত সার্ভারে চলে — বাংলাদেশি ভিজিটরের জন্য এটাই ৩০ মিলিসেকেন্ড আর ৩০০ মিলিসেকেন্ডের পার্থক্য। আপনার অডিয়েন্স বাংলাদেশি হলে আর হোস্ট না হলে, ওই একটি পরিবর্তনই এই পাতার সব অপ্টিমাইজেশন একসঙ্গে করার চেয়ে বেশি কাজে দেবে।

কাজের বাস্তব ক্রম

সাধারণ একটি ধীর WordPress সাইটে সময়টা আসলে যেভাবে খরচ হয়:

প্রতিটির পর মেপে দেখুন। TTFB ২০০ মিলিসেকেন্ডের নিচে আর LCP ২.৫ সেকেন্ডে নেমে এলে কাজ শেষ — এর পরের কাজে যে ফল পাবেন, বিকেলটা অন্য প্রায় যেকোনো কাজে দিলে তার চেয়ে বেশি পেতেন। আর কাজটা যদি নিজের বিকেল দিয়ে করতেই না চান, তাহলে নিজে না করে হাতে তুলে দিতে চাইলে আমরা এই কাজটাই করি।

সচরাচর জিজ্ঞাসা

ক্যাশিং প্লাগইন থাকা সত্ত্বেও আমার WordPress সাইট ধীর কেন? সাধারণত ক্যাশটি আসলে কাজ করছে না। লগআউট অবস্থায় প্রাইভেট উইন্ডোতে দেখুন — লগইন করা ব্যবহারকারীর জন্য WordPress ক্যাশ এড়িয়ে যায়, তাই অ্যাডমিন ক্যাশহীন সাইট দেখে ভাবেন কিছুই বদলায়নি। এছাড়া দেখুন প্লাগইনটি আপনার সার্ভারের সঙ্গে মেলে কি না: Apache হোস্টে LiteSpeed Cache তার ক্ষমতার সামান্য অংশই কাজে লাগায়।

প্লাগইনের সংখ্যা কি WordPress ধীর করে? সরাসরি নয়। খরচটা প্রতি রিকোয়েস্টে তারা কী করে তাতে, কয়টা আছে তাতে নয়। সংখ্যা দেখে মোছার বদলে Query Monitor দিয়ে ব্যয়বহুলগুলো খুঁজুন।

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

WordPress-এর জন্য ভালো TTFB কত? ২০০ মিলিসেকেন্ডের নিচে ভালো, আর ক্যাশিংসহ শেয়ার্ড হোস্টিংয়েই তা সম্ভব। ২০০–৫০০ চলনসই। নিয়মিত ৮০০-র ওপরে মানে হয় কোনো ক্যাশ চলছে না, নয়তো সার্ভার অতিরিক্ত চাপে আছে বা ভিজিটরদের থেকে অনেক দূরে।

PHP আপডেট করলে কি সাইট ভেঙে যাবে? যেতে পারে, আর সবসময়ই পরিত্যক্ত কোনো প্লাগইনের কারণে। একবারে এক ভার্সন এগোন, অ্যাডমিন ও গুরুত্বপূর্ণ পেজগুলো পরীক্ষা করুন, আর দরকার হলে PHP ভার্সন সিলেক্টর দিয়ে ফিরে আসুন। যে প্লাগইন সমর্থিত PHP ভার্সনে চলে না, গতির প্রশ্ন বাদ দিলেও সেটি একটি নিরাপত্তা সমস্যা।