হোস্টিং এবং পারফরম্যান্স
আমরা যেভাবে WordPress দ্রুত করি: LiteSpeed Enterprise, LSCache এবং প্রতি-সাইট Redis
দ্রুততম WordPress অনুরোধ হলো সেটি যা কখনো রান করে না—এখানে দেওয়া হলো কীভাবে আমাদের স্ট্যাক PHP বা MySQL সক্রিয় হওয়ার আগেই ক্যাশ থেকে বেশিরভাগ ভিজিটের উত্তর দেয়, এবং Core Web Vitals-এর জন্য এর অর্থ কী।
সবচেয়ে দ্রুতগতির অনুরোধ হলো সেটি যা কখনো চালুই হয় না
একটি সাধারণ WordPress অনুরোধ বেশ ব্যয়বহুল। ওয়েব সার্ভার পিএইচপি-র (PHP) কাছে দায়িত্ব হস্তান্তর করে, পিএইচপি WordPress চালু করে, প্লাগইনগুলো চালায়, বেশ কয়েকবার MySQL-এ কুয়েরি করে, এইচটিএমএল (HTML) একত্রিত করে এবং তারপরেই কেবল বাইট ফেরত পাঠায়। একটি ব্যস্ত সাইটে প্রতিটি দর্শকের জন্যই পুরো প্রক্রিয়াটি ঘটে, এবং আপনার টাইম-টু-ফার্স্ট-বাইট-এর (time-to-first-byte) প্রায় পুরোটাই এখানেই ব্যয় হয়।
আমাদের সমাধান হলো এটি নিশ্চিত করা যে, বেশিরভাগ ভিজিটের ক্ষেত্রে এর কোনোটিই ঘটে না। আমরা যে সাইটগুলি হোস্ট করি — ১,০০,০০০-এর বেশি PBN সাইট এবং মূলধারার ম্যানেজড WordPress সহ — তার ফ্রন্ট-এন্ড পেজ ভিউয়ের একটি বড় অংশ সরাসরি ক্যাশ থেকে প্রি-রেন্ডার করা সম্পূর্ণ পেজ হিসেবে পরিবেশন করা হয়, যেখানে পিএইচপি (PHP) বা ডাটাবেস ব্যবহারের প্রয়োজন হয় না। এই পোস্টের বাকি অংশে আলোচনা করা হয়েছে কীভাবে এই স্তরগুলো একসাথে কাজ করে এবং প্রতিটি স্তর কীভাবে তার গুরুত্ব প্রমাণ করে।
গুরুত্বপূর্ণ বিষয়টি হলো এগুলো কোনো প্রতিযোগী ক্যাশ নয় যে আপনাকে যেকোনো একটি বেছে নিতে হবে। ফুল-পেজ ক্যাশ, অবজেক্ট ক্যাশ এবং সিডিএন এজ—প্রত্যেকেই ভিন্ন ধরনের অনুরোধ ক্যাশ করে, এবং আসল সুবিধা নিহিত রয়েছে একটি থেকে অন্যটিতে কীভাবে ডেটা হস্তান্তরিত হয় তার মধ্যে।
LiteSpeed Enterprise + LSCache: দ্য ফুল-পেজ লেয়ার
প্রতিটি সাইট সার্ভার-স্তরের LSCache সহ LiteSpeed Enterprise-এ চলে। যখন কোনো ফ্রন্ট-এন্ড রেসপন্স ক্যাশ করার যোগ্য হয়, তখন ওয়েব সার্ভার এটিকে LiteSpeed cache-control এবং tag হেডার দিয়ে চিহ্নিত করে, এবং পরবর্তী হিটে LiteSpeed সরাসরি সম্পূর্ণ পেজ পরিবেশন করে—কোনো PHP প্রসেস স্পন করা হয় না, কোনো MySQL কুয়েরি চালানো হয় না। WordPress TTFB-এর ক্ষেত্রে এটি সবচেয়ে বড় চালিকাশক্তি, কারণ এটি হট পাথ থেকে পুরো অ্যাপ্লিকেশন বুট সরিয়ে দেয়।
যেহেতু LSCache পিএইচপি প্লাগইনের পরিবর্তে সরাসরি ওয়েব সার্ভারের ভেতরে কাজ করে, তাই এটি অনুরোধের জীবনচক্রের (request lifecycle) অনেক আগেই কাজ শুরু করে এবং সার্ভার যাতে তাৎক্ষণিকভাবে ফ্লাশ করতে পারে এমন একটি ফর্মে পেজগুলোকে ধরে রাখে। একটি ক্যাশ ক্রলার জনপ্রিয় পেজগুলোকে সক্রিয় রাখে, যার ফলে ক্যাশ মুছে ফেলার (purge) পর প্রথম ভিজিটরকে পেজটি আবার তৈরি করার জন্য অপেক্ষা করতে হয় না। এর ফলাফল হলো সাধারণ স্ট্যাকের সাথে যুক্ত শুধুমাত্র প্লাগইন-ভিত্তিক ক্যাশের তুলনায় উল্লেখযোগ্যভাবে কম এবং আরও স্থিতিশীল TTFB, যেখানে ক্যাশটি এখনও পিএইচপি-র পেছনেই অবস্থান করে।
আমাদের নিজস্ব রিপো-গ্রেড ক্যাশ প্লাগইনটি প্রতিটি সাইটে প্রি-ইনস্টল করা এবং অটো-আপডেটেড হিসেবে থাকে, যা WordPress-কে শুরু থেকেই সঠিকভাবে LSCache-এর সাথে সংযুক্ত করে। কোনো নন-LiteSpeed অরিজিনে এটি কেবল কোনো ফুল-পেজ হেডার নির্গমন করে না এবং পথ থেকে সরে দাঁড়ায়, অন্যদিকে অবজেক্ট ক্যাশ এবং এক্সক্লুশন রুলস তাদের কাজ চালিয়ে যায়—তাই একটি মাইগ্রেট করা সাইট কখনো ভাঙা বা অর্ধেক কনফিগার করা অবস্থায় পড়ে থাকে না।
পুরানো কন্টেন্ট পরিবেশন না করে দ্রুত গতি বজায় রাখা: ইএসআই এবং স্মার্ট অটো-পার্জ
এগ্রেসিভ ফুল-পেজ ক্যাচিংয়ের দুটি ক্লাসিক ফেইলিওর মোড রয়েছে: লগইন করা কোনো ব্যবহারকারীকে অন্য কারও পেজ দেখানো এবং যেকোনো ব্যবহারকারীকে এমন একটি পেজ দেখানো যা পরিবর্তন হওয়া উচিত ছিল। কম ক্যাচ করার পরিবর্তে ক্যাচিং স্তরেই এই দুটির সমাধান করা হয়।
ESI (Edge Side Includes) আমাদের পেজ ক্যাশ করার সুযোগ দেয় এবং সেই সাথে যে অংশগুলো লাইভ রাখতে হবে সেগুলোর জন্য ফাঁকা স্থান বা হোল তৈরি করে। একটি WooCommerce স্টোরে ক্যাটালগ, পণ্য এবং ক্যাটেগরি পেজগুলোকে সম্ভাব্য দ্রুততম TTFB-এর জন্য ফুল-পেজ ক্যাশ হিসেবে পরিবেশন করা হয়, অন্যদিকে ESI প্রতিটি অনুরোধের বিপরীতে কার্ট ফ্রাগমেন্ট, মিনি-কার্ট মোট এবং অ্যাকাউন্টের স্থিতি রেন্ডার করে। কার্ট, চেকআউট, my-account এবং যেকোনো নন্স বা সেশন পেজ ডিফল্টভাবে বাদ দেওয়া হয়। ক্রেতারা সবসময় তাদের নিজস্ব ঝুড়ি এবং একটি কার্যকর চেকআউট দেখতে পান; আর সবাই ক্যাশ থেকে স্টোরফ্রন্ট পেতে থাকে।
স্মার্ট অটো-পার্জের মাধ্যমে ফ্রেশনেশ হ্যান্ডেল করা হয়। কন্টেন্ট, প্রোডাক্ট, দাম বা অর্ডার পরিবর্তিত হলে পার্জ হুকগুলো স্বয়ংক্রিয়ভাবে ট্রিগার হয়, যাতে টাইমারের ওপর নির্ভর না করে সংশ্লিষ্ট ক্যাশ করা পেজগুলো সাথে সাথে রিফ্রেশ হয়ে যায় এবং আপনি ড্যাশবোর্ড থেকে বা WordPress-এর ভেতর থেকেও অন-ডিমান্ড পার্জ করতে পারবেন। ট্যাগ-ভিত্তিক পার্জিংয়ের অর্থ হলো একটি পোস্ট এডিট করলে শুধুমাত্র সেই পোস্ট এবং এর আর্কাইভগুলো ক্লিয়ার হয়—পুরো ক্যাশ নয়—ফলে একটিমাত্র এডিটের কারণে পুরো সাইট কোল্ড-স্টার্ট হয় না।
প্রতি-সাইট Redis অবজেক্ট ক্যাশ: যা সম্পূর্ণ পৃষ্ঠা হতে পারে না তার জন্য
প্রতিটি অনুরোধ স্ট্যাটিক পূর্ণ পৃষ্ঠা হতে পারে না। লগ-ইন করা সেশন, WordPress অ্যাডমিন, WooCommerce কার্ট, সার্চ এবং ESI-এর রেখে যাওয়া ডায়নামিক অংশ—এসবের প্রতিটিতেই পিএইচপি (PHP) চালাতে হয়। সেগুলোর ক্ষেত্রে লক্ষ্য 'অ্যাপ্লিকেশন বাদ দেওয়া' থেকে পরিবর্তন হয়ে 'ডেটাবেজ বাদ দেওয়া' হয়ে যায়।
প্রতিটি সাইটের জন্য নিজস্ব ডেডিকেটেড Redis অবজেক্ট ক্যাশ রয়েছে। WordPress বারবার ডেটাবেস রিডের ফলাফল—অপশন, ট্রানজিয়েন্ট, পোস্ট এবং টার্ম লুকআপ, WooCommerce প্রোডাক্ট এবং সেশনের ডেটা—মেমরিতে ক্যাশ করে রাখে, ফলে প্রতিবার ভিজিটে MySQL-এ একই কুয়েরি চালাতে হয় না। পূর্ণ-পৃষ্ঠার ক্যাশ যেখানে কাজ করে না, ঠিক সেখানেই এর প্রভাব সবচেয়ে বেশি স্পষ্টভাবে দৃশ্যমান হয়: দ্রুতগতির ড্যাশবোর্ড, দ্রুতগতির কার্ট এবং ট্রাফিকের সময় ডেটাবেসের ওপর অনেক কম লোড।
অবজেক্ট ক্যাশটি প্রতি সাইটের জন্য আলাদা, শেয়ার করা নয়, যা কার্যক্ষমতা এবং আইসোলেশন উভয় ক্ষেত্রেই গুরুত্বপূর্ণ। প্রতি সাইটের ডেটাবেস থ্রোটলিংয়ের সাথে মিলিত হয়ে, একটি সাইটের ভারী বা ত্রুটিপূর্ণ কুয়েরিগুলো আশেপাশের সাইটগুলোর জন্য ডেটাবেসকে অচল করে দিতে পারে না। আমাদের ক্যাশিং ফিচার পেজে এই পুরো মাল্টি-লেয়ার সেটআপটি কীভাবে কাজ করে সে সম্পর্কে এবং আইসোলেশনের অধীনে টেন্যান্টদের মধ্যকার সীমানা সম্পর্কে আপনি আরও জানতে পারবেন।
এজ এবং এর নিচের ট্রান্সপোর্ট
অরিজিনে থাকা ক্যাশকে এখনও নেটওয়ার্ক পার হতে হয়। সার্ভারের সামনে রয়েছে সিডিএন এজ, তাই স্ট্যাটিক সম্পদ এবং ক্যাশ করার উপযোগী পেজগুলো ভিজিটরের কাছাকাছি কোনো পয়েন্ট অব প্রেজেন্স থেকে পরিবেশন করা হয়, এবং লোডের মধ্যেও অরিজিন শান্ত থাকে। আমাদের ফুটপ্রিন্ট-মুক্ত হোস্টিং লাইনের জন্য একই এজ হলো একটি মাল্টি-সিডিএন পুল যা বেশ কয়েকটি প্রদানকারীর মধ্যে বিস্তৃত, যা পারফরম্যান্সের পাশাপাশি একটি ফুটপ্রিন্ট লক্ষ্য পূরণ করে; মূলধারার WordPress-এ এটি কেবল একটি দ্রুত, সুশৃঙ্খল লেয়ার যা অরিজিনগুলোকে নিষ্ক্রিয় রাখে।
এর নিচে, মৌলিক বিষয়গুলোতে কোনো কার্পণ্য করা হয় না। সাইটগুলো NVMe স্টোরেজ ও HTTP/3-এর মাধ্যমে চলে, ফলে ক্যাশে যে বাইটগুলো পাঠায় তা একটি আধুনিক, মাল্টিপ্লেক্সড ট্রান্সপোর্টের মাধ্যমে পৌঁছে যায় এবং কোনো ক্যাশে মিস হলে তার পেছনে দ্রুতগতির স্টোরেজ কাজ করে। এই স্তরগুলোর কোনোটিই অতিরিক্ত সংযোজন নয়: LiteSpeed, LSCache, প্রতি সাইটের জন্য Redis, NVMe এবং HTTP/3 প্রতিটি প্ল্যানেই মৌলিক ভিত্তি, কোনো আপসেল টায়ার নয়।
যে জিনিসগুলো আসলে Core Web Vitals-কে প্রভাবিত করে
এটি নিখুঁত হওয়া জরুরি, কারণ হোস্টিং প্রায়ই Core Web Vitals-এর ক্ষেত্রে অতিরিক্ত বিক্রি করা হয়। TTFB হলো সমীকরণের সেই অংশ যা সার্ভারের অধীনে থাকে এবং এর উপরের ক্যাশিং স্ট্যাকই এটিকে কমিয়ে আনে—এজ থেকে HTTP/3-এর মাধ্যমে পরিবেশিত একটি ক্যাশ করা পূর্ণাঙ্গ পেজের TTFB যতটা কম হতে পারে, এটি প্রায় ঠিক ততটাই কম। যেহেতু TTFB হলো Largest Contentful Paint-এর প্রধান চালিকাশক্তি, তাই একটি দ্রুত অরিজিন ডাউনস্ট্রিমের প্রতিটি মেট্রিককে এমন একটি অগ্রগামী সূচনা দেয় যা অন্যথায় পাওয়া সম্ভব নয়।
কিন্তু LCP, CLS এবং INP মূলত ব্রাউজারে, পেজ নিজেই নির্ধারণ করে: একটি অপ্টিমাইজ না করা হিরো ইমেজ, রেন্ডার-ব্লকিং CSS এবং JavaScript, ফন্ট এবং বিজ্ঞাপন লোড হওয়ার সময় লেআউট পরিবর্তন, এবং প্লাগইন থেকে ভারী মেইন-থ্রেড কাজ। কোনো পরিমাণ সার্ভার ক্যাশিং একটি ২ MB হিরো বা মেগাবাইট JavaScript পাঠানো থিম ঠিক করতে পারে না। সৎ হোস্টিং সার্ভারের অবদানকে কার্যকরভাবে বিনামূল্যে এবং সামঞ্জস্যপূর্ণ করে তোলে, এরপর ফ্রন্ট এন্ড স্লিম রাখা সাইটের ওপর নির্ভর করে।
কাজের সেই বণ্টনই হলো কার্যকর মানসিক মডেল। আমরা গ্যারান্টি দিই যে রিকোয়েস্টটি ব্রাউজারে দ্রুত পৌঁছাবে এবং ট্রাফিকের মধ্যেও দ্রুত থাকবে; আপনি পেলোড ছোট এবং স্থিতিশীল রাখবেন। যেখানে এই দুটির মিলন ঘটে — ক্যাশে ওয়ার্ম-আপ, এজ ডেলিভারি, এবং ডাটাবেসকে রেসপন্সিভ রাখা যাতে ডাইনামিক পেজগুলো আটকে না যায় — ঠিক সেখানেই আমাদের স্ট্যাক টিউন করা হয়েছে, আর এটিই এই প্ল্যাটফর্মে ম্যানেজড WordPress-কে কোনো জেনেরিক হোস্টের একই সাইটের চেয়ে দ্রুততর করে তোলে।
সচরাচর জিজ্ঞাসিত প্রশ্নাবলী
আমার কি এখনও WP Rocket-এর মতো কোনো ক্যাশিং প্লাগইনের প্রয়োজন আছে?
না। ফুল-পেজ ক্যাশিং ওয়েব সার্ভার লেভেলে LiteSpeed-এর LSCache দ্বারা পরিচালিত হয়, এবং আমাদের নিজস্ব ক্যাশ প্লাগইন — যা পূর্ব-ইনস্টল করা এবং অটো-আপডেটেড — তার পেছনে একটি পার-সাইট Redis অবজেক্ট ক্যাশ সহ সঠিক উপায়ে এটিকে WordPress-এর সাথে যুক্ত করে। এর উপরে দ্বিতীয় আরেকটি ফুল-পেজ ক্যাশিং প্লাগইন যুক্ত করা সাহায্য করার বদলে সাধারণত সার্ভার-লেভেলের ক্যাশের সাথে দ্বন্দ্ব তৈরি করে, তাই এটির প্রয়োজন নেই এবং এটি সুপারিশও করা হয় না।
ক্যাচিং কি আমার WooCommerce কার্ট বা লগ-ইন করা পৃষ্ঠাগুলো নষ্ট করে দেবে?
না। কার্ট, চেকআউট, মাই-অ্যাকাউন্ট এবং যেকোনো ননস বা সেশন পেজ ডিফল্টভাবেই ক্যাশ থেকে বাদ দেওয়া হয়, এবং ESI অন্যথায় ক্যাশ করা পেজগুলোতে কার্ট ফ্র্যাগমেন্ট এবং টোটাল লাইভ রাখে। স্টোরফ্রন্ট ক্যাশ থেকে লোড হলেও ক্রেতারা সবসময় তাদের নিজস্ব ঝুড়ি এবং কাজ করছে এমন চেকআউট দেখতে পান।
আমি যখন প্রকাশ বা সম্পাদনা করি তখন ক্যাশ কীভাবে সতেজ থাকে?
স্মার্ট অটো-পার্জ প্রাসঙ্গিক WordPress হুকগুলিতে কাজ করে, তাই কোনো কিছু প্রকাশ করা, সামগ্রী সম্পাদনা করা, বা কোনো পণ্য, মূল্য বা অর্ডার পরিবর্তন করা হলে পুরো ক্যাশের পরিবর্তে শুধুমাত্র প্রভাবিত পৃষ্ঠাগুলি এবং তাদের আর্কাইভগুলি পরিষ্কার হয়ে যায়—এবং একটি ক্রলার সেগুলোকে আবার ওয়ার্ম আপ করে। আপনি ড্যাশবোর্ড থেকে বা WordPress-এর ভেতর থেকেও চাহিদা অনুযায়ী পার্জ করতে পারেন।
শুধুমাত্র হোস্টিং কি আমাকে নিখুঁত Core Web Vitals দিতে পারে?
এটি আপনাকে সম্ভাব্য সেরা TTFB দেয়, যা সার্ভারের অংশ এবং Largest Contentful Paint-এর জন্য একটি ভালো সূচনা। তবে LCP, CLS এবং INP মূলত পেজ নিজেই নির্ধারণ করে—ছবির সাইজ, রেন্ডার-ব্লকিং অ্যাসেট, লেআউট স্থিতিশীলতা এবং মেইন-থ্রেড জাভাস্ক্রিপ্ট। আমাদের স্ট্যাক সার্ভারের অবদানকে দ্রুত এবং সামঞ্জস্যপূর্ণ করে তোলে; ফ্রন্ট-এন্ড পে লোড হালকা রাখাই বাকি ব্যবধান দূর করে।
সম্পর্কিত
১৪ দিনের জন্য বিনামূল্যে ব্যবহার করে দেখুন
আপনার প্রথম সাইটগুলো ১৪ দিনের জন্য বিনামূল্যে চালু করুন — কোনো কার্ড লাগবে না। কোনো বিদ্যমান নেটওয়ার্ক স্থানান্তর করছেন? আপনার প্রথম মাইগ্রেশন আমাদের খরচে।
বিনামূল্যে শুরু করুন