ওয়েবসাইট কীভাবে আরও দ্রুত করবেন: একটি ব্যবহারিক চেকলিস্ট
ওয়েবসাইট দ্রুত করতে প্রথমে PageSpeed Insights দিয়ে মাপুন, তারপর সেটি যে সবচেয়ে বড় কারণ দেখায় তা ঠিক করুন — সাধারণত অতিরিক্ত বড় ছবি, অনেক বেশি JavaScript, ভারী ফন্ট বা তৃতীয় পক্ষের স্ক্রিপ্ট। Google-এর Core Web Vitals-এর "ভালো" লক্ষ্যে পৌঁছানোর চেষ্টা করুন: মূল কনটেন্ট 2.5 সেকেন্ডের মধ্যে দৃশ্যমান, ট্যাপের সাড়া 200 মিলিসেকেন্ডের মধ্যে, এবং লেআউট প্রায় না নড়া। বেশিরভাগ সাইট পুনর্লিখন ছাড়াই কয়েকটি পরিবর্তনে সেখানে পৌঁছায়।
কিছু বদলানোর আগে মাপুন
অনুমান করে সময় নষ্ট হয়। দুটি বিনামূল্যের টুলই প্রায় সবার জন্য যথেষ্ট:
- PageSpeed Insights (pagespeed.web.dev) — একটি লাইভ URL পেস্ট করুন। এটি প্রকৃত Chrome ব্যবহারকারীদের থেকে ফিল্ড ডেটা দেখায় (আপনার সাইটে যথেষ্ট ট্র্যাফিক থাকলে), একটি সিমুলেটেড লোড থেকে ল্যাব ডেটা, এবং নির্দিষ্ট সমস্যার তালিকা।
- Chrome DevTools-এর Lighthouse — একই ল্যাব পরীক্ষা, যেকোনো খোলা যায় এমন পেজে, প্রিভিউসহ। মোবাইল মোডে পরীক্ষা করুন; ধীর নেটওয়ার্কের ফোনেই সমস্যা ধরা পড়ে।
যে সংখ্যাগুলো গুরুত্বপূর্ণ সেগুলো Google-এর Core Web Vitals। ২০২৬ সালের সেপ্টেম্বর পর্যন্ত web.dev-এ Google-এর ডকুমেন্টেশন পেজ লোডের 75তম পার্সেন্টাইলে মেপে এই "ভালো" সীমাগুলো দেয়:
| মেট্রিক | যা মাপে | ভালো |
|---|---|---|
| Largest Contentful Paint (LCP) | মূল কনটেন্ট (হিরো ছবি, শিরোনাম) কত দ্রুত আসে | 2.5 s বা কম |
| Interaction to Next Paint (INP) | ক্লিক, ট্যাপ ও টাইপিংয়ে পেজ কত দ্রুত সাড়া দেয় | 200 ms বা কম |
| Cumulative Layout Shift (CLS) | লোড হওয়ার সময় লেআউট কতটা নড়ে | 0.1 বা কম |
INP ২০২৪ সালে পুরোনো First Input Delay মেট্রিকের জায়গা নিয়েছে। কোনো টুল এখনও FID দেখালে সেটি পুরোনো।
আপনার শুরুর সংখ্যাগুলো লিখে রাখুন। প্রতিটি সংশোধনের পর আবার পরীক্ষা করুন, যাতে জানেন কোনটি কাজ করেছে।
সময় কোথায় যায়: বিকল্প ও বিনিময়
প্রতিটি সাধারণ কারণের একটি সমাধান আছে, এবং প্রতিটি সমাধানের একটি খরচ আছে। উপরের সহজগুলো দিয়ে শুরু করুন — সেগুলো সবচেয়ে সস্তা ও সবচেয়ে সাধারণ।
| কারণ | সাধারণ সমাধান | বিনিময় |
|---|---|---|
| বড় ছবি | প্রদর্শিত আকারে ছোট করুন, সংকুচিত করুন, WebP বা AVIF ব্যবহার করুন | অতিরিক্ত সংকোচনে সামান্য মানের ক্ষতি |
| ভুল ক্রমে লোড হওয়া ছবি | ভাঁজের নিচের ছবি lazy-load করুন; হিরো ছবিকে উচ্চ অগ্রাধিকার দিন | কোনো নেই, যদি হিরো ছবি lazy না হয় |
| অতিরিক্ত JavaScript | প্রতি পেজে কোড ভাগ করুন, ব্যবহার না হওয়া লাইব্রেরি সরান | কিছু রিফ্যাক্টরিং |
| শুধু ক্লায়েন্টে রেন্ডারিং | পাবলিক পেজ প্রি-রেন্ডার বা সার্ভার-রেন্ডার করুন | বেশি বিল্ড বা সার্ভার সেটআপ |
| ওয়েব ফন্ট | কম পরিবার ও ওজন, মূলটি প্রিলোড করুন, font-display: swap | টাইপোগ্রাফির বৈচিত্র্য কমে |
| তৃতীয় পক্ষের স্ক্রিপ্ট | ব্যবহার না হওয়াগুলো সরান, বাকিগুলো পেজের পরে লোড করুন | একটি উইজেট বা ট্র্যাকার হারানো |
| ধীর সার্ভারের সাড়া | ক্যাশিং, CDN, কনটেন্ট পেজের জন্য স্ট্যাটিক হোস্টিং | ক্যাশ বাতিলকরণ ভাবতে হয় |
ছবি
ছবি সবচেয়ে সাধারণ সমস্যা এবং ঠিক করাও সবচেয়ে সহজ। 800 পিক্সেল প্রস্থে দেখানো একটি 4,000 পিক্সেলের ছবি প্রতিটি দর্শককে তারা যা দেখেন তার পাঁচগুণ ডাউনলোড করায়।
- প্রদর্শিত আকারেই ছবি দিন, ফোন ও ডেস্কটপের জন্য রেসপন্সিভ
srcsetআকারসহ। - আধুনিক ফরম্যাট (WebP বা AVIF) ও যুক্তিসংগত সংকোচন ব্যবহার করুন।
- প্রতিটি ছবিতে
widthওheightদিন যাতে ব্রাউজার জায়গা সংরক্ষণ করতে পারে। শুধু এটিই বেশিরভাগ লেআউট শিফট ঠিক করে। - ভাঁজের নিচের ছবিতে
loading="lazy"দিয়ে lazy-load করুন। - পেজের উপরের মূল ছবিকে কখনো lazy-load করবেন না। Google-এর LCP নির্দেশিকা এ বিষয়ে স্পষ্ট: LCP ছবির lazy-loading সবসময় তাকে দেরি করায়। এর বদলে
fetchpriority="high"দিন।
JavaScript
অনেক AI-বানানো সাইট সিঙ্গেল-পেজ অ্যাপ (SPA): ব্রাউজার একটি JavaScript বান্ডল ডাউনলোড করে তারপর পেজ আঁকে। বান্ডল যত বড়, খালি স্ক্রিন তত দীর্ঘ। প্রয়াসের ক্রমানুসারে সমাধান:
- যা ব্যবহার হয় না তা সরান। নির্ভরতার তালিকা চান এবং যেসব লাইব্রেরি একবার যোগ হয়ে ভুলে গেছে তা কাটুন — একটি তারিখের জন্য একটি পুরো তারিখ লাইব্রেরি, বা পাঁচটি আইকনের জন্য একটি পুরো আইকন প্যাক।
- রুট অনুযায়ী ভাগ করুন। অ্যাডমিন ড্যাশবোর্ডের কোড তখনই লোড করুন যখন কেউ সেটি খোলেন, হোম পেজে নয়।
- পাবলিক পেজ প্রি-রেন্ডার করুন। একটি মার্কেটিং পেজ যদি আসল HTML হিসেবে আসে, তবে কোনো JavaScript চালানোর আগেই সেটি দেখা যায়। এটি সার্চ ইঞ্জিনেরও সাহায্য করে; দেখুন AI দিয়ে বানানো ওয়েবসাইটের SEO।
ধীর INP সাধারণত মানে একটি দীর্ঘ কাজ পেজকে আটকে রাখছে — প্রতি কি-স্ট্রোকে একটি বিশাল তালিকা ফিল্টার করা, বা একটি ঘর বদলালে পুরো টেবিল আবার রেন্ডার করা। Chrome DevTools-এর Performance প্যানেল দেখায় কোনটি।
ফন্ট
প্রতিটি ফন্ট পরিবার ও ওজন আরেকটি ফাইল। দুটি পরিবার ও তিন-চারটি ওজনই সাধারণত যথেষ্ট। ভাঁজের উপরে ব্যবহৃত ফন্ট প্রিলোড করুন, লেখা যেন সঙ্গে সঙ্গে দেখা যায় সেজন্য font-display: swap ব্যবহার করুন, এবং বাইরের ফন্ট সেবা আপনার দর্শকদের জন্য ধীর হলে ফন্ট নিজের সার্ভারে রাখুন।
তৃতীয় পক্ষের স্ক্রিপ্ট
চ্যাট উইজেট, অ্যানালিটিক্স, হিটম্যাপ, বিজ্ঞাপন পিক্সেল, এমবেড করা ভিডিও ও সোশ্যাল ফিড, সবই অন্য সার্ভার থেকে কোড লোড করে। প্রতিটি ছোট মনে হয়; একসঙ্গে সেগুলো প্রায়ই পেজের সবচেয়ে ধীর অংশ। যেগুলো আপনি সত্যিই ব্যবহার করেন সেগুলো রাখুন। বাকিগুলো পেজ ইন্টারঅ্যাকটিভ হওয়ার পরে লোড করুন, এবং ভারী এমবেড (YouTube প্লেয়ার, মানচিত্র) একটি হালকা প্রিভিউ দিয়ে বদলান, যা ক্লিক করলে আসল জিনিসটি লোড করে।
সার্ভারের সাড়া
Time to first byte (TTFB) — সার্ভার উত্তর শুরু করতে কতটা সময় নেয় — অন্য সব মেট্রিকের নিচে থাকে। CDN থেকে (দর্শকদের কাছাকাছি সার্ভারের একটি নেটওয়ার্ক; দেখুন CDN কী) পরিবেশিত স্ট্যাটিক পেজ প্রায় সবখানেই দ্রুত। প্রতিবার অনুরোধে সার্ভারের বানানো পেজ সেই সার্ভার ও তার ডেটাবেসের ওপর নির্ভর করে। পুনরাবৃত্ত কাজের জন্য ক্যাশিং এবং ধীর কোয়েরির জন্য ডেটাবেস ইনডেক্স যোগ করা সাধারণ সমাধান।
যে প্রম্পটগুলো কাজ করে
নির্দিষ্ট হোন: পেজ, মেট্রিক ও সীমাবদ্ধতা নাম দিন। PageSpeed Insights-এর ফলাফল থাকলে পেস্ট করুন।
PageSpeed Insights হোম পেজের মোবাইল LCP 4.8 s দেখাচ্ছে, এবং LCP উপাদান হলো হিরো ছবি। হিরো ছবিটি ছোট করে WebP-তে রূপান্তর করো, রেসপন্সিভ আকার দাও, width ও height সেট করো, fetchpriority="high" দাও এবং নিশ্চিত করো যে এটি lazy-load হচ্ছে না। ভাঁজের নিচের প্রতিটি ছবি lazy-load করো। ডিজাইন বদলাবে না।
এই অ্যাপের নির্ভরতাগুলো নিরীক্ষা করো। প্রতিটি প্যাকেজ, কোথায় ব্যবহৃত হয় এবং বান্ডলে আনুমানিক কতটা যোগ করে তার তালিকা দাও। ব্যবহার না হওয়াগুলো সরাও, এবং /admin ও /settings রুটকে আলাদা চাঙ্ক করো, যা কেবল ভিজিট করা হলে লোড হবে।
/products-এর সার্চ বক্স ধীর লাগছে। ফিল্টারে debounce দাও, প্রতি কি-স্ট্রোকে পুরো তালিকা আবার রেন্ডার করা বন্ধ করো, এবং তালিকায় 200টির বেশি আইটেম থাকলে পেজিনেশন বা ভার্চুয়ালাইজেশন করো।
ধাপে ধাপে
- লাইভ পেজটি পরীক্ষা করুন মোবাইলে PageSpeed Insights-এ। LCP, INP, CLS এবং তালিকাভুক্ত শীর্ষ তিনটি সমস্যা লিখে রাখুন।
- আগে ছবি ঠিক করুন: আকার, ফরম্যাট, মাত্রা, ভাঁজের নিচে lazy-loading, হিরোর জন্য অগ্রাধিকার।
- যে তৃতীয় পক্ষের স্ক্রিপ্ট ব্যবহার করেন না সেগুলো কাটুন, এবং বাকিগুলো পিছিয়ে দিন।
- ফন্ট ছাঁটুন যা ডিজাইনের প্রয়োজন তাতেই সীমিত রেখে।
- JavaScript কমান্: ব্যবহার না হওয়া প্যাকেজ সরান, রুট অনুযায়ী ভাগ করুন।
- পাবলিক পেজ প্রি-রেন্ডার করুন যদি সেগুলো এখনও ক্লায়েন্টে রেন্ডার হয় এবং LCP এখনও ধীর থাকে।
- সার্ভার যাচাই করুন: ক্যাশিং, ডেটাবেস ইনডেক্স, এবং যে কনটেন্ট কমই বদলায় তার জন্য স্ট্যাটিক হোস্টিং।
- আবার প্রকাশ করুন এবং পুনরায় পরীক্ষা করুন। PageSpeed Insights-এর ফিল্ড ডেটা পরের কয়েক সপ্তাহে আসল ভিজিট আসার সঙ্গে আপডেট হয়, তাই প্রাথমিক ফলাফল ল্যাব ডেটা দিয়ে বিচার করুন।
সাধারণ ভুল
- শুধু একটি দ্রুত ল্যাপটপে পরীক্ষা। আপনার দর্শকেরা মাঝারি মানের ফোন ও অস্থির মোবাইল ডেটায় আছেন। মোবাইল মোডে পরীক্ষা করুন।
- একটি নিখুঁত 100-এর পেছনে ছোটা। ল্যাব স্কোর একটি নির্দেশিকা। Core Web Vitals ভালো সীমায় এলে কনটেন্ট ও ব্যবহারযোগ্যতা শেষ কয়েক পয়েন্টের চেয়ে বেশি গুরুত্বপূর্ণ।
- সবকিছু lazy-load করা, হিরো ছবিসহ। তাতে LCP আরও খারাপ হয়।
- উপরে একটি স্পিড প্লাগইন বা লাইব্রেরি যোগ করা। ওজন কমানো প্রায় সবসময় সেটি পরিচালনার জন্য কোড যোগ করার চেয়ে ভালো।
- লাইভ সাইট নয়, প্রিভিউ অপ্টিমাইজ করা। ডেভেলপমেন্ট প্রিভিউ অপ্টিমাইজ না করা বিল্ড চালায়। প্রকাশিত URL মাপুন।
- একবার গতি ঠিক করা। প্রতিটি নতুন উইজেট, ছবি ও ফিচার ওজন যোগ করে। বড় পরিবর্তনের পর আবার পরীক্ষা করুন।
গতির চেকলিস্ট
- মোবাইলে LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1
- ছবি ছোট করা, সংকুচিত, আধুনিক ফরম্যাটে, width ও height সহ
- হিরো ছবি lazy নয়; ভাঁজের নিচের ছবি lazy-load
- ব্যবহার না হওয়া JavaScript লাইব্রেরি নেই; ভারী রুট আলাদা করা
- দুটি বা কম ফন্ট পরিবার, মূল ফন্ট প্রিলোড করা
- শুধু ব্যবহৃত তৃতীয় পক্ষের স্ক্রিপ্ট, দেরিতে লোড
- পাবলিক পেজ যেখানে সম্ভব প্রি-রেন্ডার বা স্ট্যাটিক
- প্রকাশের পর লাইভ URL-এ পুনরায় পরীক্ষা
গতি ও মোবাইল লেআউট একসঙ্গে চলে; দেখুন ওয়েবসাইট মোবাইল-রেসপন্সিভ কীভাবে করবেন। পুরো লঞ্চ-পূর্ব পর্যালোচনার জন্য AI প্রোটোটাইপ কীভাবে প্রোডাকশনে নেবেন বাকিটা ঢেকে দেয়।
Mythex-এ গতি
Mythex-এ এই পরিবর্তনগুলো আপনি চ্যাটে অনুরোধ করে করেন, অথবা Pro-তে কোড এডিটরে। লাইভ URL যাচাই করুন, প্রিভিউ নয়, কারণ প্রিভিউ একটি ডেভেলপমেন্ট সার্ভার চালায়। স্ট্যাটিক ফ্রন্ট-এন্ড প্রকাশের সময় স্ট্যাটিক সাইট হিসেবে ডিপ্লয় হয় (স্ট্যাটিক ওয়েবসাইট), যা কনটেন্ট পেজের জন্য উপযুক্ত। সার্ভারসহ অ্যাপগুলো শূন্যে নেমে যায়: অলস থাকলে ঘুমায় এবং পরের ভিজিটে জেগে ওঠে, তাই নীরব সময়ের পর প্রথম অনুরোধ ধীর হয়, আর সংযুক্ত ডেটাবেস ৫ মিনিট অলস থাকলে ঘুমিয়ে পড়ে (হোস্টিং সীমা)। কোনো পাবলিক পেজ শুধু প্রথম ভিজিটে ধীর হলে সেটিই সম্ভাব্য কারণ। মার্কেটিং পেজ স্ট্যাটিক রাখলে সাহায্য হয়। পরিবর্তনের পর আবার প্রকাশ করুন এবং হার্ড-রিফ্রেশ দিন।
প্রশ্নোত্তর
ভালো পেজ লোড সময় কত?
Google-এর Core Web Vitals সবচেয়ে স্পষ্ট লক্ষ্য দেয়: মূল কনটেন্ট 2.5 সেকেন্ডের মধ্যে দেখা যাওয়া উচিত (LCP), পেজ ইনপুটে 200 মিলিসেকেন্ডের মধ্যে সাড়া দেওয়া উচিত (INP), এবং লেআউট শিফট 0.1 বা তার কম থাকা উচিত (CLS); এগুলো প্রকৃত ভিজিটের 75তম পার্সেন্টাইলে মাপা হয়।
ওয়েবসাইটের গতি কি SEO-কে প্রভাবিত করে?
একটু করে। Google Core Web Vitals সহ পেজ অভিজ্ঞতার সংকেত ব্যবহার করে, তবে প্রাসঙ্গিক কনটেন্ট অনেক বেশি গুরুত্বপূর্ণ। গতির প্রভাব দর্শকদের ওপর বেশি, কারণ ধীর পেজ তারা পড়ার আগেই ছেড়ে চলে যান।
আমার PageSpeed Insights স্কোর প্রতিবার আলাদা আসে কেন?
ল্যাব স্কোর একটিমাত্র সিমুলেটেড লোড থেকে আসে, তাই নেটওয়ার্ক ও সার্ভারের সময় প্রতিবার আলাদা হয়। কয়েকবার চালিয়ে প্রবণতা দেখুন, এবং ফিল্ড ডেটা বিভাগে বেশি গুরুত্ব দিন, যা প্রকৃত Chrome ব্যবহারকারীদের থেকে আসে।
বেশিরভাগ ওয়েবসাইট কোন জিনিসে ধীর হয়?
সাধারণত অতিরিক্ত বড় ছবি, অনেক বেশি JavaScript, ওয়েব ফন্ট এবং তৃতীয় পক্ষের স্ক্রিপ্ট, যেমন চ্যাট উইজেট, বিজ্ঞাপন পিক্সেল ও এমবেড। ধীর সার্ভারের সাড়া বা ঠান্ডা অবস্থা থেকে চালু হওয়া ব্যাকএন্ড এর সঙ্গে যোগ হয়।