একটি বিগিনার-ফ্রেন্ডলি গাইড যা ব্যাখ্যা করে কীভাবে ওয়েবসাইট লোড টাইম বাস্তবে উন্নত হয়: ইমেজ, ক্যাশিং, হোস্টিং, কোড ও Core Web Vitals—এবং শুরুতে করার দ্রুত কার্যক্রমসমূহ।
যখন মানুষ বলে “আমার ওয়েবসাইট ধীর,” তারা সাধারণত দুটির মধ্যে একটির কথা বোঝায়:
“লোড টাইম” একটি একক স্টপওয়াচ নম্বর নয়। একটি পেজ ধাপে ধাপে লোড হয়: ব্রাউজার ফাইল (HTML, ছবি, ফন্ট, স্ক্রিপ্ট) অনুরোধ করে, ডাউনলোড করে, এবং সেগুলোকে ব্যবহারযোগ্য পেজে রেন্ডার করে। এটা আপনি এমন ভাবতে পারেন—একটি দোকান খুলছে: দরজা খুলে, লাইট অন করে, শেল্ভস স্টক করে, তারপর গ্রাহক পরিবেশন করার জন্য প্রস্তুত।
গতি প্রভাব ফেলে:
আপনাকে ৫০টি মাইক্রো-অপ্টিমাইজেশনের দরকার নেই। বেশিরভাগ বেসিক সাইটের জন্য সবচেয়ে বড় উন্নতি আসে একটি সংক্ষিপ্ত তালিকা থেকে: ইমেজ, অতিরিক্ত JavaScript/CSS, তৃতীয়-পক্ষের উইজেট, এবং সার্ভার/হোস্টিং রেসপন্স টাইম।
এই গাইডটি বাস্তব-জগতে পেজ লোড টাইম উন্নত করার জন্য ব্যবহারিক, কম-ঝুঁকিপূর্ণ ধাপগুলোর ওপর ফোকাস করে, বিশেষ করে মোবাইলে। এটি গভীরভাবে অ্যাপ আর্কিটেকচার পুনরায় লিখা, কাস্টম ক্যাশিং লেয়ার তৈরি করা, বা বড় ইঞ্জিনিয়ারিং টিমের জন্য পারফরম্যান্স বাজেটিং-এ প্রবেশ করবে না। লক্ষ্য হলো এমন পরিবর্তন গুলোতে সাহায্য করা যেগুলো আপনি বাস্তবে শেষ করে যাচাই করতে পারবেন—আপনার সাইট ভাঙা ছাড়াই।
যখন মানুষ বলে “আমার সাইট ধীর,” তারা সাধারণত তিনটির মধ্যে একটি বোঝায়: প্রধান কনটেন্ট দেরিতে দেখা যায়, পেজ ক্লিক করলে জটিল লাগে, বা লেআউট লোড হওয়ার সময় বারবার ঝাপসা। Google-এর Core Web Vitals সেই অভিযোগগুলোর সাথে সুন্দরভাবে মানায়।
LCP (Largest Contentful Paint): সবচেয়ে বড় "মেইন" উপাদান (অften হিরো ইমেজ বা হেডলাইন ব্লক) প্রদর্শিত হতে কত সময় লাগে। LCP বেশি হলে ব্যবহারকারী বেসিকভাবে খালি পেজ দেখছেন।
INP (Interaction to Next Paint): ব্যবহারকারী ইন্টারঅ্যাক্ট করার (ট্যাপ, ক্লিক, টাইপ) পরে পেজ কত দ্রুত প্রতিক্রিয়া দেয়। INP বেশি হলে সাইট লেগি মনে হবে—বাটন দেরিতে কাজ করে, মেনু খোলায় বিলম্ব হয়।
CLS (Cumulative Layout Shift): লোডের সময় পেজ কতটা ঝাঁকুনি খায়। টেক্সট সরিয়ে আপনি ভুলে বাটনে চাপ দিলে সেটাই CLS।
TTFB (Time to First Byte) হল সার্ভার (এবং মধ্যবর্তী সব কিছুর) থেকে কিছুই পাঠানো শুরু করার আগে কতক্ষণ লাগে। ধীর TTFB সবকিছুতেই বিলম্ব করে: ছবি ডাউনলোড শুরু করতে পারে না, ফন্ট লোড হয় না, এবং সাধারণত LCP খারাপ হয়। TTFB সমস্যা সাধারণত হোস্টিং, ভারি ব্যাকএন্ড কাজ, বা অনুপযুক্ত ক্যাশিং নির্দেশ করে।
ল্যাব টেস্ট (যেমন Lighthouse) একটি নির্দিষ্ট শর্তে পেজ লোড সিম্যুলেট করে। এগুলো ডিবাগিং এবং আগে/পরে তুলনা করার জন্য দারুণ।
রিয়েল-ইউজার ডেটা (মাঠের ডেটা, যেমন CrUX PageSpeed Insights এ) বাস্তবে ভিজিটররা কেমন অভিজ্ঞতা করে তা প্রতিফলিত করে। এটা সবচেয়ে গুরুত্বপূর্ণ প্রশ্নের উত্তর দেয়: “এটি সত্যিকারের মানুষের জন্য দ্রুত মনে হয় কি?”
আপনি যদি কোনও বেসলাইন না নিয়ে “অপ্টিমাইজ” শুরু করেন, তাহলে সময় নষ্ট করা বা ভুল করে সাইট ধীর করাও সহজ। প্রথমে ২০ মিনিট মাপুন, তারপর জানতে পারবেন কোন পরিবর্তনগুলো উপকারী ছিল।
PageSpeed Insights ব্যবহার করুন (/) একটি দ্রুত স্ন্যাপশটের জন্য। এটি রিপোর্ট করে field data (প্রকৃত-ইউজার অভিজ্ঞতা, যেখানে উপলব্ধ) এবং lab data (সিম্যুলেটেড টেস্ট)। লক্ষ্য রাখুন:
ডিপার ল্যাব টেস্টিং এর জন্য Chrome-এ Lighthouse চালান:
যখন আপনি দেখতে চান কি করছে পেজ ধীর করে, WebPageTest (/) একটি স্পষ্ট টুল। waterfall view প্রতিটি ফাইলের লোডিং অনুক্রম দেখায়—HTML, ইমেজ, ফন্ট, স্ক্রিপ্ট, এবং তৃতীয়-পক্ষ ট্যাগ—এবং ব্রাউজার কোথায় অপেক্ষা করছে।
একটি মূল পেজ (হোমপেজ বা শীর্ষ ল্যান্ডিং পেজ) দিয়ে শুরু করুন এবং টেস্ট করুন:
প্রতিটি টেস্টের জন্য লিখে রাখুন:
একটি ছোট লগ (স্প্রেডশীট চলবে): তারিখ, ব্যবহার করা টুল, URL, ফলাফল, এবং কি বদলানো হলো। প্রতি বার শুধুমাত্র এক বা দুইটা জিনিস বদলান, তারপর একই শর্তে পুনরায় টেস্ট করুন।
আপনি যদি একটি অ্যাপে ইটারেট করেন (শুধু স্ট্যাটিক সাইট নাও), তাহলে পারফরম্যান্স এক্সপেরিমেন্ট শিপ ও রোলব্যাক করার নিরাপদ উপায় থাকা সুবিধাজনক। এমন প্ল্যাটফর্মগুলো যেমন Koder.ai উৎপাদন ও হোস্টিং চ্যাট-ওয়ার্কফ্লো থেকে সরল করে—আপনি স্ন্যাপশট নিতে, পরিবর্তন টেস্ট করতে, এবং যদি কোনো “স্পিড ফিক্স” ইউএক্স ভাঙে তাহলে দ্রুত রোল ব্যাক করতে পারবেন।
ধীর পেজ সাধারণত কোনো এক রহস্যজনক ইস্যু থেকে নয়। এগুলো কয়েকটি সাধারণ “ওয়েট এবং ডিলে” সমস্যার ফল—বিশেষ করে মোবাইলে।
ইমেজ প্রায়শই পেজের সবচেয়ে ভারী অংশ। একটা সিঙ্গেল হিরো ইমেজ ভুল সাইজে এক্সপোর্ট করলে মেগাবাইট এবং কয়েক সেকেন্ড যোগ হতে পারে।
সাধারণ সমস্যা:
JavaScript পেজকে ব্যবহারযোগ্য হতে দেরি করাতে পারে। পেজ “দেখে” গেলেও স্ক্রিপ্ট লোড, পার্স এবং রান করার সময় এটি স্লাগি মনে হতে পারে।
তৃতীয়-পক্ষ স্ক্রিপ্টগুলো প্রায়ই সমস্যা করে: চ্যাট উইজেট, পপ-আপ, হিটম্যাপ, A/B টেস্টিং টুল, অ্যাড ট্যাগ, এবং সোশ্যাল এমবেড। প্রতিটি অতিরিক্ত কল নেটওয়ার্ক বাড়ায় এবং ব্রাউজারের কাজকে দেরি করে।
কখনো কখনো ব্রাউজার আপনার সার্ভারের জন্য অপেক্ষা করছে আগে কিছুই ডাউনলোড শুরু করার আগে। এটা প্রায়শই TTFB হিসেবে দেখা যায়। কারণগুলো: অপ্রতুল হোস্টিং, ব্যস্ত ডাটাবেস, অপ্টিমাইজ না করা থিম/প্লাগইন, বা প্রতিটি ভিজিটে ডায়নামিক পেজ বিল্ড করা।
যদি সাইট প্রতিটি ভিজিটে সবকিছু শূন্য থেকে শুরু করায়, রেটার্ন ভিজিটরদের শাস্তি Diesel হয়। ক্যাশ না থাকলে সার্ভার বারবার পেজ রেবিল্ড করে এবং ব্রাউজার সেইসব ফাইলগুলো পুনরায় ডাউনলোড করে যা বারবার পরিবর্তিত হয় না।
এছাড়া অনেক ছোট ফাইল (ফন্ট, স্ক্রিপ্ট, স্টাইল, ট্র্যাকার) “রিকোয়েস্ট ওভারহেড” তৈরি করে। প্রতিটি ফাইল ছোট হলেও একসাথে অপেক্ষার সময় জোড়া হয়।
ভাল খবর: এই কারণগুলো ঠিক করা যায়—এবং সাধারণত এই ক্রমেই কাজ করলে সবচেয়ে বড় লাভ হয়।
যদি আপনি শুধু একটি পারফরম্যান্স উন্নতি করেন, সেটি হোক ইমেজ। অনেক বিগিনার সাইটে ইমেজই পেজে ডাউনলোড হওয়া "ওয়েট"-এর সবচেয়ে বড় অংশ—বিশেষ করে মোবাইলে। ভালো খবর: ইমেজ ফিক্সগুলো সাধারণত নিরাপদ, দ্রুত, এবং ডিজাইন বদলানো ছাড়াই করা যায়।
একটি সাধারণ ভুল হলো একটি বিশাল ফটো (যেমন, 4000px) আপলোড করা এবং সেটি 800px-এ দেখানো। ব্রাউজার তখনও বড় ফাইল ডাউনলোড করে।
লক্ষ্য করুন: ইমেজগুলো সেই সর্বোচ্চ সাইজে এক্সপোর্ট করুন যেখানে সেগুলো বাস্তবে আপনার সাইটে প্রদর্শিত হবে। উদাহরণস্বরূপ, যদি আপনার ব্লগের কনটেন্ট এরিয়া 800px হয়, তাহলে 3000–4000px ইমেজ আপলোড করবেন না।
JPEG এবং PNG এখনও কাজ করে, কিন্তু আধুনিক ফরম্যাট একই ভিজ্যুয়াল কোয়ালিটি কম ফাইল সাইজে দিতে পারে।
যদি আপনার CMS বা ইমেজ প্লাগইন স্বয়ংক্রিয়ভাবে WebP/AVIF সার্ভ করতে পারে (fallback সহ), সেটা আদর্শ।
সংকোচন থেকে বেশিরভাগ অবিলম্বিক লোড টাইম লাভ হয়। একটি “ভিজ্যুয়ালি একাধিক” ইমেজ প্রায়শই 30–70% কম হতে পারে।
এছাড়া অপ্রয়োজনীয় ক্যামেরা ইন্টারনাল বা লোকেশন ডাটা সরিয়ে দিন—এটা ছবির চেহারা বদলে না কিন্তু বাইট যোগ করে।
প্রায়োগিক নিয়ম: যতক্ষণ না আপনি স্পষ্টভাবে গুণগত মান হারাচ্ছেন ততক্ষণ সংকোচন বাড়ান, তারপর এক ধাপ কমিয়ে নিন।
srcset) ব্যবহার করুন মোবাইল বনাম ডেস্কটপের জন্যমোবাইল ব্যবহারকারীকে ডেস্কটপ সাইজ ইমেজ ডাউনলোড করা উচিত নয়। Responsive images ব্রাউজারকে ডিভাইস অনুযায়ী সঠিক সাইজ বেছে নিতে দেয়।
যদি আপনার সাইট স্বয়ংক্রিয়ভাবে একাধিক ইমেজ সাইজ জেনারেট করে, নিশ্চিত করুন আপনার থিম সেগুলো সঠিকভাবে ব্যবহার করছে। পেজ HTML-এ আপনি যা দেখতে চান তা হলো srcset (বহু সংস্করণ) একক বড় ফাইলের বদলে।
কোড মিনিফাই বা আরও উন্নত টিউনিং করার আগে, আপনার শীর্ষ ইমেজগুলো শুধু অডিট করুন:
এ চারটি কাজ ধারাবাহিকভাবে করুন, এবং আপনার ওয়েবসাইট গতি এবং পেজ লোড টাইম সাধারণত অবিলম্বে উন্নতি পাবে—প্রায়ই Core Web Vitals-ও সঠিক দিকে যাবে।
Lazy loading মানে আপনার পেজ কিছু ইমেজ (এবং কখনো কখনো iframes) ডাউনলোড টাল দেয় যতক্ষণ না সেগুলো স্ক্রিনে দেখাতে কাছে আসে। এটা প্রাথমিক পেজ লোড টাইম কমাতে পারে কারণ ব্রাউজার একসাথে সবকিছু ফেচ করছে না—বিশেষ করে দীর্ঘ পেজে অনেক নিচের ইমেজ থাকলে উপকারী।
Lazy loading সবচেয়ে উপকারী:
ভালভাবে ব্যবহার করলে এটা "অগ্রভাগে করা কাজ" কমায় এবং পেজকে দ্রুত মনে করায়।
আপনার সবচেয়ে বড় উপরের-ফোল্ড ইমেজ প্রায়শই হিরো ইমেজ। যদি আপনি এটাকে lazy-load করে দেন, ব্রাউজার অনুরোধ করতে দেরি করে, যা Largest Contentful Paint (LCP)-কে ক্ষতিগ্রস্থ করতে পারে।
রুল অফ থাম্ব: প্রধান হিরো ইমেজ বা প্রথম স্ক্রীনের কিছুকে কখনই lazy-load করবেন না (হেডলাইন ইমেজ, প্রধান পণ্য ফটো, উপরের ব্যানার)।
Lazy loading কখনো কখনো “ঝাঁকুনি” ঘটায় যখন ইমেজগুলো প্রদর্শিত হয়। layout shifts (CLS) রোধ করতে সর্বদা জায়গা রিজার্ভ করুন:
width এবং height সেট করুন, অথবাএভাবে ইমেজ লোডিং চলাকালীন লেআউট স্থায়ী থাকে।
যদি একটি উপরের-ফোল্ড ইমেজ বা ফন্ট প্রথম ইমপ্রেশন জন্য অত্যাবশ্যক হয়, সেটি preload করার কথা ভাবুন যাতে ব্রাউজার দ্রুত এটি আনে। তবে সাবধান—অতিমাত্রায় প্রিলোড করলে ব্যান্ডউইথের জন্য প্রতিযোগিতা হয়ে ফিরোয়।
আপনি যদি চেকলিস্ট পদ্ধতি চান, তাহলে এটি আপনার মাপা ধাপের সঙ্গে /blog/how-to-measure-site-speed-before-you-change-anything লিংক মিলিয়ে ব্যবহার করুন।
ক্যাশিং হলো ব্রাউজারের উপায়: “আমি এটা আগে ডাউনলোড করেছি—আমি কি এটি পুনরায় ব্যবহার করতে পারি?” একই লোগো, CSS ফাইল বা JavaScript বান্ডল প্রতিটি পেজ ভিউ (অথবা প্রতিটি ভিজিট) ডাউনলোড না করে ব্রাউজার স্থানীয় কপি রাখে। এতে রিটর্ন ভিজিট অনেক দ্রুত হয় এবং ডেটা ব্যবহার কমে—বিশেষ করে মোবাইলে।
যখন আপনার সাইট একটি ফাইল (যেমন styles.css বা app.js) পাঠায়, তখন এটি নির্দেশও পাঠাতে পারে কতক্ষণ ওই ফাইলটি পুনরায় ব্যবহার করা যাবে। যদি ব্রাউজারকে বলা হয় ৩০ দিন ধরে রাখো, তখন পরবর্তী ভিজিটে ঐ ফাইলগুলো স্থানীয় ডিভাইস থেকে তৎক্ষণাৎ লোড হবে সার্ভার থেকে নয়।
এটি প্রথম ভিজিটকে দ্রুত করবে না, কিন্তু এটি ব্যাপকভাবে দ্রুত করে:
স্ট্যাটিক ফাইলগুলি হল যেগুলো প্রতিটি রিকোয়েস্টে বদলে না: ইমেজ, CSS, JavaScript, ফন্ট। এগুলো দীর্ঘ সময়ের জন্য ক্যাশ করার উপযুক্ত।
আপনি ধারণাগতভাবে চাইবেন:
আপনার হোস্ট, CMS, বা ফ্রেমওয়ার্ক সম্ভবত “static asset caching” টগল দেয়। একজন ডেভেলপার থাকলে তাদের বলুন উপযুক্ত Cache-Control হেডার সেট করতে।
একটি সাধারণ উদ্বেগ: “যদি আমরা ফাইল এক মাস ক্যাশ করি, আগামীকাল কীভাবে আপডেট পাব?” সমাধান হল versioned filenames।
app.js বারবার ব্যবহার করার বদলে, আপনার বিল্ড প্রসেস (অথবা ডেভেলপার) আউটপুট করতে পারে যেমন:
app.3f2a1c.jsstyles.a81b09.cssকনটেন্ট বদলালে ফাইলনামও বদলে যাবে, ফলে ব্রাউজার সেটি নতুন ফাইল হিসেবে ডাউনলোড করবে—তবে পুরনো ভার্সনগুলো নিরাপদে ক্যাশ করা থাকবে।
সার্ভিস ওয়ার্কার ক্যাশিংকে আরও সামনে নিয়ে যেতে পারে—আপনার সাইট কী সংরক্ষণ করবে এবং কখন তা নিয়ন্ত্রণ করতে দেয়, কখনো কখনো অফলাইন আচরণও সম্ভব্য করে। কিন্তু ভুলভাবে করা হলে "স্টেল কনটেন্ট" সমস্যা সৃষ্টি করতে পারে। বিগিনার হলে সার্ভিস ওয়ার্কারকে অ্যাডভান্সড অপশন হিসেবে বিবেচনা করুন—যেখানে পরিষ্কার লক্ষ্য এবং একজন অভিজ্ঞ লোক সেটি রক্ষণাবেক্ষণ করবে।
CDN (Content Delivery Network) হলো বিভিন্ন অঞ্চলে ছড়িয়ে থাকা সার্ভারগুলোর একটি গ্রুপ যা দর্শকের নিকট থেকে আপনার সাইটের ফাইলগুলিকে সরবরাহ করতে পারে। প্রতিটি অনুরোধ আপনার একক হোস্টিং সার্ভারের কাছে এ না গিয়ে কাছাকাছি থাকা CDN সার্ভারগুলি হ্যান্ডেল করতে পারে।
CDN গুলো সবচেয়ে ভালভাবে স্ট্যাটিক অ্যাসেট-গুলোকে দ্রুত সরবরাহ করে—যেমন ইমেজ, CSS, JavaScript ফাইল, ফন্ট, এবং ভিডিও। এই ফাইলগুলো CDN সার্ভারে কপি করা যায় ("ক্যাশ") এবং বহু ভিজিটরের জন্য পুনরায় ব্যবহার করা যায়।
যারা সবচেয়ে উপকৃত হবে: বিভিন্ন শহর/দেশ থেকে দর্শক পাওয়া সাইট, মিডিয়া-ভিত্তিক সাইট, এবং যেকোন ব্যবসা যা পেইড ক্যাম্পেইন চালায় যেগুলো বিভিন্ন লোকেশন থেকে ট্র্যাফিক পাঠায়।
দূরত্ব বিলম্ব বাড়ায়। যদি আপনার সার্ভার একটি দেশে থাকে এবং ভিজিটর অন্য মহাদেশে, প্রতিটি ফাইল অনুরোধে বেশি সময় লাগে। CDN cached ফাইলটিকে এজ সার্ভার থেকে সরবরাহ করে, যা সাধারণত পেজ লোড টাইম উন্নত করে এবং Core Web Vitals-এ সাহায্য করে—বিশেষ করে মোবাইল কানেকশনে।
ভুল কনফিগার করা ক্যাশ হেডার পুরোপুরি ক্যাশিং বন্ধ করতে পারে (অথবা খুব কম ক্যাশ)। উল্টো সমস্যা হলো স্টেল ক্যাশ: আপনি ফাইল আপডেট করেছেন, কিন্তু ভিজিটররা এখনও পুরনো ভের্সন পেয়ে যায়। এই থেকে বাঁচতে cache-busting filenames (যেমন app.1234.js) এবং CDN-এর purge ফিচার শিখুন।
CDN ভারি ইমেজ বা ফোল্ডেড স্ক্রিপ্ট ঠিক করবে না—প্রথমে বেসিকগুলো ঠিক করুন, তারপর CDN যোগ করলে এটি গুণিতক সুবিধা দেয়।
CSS এবং JavaScript প্রায়শই পেজকে ধীর করে এমন “অদৃশ্য ওজন”। ইমেজের মতো আপনি সবসময় সমস্যা দেখতে পান না—তবুও ব্রাউজারকে এগুলো ডাউনলোড, প্রসেস এবং এক্সিকিউট করতে হয় যতক্ষণ না পেজ ব্যবহারযোগ্য।
মিনিফাই করলে অতিরিক্ত স্পেস, মন্তব্য, এবং ফরম্যাটিং সরানো হয়। সাধারণত ফাইল ছোট হয় এবং দ্রুত ডাউনলোড হয়।
এটি কি পরিবর্তন করে: ফাইল সাইজ।
এটি কি পরিবর্তন করে না: ব্রাউজারকে কোড পার্স এবং রান করতে যত কাজ করতে হয়। যদি আপনার স্ক্রিপ্ট লোডে অনেক কাজ করে, মিনিফাই সেটা ঠিক করবে না—তাই মিনিফাইকে দ্রুত এক উইন হিসেবে দেখুন, সম্পূর্ণ সমাধান হিসেবে নয়।
অনেক সাইট একটি “এক সাইজ সব” স্টাইলশীট লোড করে যার মধ্যে সেই পেজে ব্যবহৃত না হওয়া নিয়মও থাকে। সেই অতিরিক্ত CSS ডাউনলোড হয় এবং রেন্ডারিং ধীর করতে পারে।
প্রায়োগিক পদ্ধতি:
লক্ষ্য: হোমপেজ পুরো সাইটের ওজন বহন করবে না।
কিছু স্ক্রিপ্ট পেজকে ব্যবহারযোগ্য হওয়ার আগে ব্লক করে কারণ ব্রাউজার সেগুলো চালিয়ে ফেলে।
defer সাধারণত আপনার নিজের স্ক্রিপ্টগুলোর জন্য ভাল, যেগুলো HTML পার্স হওয়ার পরে অপেক্ষা করতে পারে।async স্বাধীন স্ক্রিপ্টের জন্য ভালো (প্রায়ই তৃতীয়-পক্ষ) যা অন্য কোডের উপর নির্ভর করে না।আপনি যদি নিশ্চিত না হন, প্রথমে এমন সব ডিফার করুন যা প্রথম স্ক্রীনের জন্য দরকার নেই (মেনু, অ্যানিমেশন, স্লাইডার, ট্র্যাকিং এক্সট্রা)।
বড় লাইব্রেরি কয়েকশ কিবি (বা বেশি) যোগ করতে পারে। আরেকটা প্লাগইন বা ফ্রেমওয়ার্ক যোগ করার আগে জিজ্ঞেস করুন:
কম স্ক্রিপ্ট সাধারণত কম সাপরাইজ দেয়—বিশেষ করে মোবাইল পারফরম্যান্সে, যেখানে CPU সময় ডাউনলোড সাইজের মতই গুরুত্বপূর্ণ।
তৃতীয়-পক্ষ স্ক্রিপ্টগুলো হচ্ছে যেকোনো জিনিস যা আপনার সাইট অন্য কোম্পানির সার্ভার থেকে লোড করে। এগুলো দ্রুত ফিচার যোগ করে যেগুলো জনপ্রিয়, কিন্তু সেগুলোই সবচেয়ে বড়, সবচেয়ে অনিয়মিতভাবে পেজ ধীর করে দিতে পারে।
বেশিরভাগ স্লোডাউন কয়েকটি ক্যাটাগরির মধ্যে আসে:
এই স্ক্রিপ্টগুলো প্রায়শই অতিরিক্ত ফাইল ডাউনলোড করে, অনেক JavaScript চালায়, এবং কখনো কখনো ব্রাউজারকে পেজ শেষ করতে ব্লক করে।
Chrome DevTools → Performance খুলুন, একটি পেজ লোড রেকর্ড করুন এবং দেখুন:
আপনি Lighthouse চালিয়ে (Chrome DevTools → Lighthouse) “Reduce JavaScript execution time” এবং “Eliminate render-blocking resources” সম্পর্কিত সুপারিশগুলোও দেখতে পারবেন।
কয়েকটি বিগিনার-ফ্রেন্ডলি উইন:
পুরো YouTube/Facebook/Map এমবেড পেজ লোডে লোড করার বদলে, একটি সাধারণ প্রিভিউ দেখান (থাম্বনেইল + প্লে বাটন)। ব্যবহারকারী ক্লিক করলে প্রকৃত এমবেড লোড করবেন।
এভাবে পেজটি সকলের জন্য দ্রুত থাকে—বিশেষ করে মোবাইলে—ফিচার পুরোপুরি সরিয়ে না রেখে।
TTFB (Time to First Byte) হল ব্রাউজার পেজের জন্য অনুরোধ করার পর সার্ভার প্রথম বাইট পাঠানো পর্যন্ত সময় লাগে। এটা ভাবুন “রান্নাঘর রান্না শুরু করে কতোক্ষণ লাগে,” পুরো খাবার কতক্ষণ লাগে না।
দারুণ ডিজাইন করা সাইটও ধীর অনুভব করতে পারে যদি TTFB বেশি—বিশেষ করে মোবাইল নেটওয়ার্কে যেখানে প্রতিটি বিলম্ব বেশি লক্ষণীয়।
TTFB মূলত সার্ভার-সাইড কাজের কারণে:
আপনার ইমেজ এবং স্ক্রিপ্ট অপ্টিমাইজ করা সত্ত্বেও, ধীর সার্ভার রেসপন্স ব্রাউজারকে খালি স্ক্রিনে অপেক্ষা করায়।
যদি আপনার সাইট CMS দিয়ে তৈরি বা ডাইনামিক পেজ জেনারেট করে, সার্ভার-সাইড ক্যাশিং সাধারণত TTFB বৃদ্ধির সবচেয়ে বড় সহজ বিজয়। প্রতিটি ভিজিটরের জন্য একই পেজ পুনরায় তৈরি না করে, সার্ভার একটি রেডি-টু-সার্ভ ভার্সন সংরক্ষণ করতে পারে।
প্রায়োগিক উদাহরণ:
টেক্সট-ভিত্তিক ফাইল (HTML, CSS, JavaScript) জন্য Brotli (পছন্দনীয়) বা Gzip এনেবল করুন। এটা নেটওয়ার্কে পাঠানো ডেটার পরিমাণ কমায়, যা বিশেষ করে রিটার্ন লোড এবং মোবাইল ইউজারের জন্য পারসেপচুয়াল স্পিড উন্নত করে।
ভালো হোস্টিং TTFB কাটা দিতে পারে, কিন্তু প্রথমে যুক্তিযুক্ত হবে যে সরাসরি ফ্রন্ট-এন্ড ইস্যু (বড় ইমেজ, অতিরিক্ত তৃতীয়-পক্ষ স্ক্রিপ্ট, ভারি JavaScript) ঠিক করা। ব্রাউজার যদি মেগাবাইট ডাউনলোড করে, দ্রুত হোস্টিং দিলেও পেজ সত্যিকারের দ্রুত মনে হবে না।
যদি আপনি বেসিকগুলো হ্যান্ডেল করার পরও TTFB উচ্চ থাকে, তখন হোস্টিং আপগ্রেড (অধিক CPU/RAM, টিউন করা ডাটাবেস, ভালো রানটাইম পারফরম্যান্স) শেষ ধাপ হিসেবে বিবেচনা করুন।
নতুন প্রোডাক্ট তৈরির সময় হোস্টিং ভ্যারিয়েবল কম রাখতে এবং sensible defaults পেতে ম্যানেজড প্ল্যাটফর্ম বিবেচনা করুন। উদাহরণস্বরূপ, Koder.ai অ্যাপগুলো AWS-এ বিশ্বব্যাপী হোস্ট করে এবং ডিপ্লয়মেন্ট, কাস্টম ডোমেইন, ও এনভায়রনমেন্ট রোলব্যাক সাপোর্ট করে—উপযোগী যখন আপনি পারফরম্যান্স পরিবর্তন অঞ্চলভিত্তিক টেস্ট করতে চান বা ডেটা রেসিডেন্সি অনুরোধ মেনে চলতে চান।
আপনি বিশাল প্রজেক্ট প্ল্যান চাইবেন না—আপনাকে একটি সরল কাজের ক্রম, যাচাইয়ের উপায়, এবং এমন ফিক্সগুলোর প্রতি ঝোঁক দরকার যা বিশ্বাসযোগ্যভাবে পেজ লোড টাইম কমায়।
Day 1: Measure (কোন কিছু করার আগে).
2–3টি গুরুত্বপূর্ণ পেজ (হোমপেজ, মূল ল্যান্ডিং পেজ, জনপ্রিয় ব্লগ/প্রোডাক্ট পেজ) বেছে নিন। চালান:
/) (Core Web Vitals-এ ফোকাস)মোবাইল পারফরম্যান্স এবং ডেস্কটপের বেসলাইন নোট করুন। সম্ভব হলে বাস্তব ফোনে সেলুলার নেটে টেস্ট করুন—এটি ল্যাব টেস্টে লুকানো সমস্যা প্রকাশ করে।
Days 2–3: ইমেজ ঠিক করুন (দ্রুততম, সবচেয়ে নির্ভরযোগ্য উইন).
অগ্রাধিকার দিন:
কয়েকটি ইমেজ আপডেট করে পুনরায় টেস্ট করুন যাতে আপনি প্রভাব দেখতে পান।
Days 4–5: ক্যাশিং ঠিক করুন (পুনরাবৃত্ত ভিজিটকে দ্রুত করুন).
বেসিক ব্রাউজার ক্যাশিং এবং সার্ভার/পেজ ক্যাশিং সক্ষম করুন যেখানে উপযুক্ত। লক্ষ্য: প্রতিটি ভিজিটে একই অ্যাসেট পুনরায় তৈরি বা ডাউনলোড না করা। চালু করে দেখুন রিটার্ন করা পেজটি কতটা দ্রুত মনে হয়।
Days 6–7: JavaScript ছাঁটাই করুন (দীর্ঘমেয়াদী সবচেয়ে বড় লাভ).
অন্বেষণ করুন:
এখানে ছোট পরিবর্তনগুলোই ইন্টারঅ্যাকটিভিটি এবং Core Web Vitals-এ বড় প্রভাব ফেলতে পারে, বিশেষ করে মোবাইলে।
প্রতিটি বড় এডিটের পরে তিনটি দ্রুত চেক করুন:
আপনি ইমেজ এবং ক্যাশিং অপ্টিমাইজ করার পরও যদি TTFB স্থায়ীভাবে উচ্চ থাকে, সাধারণত তা হোস্টিং/সার্ভার সেটআপ, ধীর ডাটাবেস, বা ভারি ব্যাকএন্ড কাজ নির্দেশ করে। এছাড়াও সাহায্য বিবেচনা করুন যদি সাইট একটি জটিল অ্যাপ হয় (মেম্বারশিপ, মার্কেটপ্লেস, প্রচুর পার্সোনালাইজেশন) যেখানে "শুধু ক্যাশ করুন" সহজ নয়।
গভীরতর গাইড চাইলে সার্ভার রেসপন্স টাইম সম্পর্কে /blog/ttfb-explained দেখুন।
Website speed সাধারণত দুটি জিনিস বোঝায়:
একটি পেজ দেখতে লোড হয়েছে বলে মনে হলেও যদি JavaScript ব্যস্ত থাকে বা লেআউট সরগরম হয়, তবে এটি এখনও ধীর অভিজ্ঞতা দিতে পারে।
Core Web Vitals সাধারণ ব্যবহারকারীর অভিযোগের সাথে মিলে যায়:
এইগুলো উন্নত করলে বাস্তবে দ্রুততার অনুভূতি ভাল হয়—শুধু স্কোর বাড়ে না।
প্রায়োগিক লক্ষ্য হিসেবে ব্যবহার করুন:
এগুলো নির্দেশনামূলক; সবচেয়ে দুর্বল মেট্রিকটি প্রথমে উন্নত করুন।
বেসলাইন নেওয়া শুরু করার জন্য:
ডিভাইস, নেটওয়ার্ক, লোকেশন, সঠিক URL নোট করে রাখুন এবং পরীক্ষা করার আগে 1–2 টি জিনিসই বদলান।
সর্বাধিক সাধারণ কারণগুলো:
এইগুলো এই ক্রমেই ঠিক করলে দ্রুত ফল পাওয়া যায়।
কারণ এগুলোই সাধারণত পেজে সবচেয়ে বেশি ওজন যোগ করে এবং LCP-এ প্রভাব ফেলে। চারটি মূল কাজ:
srcset) ব্যবহার করে মোবাইলকে ছোট ফাইল দিন।Lazy loading উপরের-ফোল্ডের নিচের কনটেন্টগুলোর জন্য সাহায্য করে, কিন্তু ভুলভাবে ব্যবহার করলে LCP খারাপ করতে পারে.
প্র্যাকটিক্যাল নিয়ম:
width/height সেট করুন বা CSS এ ফিক্সড অ্যাসপেক্ট রেশিও ব্যবহার করুন।ক্যাশিং মূলত রিটর্ন ভিউ (দ্বিতীয় পেজ ক্লিক, পুনরায় ভিজিট) দ্রুত করে:
app.3f2a1c.js) যাতে আপডেট হলে ব্রাউজার নতুন ফাইল নেয়।সঠিকভাবে করলে ক্যাশিং পুনরায় ডাউনলোড এবং সার্ভার কাজ কমায়, আপডেটে বাধা দেয় না।
CDN সবচেয়ে বেশি উপকারী যখন আপনার ভিজিটররা বিভিন্ন অঞ্চলে থাকে এবং আপনি স্ট্যাটিক ফাইল বেশি সার্ভ করেন।
এটি ভালো কাজ করে:
সতর্কথা:
CDN একা দিয়ে ভারি পেজ ঠিক হবে না—শুরুতেই ইমেজ ও স্ক্রিপ্ট অপ্টিমাইজ করুন, তারপর CDN যোগ করুন।
সহজ একটি সিকোয়েন্স যা আপনি যাচাই করতে পারবেন:
প্রতিটি ধাপের পরে একই শর্তে আবার টেস্ট করুন এবং সাইটে ক্লিক করে যাচাই করুন—স্পিড ফিক্স যদি ইউএক্স ভাঙে তবে সেটি গ্রহণযোগ্য নয়।
এই পরিবর্তনগুলো সাধারণত ঝুঁকিমুক্ত এবং অবিলম্বে মাপা যায়।
পূবর্তি লোডের জন্য যদি কিছু অত্যাবশ্যক হয়, সতর্কভাবে প্রিলোড বিবেচনা করুন।