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