স্বাভাবিকভাবে চলার পর হঠাৎ ধীর হয়ে গেলে অনেকেই প্রথমে Cache পরিষ্কার করেন, নতুন কোনো গতি বাড়ানোর Plugin বসান অথবা Hosting প্রতিষ্ঠানকে দায়ী করেন। কখনো এসব পদক্ষেপে সাময়িক উন্নতি দেখা গেলেও মূল সমস্যাটি আড়ালেই থেকে যায়। ফলে কয়েক ঘণ্টা বা কয়েক দিন পর ওয়েবসাইট আবার ধীর হয়ে পড়তে পারে।

বাস্তবে একটি ওয়েবসাইটের গতি কমে যাওয়ার পেছনে একাধিক কারণ একসঙ্গে কাজ করতে পারে। নতুন Plugin, Theme হালনাগাদ, বড় ছবি, বিজ্ঞাপনের Script, সার্ভারের সীমাবদ্ধতা, অস্বাভাবিক Bot Traffic, Database-এর চাপ কিংবা ভুল Cache ব্যবস্থাপনা—প্রতিটি কারণের লক্ষণ আলাদা।

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

Google-এর বর্তমান Core Web Vitals ব্যবস্থায় একটি পৃষ্ঠার প্রধান বিষয়বস্তু দৃশ্যমান হওয়ার সময়, ব্যবহারকারীর কাজের প্রতি পৃষ্ঠার সাড়া এবং পৃষ্ঠার দৃশ্যগত স্থিতিশীলতা পরিমাপ করা হয়। ভালো ব্যবহারকারীর অভিজ্ঞতার জন্য Largest Contentful Paint বা LCP সাধারণত ২.৫ সেকেন্ডের মধ্যে, Interaction to Next Paint বা INP ২০০ মিলিসেকেন্ডের মধ্যে এবং Cumulative Layout Shift বা CLS ০.১ বা তার কম রাখার পরামর্শ দেওয়া হয়। তবে একটি পরীক্ষায় ভালো নম্বর পেলেই সব ব্যবহারকারীর কাছে ওয়েবসাইট দ্রুত চলছে—এমন সিদ্ধান্ত নেওয়া ঠিক নয়।

ওয়েবসাইট আসলেই ধীর, নাকি শুধু আপনার সংযোগে সমস্যা?

সমাধান শুরু করার আগে নিশ্চিত হতে হবে সমস্যাটি ওয়েবসাইটে, নাকি আপনার নিজের Internet সংযোগ, Browser অথবা Device-এ।

নিজের কম্পিউটার বা মোবাইলে ওয়েবসাইট ধীর মনে হলে অন্য একটি Internet সংযোগ ব্যবহার করে পরীক্ষা করুন। সম্ভব হলে মোবাইল ডেটা, অন্য একটি Wi-Fi সংযোগ এবং পরিচিত কারও Device থেকে একই পৃষ্ঠা খুলুন। Browser-এর ব্যক্তিগত বা Incognito অবস্থায় পরীক্ষা করলে পুরোনো Cache ও কিছু Extension-এর প্রভাব এড়িয়ে ফলাফল দেখা যায়।

এরপর ওয়েবসাইটের অন্তত তিন ধরনের পৃষ্ঠা পরীক্ষা করা প্রয়োজন:

• প্রথম পৃষ্ঠা বা Home Page
• সাধারণ একটি Article Page
• Category বা Archive Page

শুধু প্রথম পৃষ্ঠা ধীর হলে সেখানে ব্যবহৃত Slider, বড় Banner, অতিরিক্ত Post Section অথবা বিশেষ Script দায়ী হতে পারে। সব পৃষ্ঠা ধীর হলে Hosting, Database, Theme বা সার্বিক Cache ব্যবস্থায় সমস্যা থাকার সম্ভাবনা বেশি। আর শুধু একটি নির্দিষ্ট Article ধীর হলে সেই পৃষ্ঠার ছবি, Video, Table, বিজ্ঞাপন বা Embed করা বাইরের উপাদান পরীক্ষা করা উচিত।

একটি পরীক্ষার ফলাফলের ওপর নির্ভর না করে Google PageSpeed Insights বা Chrome-এর Lighthouse দিয়ে একই পৃষ্ঠা কয়েকবার পরীক্ষা করা ভালো। পরীক্ষার সময় সার্ভারের তাৎক্ষণিক চাপ, নেটওয়ার্কের অবস্থা এবং Cache তৈরি হয়েছে কি না—এসব কারণে নম্বর ওঠানামা করতে পারে। Lighthouse-এর নম্বর একটি নির্দিষ্ট পরীক্ষাগারের পরিস্থিতির ফল, আর বাস্তব ব্যবহারকারীর তথ্য আলাদা হতে পারে।

বুঝুন কোন অংশ ধীর

WordPress ওয়েবসাইটের ধীরগতি সাধারণত তিনভাবে প্রকাশ পায়।

শুধু প্রকাশিত ওয়েবসাইট ধীর

ব্যবহারকারী যে অংশ দেখেন সেটি ধীর, কিন্তু WordPress Dashboard স্বাভাবিকভাবে খুলছে—এমন হলে সাধারণত Theme, ছবি, JavaScript, CSS, বিজ্ঞাপন, Font বা বাইরের Script পরীক্ষা করতে হয়।

শুধু WordPress Dashboard ধীর

প্রকাশিত ওয়েবসাইট তুলনামূলক দ্রুত, কিন্তু Dashboard, Post Editor, Plugin Page বা Media Library খুলতে সময় নেয়—এমন হলে Database, Plugin-এর পেছনের কাজ, WordPress Cron, Backup প্রক্রিয়া অথবা Hosting-এর CPU ও Memory সীমা পরীক্ষা করা প্রয়োজন।

ওয়েবসাইট ও Dashboard দুটিই ধীর

দুই অংশই ধীর হলে Server Response, PHP কর্মক্ষমতা, Database, অতিরিক্ত Traffic, Malware বা Hosting-এর সীমাবদ্ধতার সম্ভাবনা তুলনামূলক বেশি থাকে।

এই পার্থক্যটি শুরুতেই বোঝা গেলে অপ্রয়োজনীয় অনেক পরিবর্তন এড়ানো যায়। উদাহরণ হিসেবে, শুধু Dashboard ধীর হওয়ার সমস্যায় ছবির আকার কমিয়ে লাভ হবে না। আবার শুধু একটি পৃষ্ঠার বড় ছবির কারণে ধীরগতি হলে Hosting পরিবর্তন করাও যৌক্তিক সমাধান নয়।

পরিবর্তনের আগে সম্পূর্ণ Backup রাখুন

ওয়েবসাইট দ্রুত করার কাজ শুরুর আগে Files ও Database—দুটিরই হালনাগাদ Backup রাখা প্রয়োজন। কারণ Plugin বন্ধ করা, Theme পরিবর্তন, Database পরিষ্কার করা বা PHP সংস্করণ বদলের মতো কাজে অপ্রত্যাশিত সমস্যা দেখা দিতে পারে।

শুধু Hosting প্রতিষ্ঠানের স্বয়ংক্রিয় Backup আছে ধরে নেওয়া নিরাপদ নয়। Backup কবে নেওয়া হয়েছে, কত দিনের কপি রাখা হয় এবং প্রয়োজন হলে নিজে থেকে Restore করা যাবে কি না—এসব আগে যাচাই করুন।

WordPress-এর সরকারি নির্দেশনায় নিয়মিত ও স্বয়ংক্রিয় Database Backup ব্যবস্থার কথা বলা হয়েছে। বড় পরিবর্তন বা হালনাগাদের আগে কার্যকর Backup রাখা বিশেষভাবে গুরুত্বপূর্ণ। সম্ভব হলে সরাসরি মূল ওয়েবসাইটে পরীক্ষা না করে Staging Site ব্যবহার করুন। Staging সুবিধা না থাকলে কম Traffic-এর সময়ে একটি করে পরিবর্তন করুন এবং প্রতিবার ফলাফল পরীক্ষা করুন। একসঙ্গে পাঁচটি Plugin বন্ধ করে, Theme পরিবর্তন করে এবং Cache সেটিং বদলে দিলে কোন পদক্ষেপে উন্নতি বা সমস্যা হয়েছে, তা আর বোঝা যায় না।

WordPress ওয়েবসাইটের ব্যাকআপ নেওয়া ও পুনরুদ্ধারের নিয়ম

কখন থেকে ওয়েবসাইট ধীর হয়েছে তা খুঁজুন

হঠাৎ ধীরগতির সবচেয়ে কার্যকর সূত্র হচ্ছে সময়। সমস্যাটি ঠিক কখন থেকে শুরু হয়েছে তা যতটা সম্ভব নির্দিষ্ট করুন।

নিচের ঘটনাগুলোর কোনোটি ধীরগতি শুরুর আগে ঘটেছিল কি না দেখুন:

• নতুন Plugin স্থাপন বা সক্রিয় করা
• পুরোনো Plugin বা Theme হালনাগাদ করা
• WordPress-এর মূল সংস্করণ হালনাগাদ করা
• PHP সংস্করণ পরিবর্তন করা
• বিজ্ঞাপন বা Analytics Script যুক্ত করা
• নতুন Font, Slider বা Page Builder ব্যবহার করা
• বড় ছবি বা Video প্রকাশ করা
• Cloudflare বা অন্য CDN-এর নিয়ম পরিবর্তন করা
• Hosting Package বা Server স্থানান্তর করা
• হঠাৎ Visitor বা Bot Traffic বেড়ে যাওয়া

WordPress-এর Dashboard থেকে Plugin ও Theme-এর তালিকা দেখুন। কোনটি সম্প্রতি হালনাগাদ হয়েছে তা সংশ্লিষ্ট তথ্য, Hosting-এর পরিবর্তনের তালিকা বা নিজের কাজের নোটের সঙ্গে মিলিয়ে দেখুন।

একটি গুরুত্বপূর্ণ নিয়ম হলো—সমস্যা শুরু হওয়ার কাছাকাছি সময়ে যে পরিবর্তন হয়েছে, সেটিই প্রথমে পরীক্ষা করুন। তবে প্রমাণ ছাড়া সরাসরি সেটিকে দায়ী করবেন না। একই সময়ে Server-এর চাপ বা অন্য Plugin-এর সঙ্গে অসামঞ্জস্য তৈরি হতে পারে।

WordPress Site Health পরীক্ষা করুন

WordPress Dashboard থেকে Tools → Site Health অংশে গেলে ওয়েবসাইটের বেশ কিছু গুরুত্বপূর্ণ অবস্থা দেখা যায়। এখানে ব্যবহৃত PHP সংস্করণ, Server-এর কিছু তথ্য, সক্রিয় Theme ও Plugin, Database-এর অবস্থা এবং কর্মক্ষমতার সঙ্গে সম্পর্কিত সতর্কতা পাওয়া যেতে পারে।

Site Health-এর Status অংশে জরুরি সমস্যা ও পরামর্শ দেখানো হয়। Info অংশে Server, WordPress, Theme, Plugin, Media এবং Database-সংক্রান্ত বিস্তারিত তথ্য থাকে। প্রয়োজন হলে এই তথ্য Hosting সহায়তা বিভাগ বা Developer-কে পাঠানো যায়। তবে Site Health-এ “ভালো” দেখালেই ওয়েবসাইট যে দ্রুত, তা নিশ্চিত হয় না। এটি মূলত পরিচিত Configuration ও প্রযুক্তিগত সমস্যার সতর্কতা দেয়। Theme-এর ভারী নকশা, বিজ্ঞাপনের Script বা একটি নির্দিষ্ট পৃষ্ঠার বড় ছবির মতো সব সমস্যা এখানে ধরা নাও পড়তে পারে।

Server Response Time বেশি কি না যাচাই করুন

Browser ওয়েবসাইটে অনুরোধ পাঠানোর পর Server প্রথম অংশের তথ্য পাঠাতে যে সময় নেয়, সেটি সাধারণভাবে Time to First Byte বা TTFB নামে পরিচিত। প্রথম তথ্য আসতেই দেরি হলে পরবর্তী ছবি, CSS ও JavaScript দ্রুত হলেও পৃষ্ঠা খুলতে দেরি হবে।

Google-এর কর্মক্ষমতা নির্দেশনায় ধীর LCP-এর সঙ্গে বেশি TTFB, ধীর Server, Redirect, দূরবর্তী Server এবং CDN-এর অভাবের সম্পর্ক বিবেচনা করার কথা বলা হয়েছে। Server Response ধীর হওয়ার সাধারণ কারণগুলোর মধ্যে রয়েছে :

• Shared Hosting-এ অতিরিক্ত চাপ
• CPU বা Memory ব্যবহারের সীমা অতিক্রম করা
• ধীর Database Query
• Cache না থাকা
• অদক্ষ Plugin বা Theme Code
• পুরোনো বা অসামঞ্জস্যপূর্ণ PHP সংস্করণ
• অনেক দূরের Server থেকে তথ্য আসা
• অস্বাভাবিক Bot বা আক্রমণধর্মী Traffic

Hosting নিয়ন্ত্রণপটে CPU Usage, Physical Memory, Entry Process, Disk I/O এবং Database Usage দেখার সুযোগ থাকলে সমস্যার সময়ের তথ্য পরীক্ষা করুন। কোনো একটি সীমা বারবার পূর্ণ হলে শুধু Cache পরিষ্কার করে স্থায়ী সমাধান পাওয়া যাবে না।

এ অবস্থায় Hosting সহায়তা বিভাগকে শুধু “সাইট ধীর” লিখে পাঠানোর বদলে নির্দিষ্ট তথ্য দিন। যেমন—কখন সমস্যা হয়েছে, কোন পৃষ্ঠা ধীর, Dashboard-ও ধীর কি না, Resource Limit পূর্ণ হয়েছে কি না এবং কোনো Error Log তৈরি হয়েছে কি না।

Hosting পরিবর্তনের আগে যেসব বিষয় বুঝতে হবে

একটি কমদামি Shared Hosting সবসময় খারাপ নয় এবং দামি Hosting নিলেই সব সমস্যা দূর হবে—এমনও নয়। ছোট একটি Blog ভালোভাবে তৈরি করা থাকলে মানসম্মত Shared Hosting-এ স্বাভাবিকভাবে চলতে পারে। অন্যদিকে ভারী Theme, অদক্ষ Plugin ও অপটিমাইজ না করা ছবি থাকলে VPS নিয়েও কাঙ্ক্ষিত গতি নাও পাওয়া যেতে পারে।

Hosting পরিবর্তনের সিদ্ধান্ত নেওয়ার আগে দেখুন:

• Server নিয়মিত Resource Limit-এ পৌঁছাচ্ছে কি না
• Hosting প্রতিষ্ঠান Server-level Cache দেয় কি না
• বর্তমান PHP ও Database সংস্করণ সমর্থিত কি না
• Storage SSD বা NVMe কি না
• Backup ও Restore সুবিধা কেমন
• Visitor-এর কাছাকাছি Server অবস্থান আছে কি না
• সহায়তা বিভাগ Performance সমস্যা যাচাই করে কি না

WordPress-এর সরকারি কর্মক্ষমতা নির্দেশনায় Server, Software, Theme, Plugin, Cache এবং ছবির আকার—সবগুলোকে সম্মিলিতভাবে বিবেচনা করা হয়েছে। শুধু একটি বিষয়ের ওপর পুরো গতি নির্ভর করে না।

অতিরিক্ত বা সমস্যাযুক্ত Plugin শনাক্ত করুন

WordPress ওয়েবসাইট ধীর হওয়ার আলোচিত কারণগুলোর একটি হলো Plugin। তবে শুধু Plugin-এর সংখ্যা গুনে সিদ্ধান্ত নেওয়া ঠিক নয়। ভালোভাবে তৈরি ২০টি ছোট Plugin কখনো কখনো একটি ভারী ও অদক্ষ Plugin-এর তুলনায় কম চাপ তৈরি করতে পারে।

সমস্যা হয় যখন কোনো Plugin:

• প্রতিটি পৃষ্ঠায় অপ্রয়োজনীয় Script চালায়
• অনেক Database Query তৈরি করে
• বাইরে থাকা Server থেকে তথ্য আনে
• নিয়মিত পেছনের কাজ চালায়
• বড় Log বা অস্থায়ী তথ্য জমায়
• অন্য Cache বা Security Plugin-এর সঙ্গে দ্বন্দ্ব তৈরি করে
• পুরোনো PHP বা WordPress সংস্করণের ওপর নির্ভর করে

WordPress-এর সরকারি নির্দেশনায় অপ্রয়োজনীয় Plugin নিষ্ক্রিয় ও মুছে ফেলা এবং সন্দেহভাজন Plugin একটি করে বন্ধ করে কর্মক্ষমতা পরীক্ষা করার পরামর্শ দেওয়া হয়েছে।

Plugin পরীক্ষার নিরাপদ পদ্ধতি

প্রথমে পূর্ণ Backup নিন। এরপর সাম্প্রতিক সময়ে স্থাপন বা হালনাগাদ করা Plugin দিয়ে পরীক্ষা শুরু করুন।

একবারে একটি Plugin সাময়িকভাবে বন্ধ করুন। তারপর ওয়েবসাইটের একই পৃষ্ঠা একই পদ্ধতিতে পরীক্ষা করুন। উন্নতি না হলে Plugin আবার চালু করে পরেরটি পরীক্ষা করুন।

ব্যবসায়িক বা সক্রিয় ওয়েবসাইটে সরাসরি Plugin বন্ধ করা ঝুঁকিপূর্ণ হতে পারে। বিশেষ করে Form, Membership, Ecommerce, Security বা Payment-সংক্রান্ত Plugin বন্ধ করলে গুরুত্বপূর্ণ সুবিধা সাময়িকভাবে অকার্যকর হতে পারে। এসব ক্ষেত্রে Staging Site বা নিরাপদ Troubleshooting ব্যবস্থা ব্যবহার করা উচিত।

বন্ধ করে রাখা Plugin প্রয়োজন না হলে মুছে দিন। শুধু নিষ্ক্রিয় অবস্থায় রেখে দিলে সেটি সাধারণত সামনের পৃষ্ঠায় কাজ না করলেও পুরোনো ও অনিরাপদ Plugin Files ভবিষ্যতে নিরাপত্তা ঝুঁকির কারণ হতে পারে।

ওয়ার্ডপ্রেস কী, কেন এত জনপ্রিয় এবং কেন শিখবেন

একই কাজের একাধিক Plugin ব্যবহার করবেন না

একই উদ্দেশ্যে একাধিক Cache, Security, Image Optimization বা SEO Plugin ব্যবহার করলে দ্বন্দ্ব তৈরি হতে পারে। যেমন, দুটি Cache Plugin একসঙ্গে HTML, CSS ও JavaScript পরিবর্তন করার চেষ্টা করলে নকশা ভেঙে যাওয়া, পুরোনো পৃষ্ঠা দেখা, Login সমস্যা বা অনিয়মিত গতি দেখা দিতে পারে।

একইভাবে Server-level Cache, WordPress Cache Plugin এবং CDN Cache একসঙ্গে ব্যবহার করা সম্ভব হলেও প্রতিটি স্তরের দায়িত্ব পরিষ্কার থাকতে হবে। কোন ব্যবস্থা Page Cache করছে, কোনটি Browser Cache নিয়ন্ত্রণ করছে এবং পরিবর্তনের পর কোন Cache পরিষ্কার করতে হবে—এসব না বুঝে সব সুবিধা চালু করা উচিত নয়।

Cloudflare-এর বর্তমান নির্দেশনায় কিছু WordPress Cache Plugin-এর সঙ্গে Automatic Platform Optimization চালুর সময় প্রথমে অন্য Cache ব্যবস্থা বন্ধ রেখে পরীক্ষা করতে বলা হয়েছে। একাধিক Cache স্তরের ভুল সমন্বয়ে অপ্রত্যাশিত সমস্যা হতে পারে।

Theme ও Page Builder পরীক্ষা করুন

একটি Theme ওয়েবসাইটের দৃশ্যমান নকশার পাশাপাশি কতগুলো CSS, JavaScript, Font, Icon ও অন্যান্য উপাদান লোড হবে তা নির্ধারণ করে। অতিরিক্ত Animation, Slider, Popup, আলাদা Mobile Layout এবং বহু নকশা সুবিধা থাকা Theme প্রয়োজনের তুলনায় বেশি তথ্য লোড করতে পারে।

WordPress-এর সরকারি কর্মক্ষমতা নির্দেশনায় Theme-কে ওয়েবসাইটের গতির গুরুত্বপূর্ণ অংশ হিসেবে উল্লেখ করা হয়েছে। হালকা Theme সাধারণত ভারী ও অদক্ষ Theme-এর তুলনায় ভালো কাজ করে। Theme অপটিমাইজেশনে Server Request কমানো, ছবির আকার নিয়ন্ত্রণ এবং CSS ও JavaScript দক্ষভাবে ব্যবহারের বিষয়ও উল্লেখ করা হয়েছে। Theme দায়ী কি না বোঝার নিরাপদ উপায় হলো Staging Site-এ সাময়িকভাবে একটি সাধারণ WordPress Theme চালু করে একই পৃষ্ঠা পরীক্ষা করা। গতি উল্লেখযোগ্যভাবে বাড়লে বর্তমান Theme-এর নকশা, Custom Code বা Page Builder-এর উপাদান পরীক্ষা করতে হবে।