Mobile Website ধীর হলে কোন Resource আগে পরীক্ষা করবেন

মোবাইলে ওয়েবসাইট ধীর হলে অনেকেই প্রথমে ইমেজ কমপ্রেস করেন, ক্যাশ প্লাগইনের সেটিং বদলান বা JavaScript ছোট করার কাজ শুরু করেন। কিন্তু সমস্যাটি যদি মূল HTML রেসপন্স পেতেই দেরি হওয়ার কারণে তৈরি হয়, তাহলে এসব পরিবর্তনে খুব বেশি লাভ নাও হতে পারে। আবার TTFB ভালো হলেও প্রধান কনটেন্টের ছবি দেরিতে শনাক্ত হলে Largest Contentful Paint বা LCP খারাপ থাকতে পারে।

তাই মোবাইল পেজ স্পিড সমস্যায় কোনো একটি রিসোর্স সব সাইটে আগে পরীক্ষা করার নিয়ম নেই। আগে খুঁজতে হবে মূল বাধা কোথায়। ব্যবহারিকভাবে ক্রমটি হতে পারে: ডকুমেন্ট রেসপন্স ও TTFB → LCP রিসোর্স → রেন্ডার-ব্লকিং CSS/JavaScript → অব্যবহৃত কোড → ফন্ট → তৃতীয় পক্ষের রিসোর্স। তবে PageSpeed Insights ও DevTools যা দেখাচ্ছে, তার ভিত্তিতে এই অগ্রাধিকার বদলাবে।

Google-এর বর্তমান Core Web Vitals-এ ভালো LCP হলো 2.5 সেকেন্ড বা কম, INP 200 মিলিসেকেন্ড বা কম এবং CLS 0.1 বা কম। সাধারণত 75তম পার্সেন্টাইল ধরে এই মূল্যায়ন করা হয়।

PageSpeed Insights রিপোর্টে আগে কী দেখবেন

PageSpeed Insights-এ URL পরীক্ষা করার পর মোবাইল ও ডেস্কটপ ফল আলাদা করে দেখুন। ডেস্কটপে একটি পেজ দ্রুত চললেও ধীর নেটওয়ার্ক বা সীমিত প্রসেসিং ক্ষমতার মোবাইল ডিভাইসে একই অভিজ্ঞতা নাও হতে পারে।

রিপোর্টে দুই ধরনের তথ্য বিশেষভাবে কাজে লাগে।

বাস্তব ব্যবহারকারীর তথ্য বা Field Data: এটি Chrome User Experience Report বা CrUX থেকে আসে। PageSpeed Insights-এ আগের 28 দিনের বাস্তব Chrome ব্যবহারকারীর অভিজ্ঞতা দেখা যায়। নির্দিষ্ট URL-এর জন্য পর্যাপ্ত তথ্য না থাকলে পুরো ওয়েবসাইটের মূল ডোমেইনভিত্তিক তথ্য দেখানো হতে পারে।

পরীক্ষাগারভিত্তিক তথ্য বা Lab Data: Lighthouse নিয়ন্ত্রিত বা সিমুলেটেড পরিবেশে পেজ পরীক্ষা করে। কোন রিসোর্স রেন্ডার আটকে দিচ্ছে, LCP রিসোর্স কখন শনাক্ত হচ্ছে বা কোথায় অতিরিক্ত কোড পাঠানো হচ্ছে—এসব সমস্যা চিহ্নিত করতে এই তথ্য বেশি কার্যকর।

এ কারণে শুধু পারফরম্যান্স স্কোর দেখে সিদ্ধান্ত নেওয়া ঠিক নয়। বাস্তব ব্যবহারকারীর তথ্য বলবে তারা সমস্যায় পড়ছেন কি না; Lighthouse ও DevTools সাহায্য করবে সমস্যার কারণ আলাদা করতে।

Lighthouse 13-এ কিছু পুরোনো পারফরম্যান্স অডিটের নাম ও বিন্যাস বদলেছে। যেমন সার্ভার রেসপন্স সম্পর্কিত অডিট এখন Document request latency, পুরোনো render-blocking audit এখন Render-blocking requests, আর LCP ইমেজ-সংক্রান্ত তথ্য LCP discovery ও LCP phases অংশে পাওয়া যায়। তৃতীয় পক্ষের রিসোর্সের জন্য রয়েছে Third parties অংশ।

ধাপ ১: TTFB বেশি হলে সার্ভার ও ডকুমেন্ট রেসপন্স আগে দেখুন

Time to First Byte বা TTFB হলো নেভিগেশন শুরু হওয়ার পর ব্রাউজার মূল HTML ডকুমেন্টের প্রথম বাইট পেতে কত সময় নিচ্ছে তার পরিমাপ।

এখানে শুধু সার্ভারে কোড প্রক্রিয়াকরণের সময় নয়। রিডাইরেক্ট, সংযোগ স্থাপন এবং নেটওয়ার্ক বিলম্বও TTFB-কে প্রভাবিত করতে পারে।

TTFB Core Web Vital নয়, তবে এটি FCP ও LCP-এর আগের ধাপে ঘটে। ফলে এখানে বড় দেরি থাকলে পরের লোডিং মেট্রিকগুলোও পিছিয়ে যেতে পারে।

web.dev বেশির ভাগ সাইটের জন্য 0.8 সেকেন্ড বা কম TTFB-কে একটি ব্যবহারিক লক্ষ্য হিসেবে দেখায়। 1.8 সেকেন্ডের বেশি দুর্বল অবস্থান হিসেবে ধরা হয়। এগুলো সমস্যা শনাক্তের নির্দেশক; প্রতিটি সাইটের জন্য কঠোর পাস বা ফেল নিয়ম নয়।

TTFB বেশি হলে একে একে পরীক্ষা করুন:

• অপ্রয়োজনীয় রিডাইরেক্টের ধাপ আছে কি না;
• পেজ বা সার্ভার ক্যাশ প্রত্যাশামতো কাজ করছে কি না;
• PHP বা অ্যাপ্লিকেশন প্রসেসিং অস্বাভাবিক সময় নিচ্ছে কি না;
• ডেটাবেস কুয়েরি ধীর কি না;
• হোস্টিং রিসোর্স বা সার্ভারের সক্ষমতা মূল বাধা তৈরি করছে কি না;
• ব্যবহারকারী থেকে মূল সার্ভার অনেক দূরে হলে CDN বা এজ ক্যাশিং ব্যবহার করে বিলম্ব কমানো সম্ভব কি না।

এখানে অগ্রাধিকার পরিষ্কার: TTFB স্পষ্টভাবে খারাপ হলে হিরো ইমেজের কয়েক কিলোবাইট কমানো দিয়ে শুরু করা যুক্তিযুক্ত নয়।

মূল HTML-এর প্রথম বাইট ব্রাউজারে পৌঁছানোর আগ পর্যন্ত সেই ডকুমেন্টের মার্কআপ দেখে নির্ভরশীল রিসোর্স শনাক্ত করা সম্ভব হয় না। তাই ডকুমেন্ট রেসপন্সে দেরি পুরো লোডিং ধাপকে পিছিয়ে দিতে পারে।

ধাপ ২: TTFB গ্রহণযোগ্য হলে LCP এলিমেন্ট খুঁজুন

TTFB মোটামুটি ভালো, কিন্তু LCP বেশি—এ অবস্থায় পরের কাজ হলো LCP এলিমেন্ট শনাক্ত করা।

নিউজ আর্টিকেল, ব্লগ, ই-কমার্স বা ল্যান্ডিং পেজে এটি হিরো বা ফিচার্ড ইমেজ হতে পারে। আবার বড় শিরোনাম বা টেক্সট ব্লকও LCP হতে পারে।

LCP শুধু “ইমেজ কত বড়” তার মাপ নয়। এর দেরি কয়েক জায়গায় তৈরি হতে পারে:

• TTFB
• রিসোর্স লোড শুরু হওয়ার দেরি
• রিসোর্স ডাউনলোড হতে লাগা সময়
• এলিমেন্ট রেন্ডার হওয়ার দেরি

অর্থাৎ 100 KB-এর একটি ইমেজও খারাপ LCP তৈরি করতে পারে, যদি ব্রাউজার সেটি দেরিতে শনাক্ত করে। আবার বড় ইমেজ দ্রুত ডাউনলোড হলেও CSS বা JavaScript-এর কারণে রেন্ডার দেরি হতে পারে।

LCP যদি ইমেজ হয়

Chrome DevTools বা Lighthouse-এর LCP অংশ থেকে আগে দেখুন ইমেজ রিকোয়েস্ট কখন শুরু হচ্ছে।

তারপর যাচাই করুন:

• ইমেজের src বা srcset প্রাথমিক HTML-এ আছে কি না;
• JavaScript দিয়ে পরে ইমেজ যোগ করা হচ্ছে কি না;
• CSS ব্যাকগ্রাউন্ড ইমেজ হওয়ার কারণে ব্রাউজার সেটি দেরিতে শনাক্ত করছে কি না;
• LCP ইমেজে loading=”lazy” দেওয়া আছে কি না;
• প্রদর্শনের আকারের তুলনায় অনেক বড় ইমেজ পাঠানো হচ্ছে কি না;
• বিভিন্ন স্ক্রিনের জন্য উপযোগী ইমেজ দিতে srcset ও sizes প্রয়োজন কি না।

Google-এর LCP নির্দেশনা অনুযায়ী LCP ইমেজ lazy-load না করাই উচিত। সম্ভাব্য LCP ইমেজের ক্ষেত্রে fetchpriority=”high” ব্রাউজারকে রিসোর্সটির গুরুত্ব সম্পর্কে ইঙ্গিত দিতে পারে। CSS ব্যাকগ্রাউন্ডের মতো দেরিতে শনাক্ত হওয়া গুরুত্বপূর্ণ ইমেজের ক্ষেত্রে preload কাজে লাগতে পারে।

তবে একটি রিসোর্সে preload বা উচ্চ অগ্রাধিকার কাজে দিয়েছে বলে সব গুরুত্বপূর্ণ রিসোর্সে একই কৌশল ব্যবহার করা ঠিক নয়। অতিরিক্ত অগ্রাধিকার দিলে রিসোর্সগুলো নিজেদের মধ্যেই ব্যান্ডউইথের জন্য প্রতিযোগিতা করতে পারে।

ইমেজের ফাইল সাইজ, ফরম্যাট ও বিভিন্ন স্ক্রিনে সঠিকভাবে ইমেজ পাঠানো নিয়ে আলাদা অডিট করতে “ওয়েবসাইটের ইমেজ অপ্টিমাইজ করার কার্যকর কৌশল” নিবন্ধটি অভ্যন্তরীণ লিংক হিসেবে ব্যবহার করা যেতে পারে।

ধাপ ৩: রিসোর্স ডাউনলোড হয়েছে, কিন্তু রেন্ডার হচ্ছে দেরিতে?

LCP রিসোর্স দ্রুত ডাউনলোড হওয়ার পরও স্ক্রিনে দেরিতে দেখা গেলে CSS, JavaScript ও মূল প্রসেসিং থ্রেডের কাজের দিকে তাকান।

ব্রাউজার প্রাথমিক রেন্ডারিংয়ের আগে প্রয়োজনীয় স্টাইলশিট প্রসেস করে। একইভাবে <head> অংশে থাকা async বা defer ছাড়া সাধারণ JavaScript HTML বিশ্লেষণের কাজ থামিয়ে দিতে পারে।

Lighthouse ও DevTools-এর Render-blocking requests অংশ থেকে দেখা যায় কোন রিকোয়েস্ট প্রাথমিক রেন্ডার বিলম্বিত করছে।

এ অবস্থায় সম্ভাব্য কাজ হতে পারে:

• প্রথম স্ক্রিনে সত্যিই প্রয়োজনীয় CSS আলাদা করা;
• কম গুরুত্বপূর্ণ স্টাইলশিট পরে লোড করা;
• অব্যবহৃত CSS সরানো;
• প্রাথমিক রেন্ডারের আগে প্রয়োজন নেই এমন JavaScript-এ উপযুক্ত ক্ষেত্রে defer বা async ব্যবহার করা;
• বড় JavaScript বান্ডল ভেঙে প্রয়োজন অনুযায়ী কোড পাঠানো।

তবে “সব JavaScript defer করুন” বা “সব CSS inline করুন”—এ ধরনের এক নিয়মে সব সমাধান করার পরামর্শ নিরাপদ নয়।

WordPress অপ্টিমাইজেশন প্লাগইনের আক্রমণাত্মক সেটিং মেনু, সার্চ, ফর্ম, অ্যানালিটিকস, সম্মতি ব্যানার বা চেকআউট ভেঙে দিতে পারে। পারফরম্যান্স স্কোর বাড়লেই কাজ শেষ নয়; পরিবর্তনের পর পেজের প্রয়োজনীয় কার্যকারিতাও পরীক্ষা করতে হবে।

আরও পড়ুনঃ H1, H2 ও H3 সঠিকভাবে ব্যবহার করার নিয়ম

ধাপ ৪: অব্যবহৃত JS/CSS বেশি হলে শুধু ছোট নয়, পাঠানো কোডও কমান

বড় JavaScript ফাইলের সমস্যা শুধু ডাউনলোড সাইজ নয়। ব্রাউজারকে কোড বিশ্লেষণ, কম্পাইল ও চালাতে হয়। বিশেষ করে তুলনামূলক দুর্বল মোবাইল CPU-তে অতিরিক্ত JavaScript মূল প্রসেসিং থ্রেড ব্যস্ত রাখতে পারে।

Chrome DevTools-এর Coverage অংশ দেখায় বর্তমান পেজ লোড বা ব্যবহারকারীর কাজের সময় কত CSS ও JavaScript ব্যবহৃত হয়েছে এবং কত অংশ অব্যবহৃত রয়েছে।

WordPress সাইটে এই অডিট বেশ কার্যকর, কারণ একই থিম বা প্লাগইন অনেক সময় প্রয়োজন না থাকা পেজেও সম্পদ লোড করে।

দেখুন:

• থিম সব পেজে বড় JavaScript বান্ডল পাঠাচ্ছে কি না;
• কোনো প্লাগইন একটি নির্দিষ্ট পেজে দরকার হলেও পুরো সাইটে স্ক্রিপ্ট বা CSS লোড করছে কি না;
• পেজ বিল্ডারের ব্যবহার না করা কম্পোনেন্টের কোড আসছে কি না;
• একই ধরনের লাইব্রেরি একাধিক প্লাগইন থেকে লোড হচ্ছে কি না।

এখানে শুধু minification দিয়ে মূল সমস্যা ঢাকার চেষ্টা করা ঠিক নয়। বড় অব্যবহৃত বান্ডল ছোট করলে ফাইলের আকার কিছুটা কমবে, কিন্তু ব্রাউজারকে এখনও অপ্রয়োজনীয় কোড ডাউনলোড ও প্রসেস করতে হবে।

বাস্তব ব্যবহারকারীর তথ্যে INP খারাপ এবং DevTools-এ দীর্ঘ সময় ধরে মূল থ্রেড ব্যস্ত থাকার কাজ দেখা গেলে JavaScript অডিটের অগ্রাধিকার আরও বাড়বে।

ফন্ট কখন আগে পরীক্ষা করবেন

ফন্ট সাধারণত ধীর মোবাইল পেজের প্রথম সন্দেহভাজন নয়। তবে দুটি পরিস্থিতিতে এর গুরুত্ব দ্রুত বেড়ে যায়।

প্রথমটি, LCP যদি বড় শিরোনাম বা টেক্সট ব্লক হয়। দ্বিতীয়টি, কাস্টম ফন্ট আসার আগে টেক্সট দেরিতে দেখা যাচ্ছে বা ফন্ট বদলের সময় লেআউট সরে যাচ্ছে।

তখন পরীক্ষা করুন:

• প্রয়োজনের চেয়ে বেশি ফন্ট পরিবার লোড হচ্ছে কি না;
• অপ্রয়োজনীয় ফন্টের ওজন ও ধরন পাঠানো হচ্ছে কি না;
• WOFF2-এর মতো উপযুক্ত ফরম্যাট ব্যবহার হচ্ছে কি না;
• গুরুত্বপূর্ণ ফন্ট দেরিতে শনাক্ত হচ্ছে কি না;
• font-display কৌশল পেজটির জন্য উপযুক্ত কি না;
• preload করা ফন্ট প্রাথমিক কনটেন্টে সত্যিই ব্যবহৃত হচ্ছে কি না।

ফন্ট preload-ও সীমিতভাবে ব্যবহার করা উচিত। অপ্রয়োজনীয় ফন্ট preload করলে সেই ডাউনলোড অন্য গুরুত্বপূর্ণ রিসোর্সের ব্যান্ডউইথ নিতে পারে।

নিজের কোড হালকা, তবু পেজ ধীর? তৃতীয় পক্ষের রিসোর্স দেখুন

নিজস্ব ইমেজ, CSS ও JavaScript বেশ হালকা হওয়ার পরও মোবাইল পেজ ধীর থাকলে অ্যানালিটিকস, বিজ্ঞাপন, চ্যাট উইজেট, সামাজিক মাধ্যমের এমবেড, ভিডিও প্লেয়ার, ট্যাগ ম্যানেজার এবং অন্যান্য তৃতীয় পক্ষের রিসোর্স পরীক্ষা করুন।

এগুলো কয়েকভাবে পারফরম্যান্স কমাতে পারে:

• অতিরিক্ত নেটওয়ার্ক সংযোগ;
• বেশি ডাউনলোড হওয়া ডেটা;
• JavaScript চালানোর অতিরিক্ত কাজ;
• মূল CPU থ্রেডে বাড়তি চাপ।

বর্তমান Chrome পারফরম্যান্স টুলের Third parties অংশ এ ধরনের রিসোর্স আলাদা করে দেখতে সাহায্য করে।

প্রতিটি তৃতীয় পক্ষের রিসোর্স নিয়ে চারটি প্রশ্ন করুন:

1. এটি কি সত্যিই প্রয়োজনীয়?
2. পেজ প্রথমবার লোড হওয়ার সময়ই কি এটি চালু হওয়া দরকার?
3. একই কাজের জন্য একাধিক সেবা ব্যবহার হচ্ছে কি?
4. ব্যবহারকারীর কাজ শুরু হওয়ার পরে এটি লোড করলেও কাজ চলবে কি?

কিছু কম গুরুত্বপূর্ণ এমবেড lazy-load করা যায়। কিছু স্ক্রিপ্টে async বা defer ব্যবহার করা সম্ভব। তবে কোন স্ক্রিপ্ট অন্যটির ওপর নির্ভরশীল এবং কী কাজ করছে, তা না বুঝে এগুলো প্রয়োগ করা উচিত নয়।

অ্যানালিটিকস, বিজ্ঞাপন, সম্মতি ব্যবস্থাপনা বা আয়-সংশ্লিষ্ট স্ক্রিপ্ট সরানোর আগে ব্যবসায়িক প্রভাব পরীক্ষা করাও জরুরি।

লক্ষণ দেখে কোন রিসোর্স আগে ধরবেন

দ্রুত সমস্যা শনাক্তের জন্য নিচের তালিকাটি ব্যবহার করা যায়।

মূল বিষয় হলো—ফাইলের ধরন দেখে অপ্টিমাইজেশন শুরু করবেন না; মাপা যায় এমন মূল বাধা দেখে অগ্রাধিকার ঠিক করুন।

PageSpeed Insights দিয়ে ব্যবহারিক মোবাইল পেজ স্পিড অডিট

একটি পেজ নিয়ে কাজ করলে নিচের ক্রম যথেষ্ট বাস্তবসম্মত।

১. মোবাইলের বাস্তব ব্যবহারকারীর তথ্য দেখুন

LCP, INP ও CLS-এর মধ্যে কোন মেট্রিক খারাপ তা চিহ্নিত করুন।

২. ডকুমেন্ট রিকোয়েস্ট ও TTFB দেখুন

এখানেই বড় দেরি থাকলে ব্যাকএন্ড, রিডাইরেক্ট, ক্যাশ ও ডেলিভারি ব্যবস্থা আগে পরীক্ষা করুন।

৩. LCP এলিমেন্ট শনাক্ত করুন

ইমেজ হলে শনাক্ত হওয়ার সময়, অগ্রাধিকার ও ডাউনলোডের সময় দেখুন। টেক্সট হলে ফন্ট ও রেন্ডারে দেরির দিকেও তাকান।

৪. রেন্ডার-ব্লকিং রিকোয়েস্ট পরীক্ষা করুন

কোন স্টাইলশিট বা স্ক্রিপ্ট প্রাথমিক রেন্ডারিং পিছিয়ে দিচ্ছে তা বের করুন।

৫. অব্যবহৃত JS/CSS এবং মূল থ্রেডের কাজ দেখুন

বিশেষ করে থিম, প্লাগইন এবং তৃতীয় পক্ষের JavaScript আলাদা করে দেখুন।

৬. প্রয়োজন হলে ফন্ট ও তৃতীয় পক্ষের রিসোর্স অডিট করুন

এগুলো গুরুত্বপূর্ণ লোডিং ধাপ বা ব্যবহারকারীর প্রতিক্রিয়ার গতিতে কতটা প্রভাব ফেলছে, তা মাপুন।

৭. পরিবর্তনের পর আবার পরীক্ষা করুন

একসঙ্গে অনেক অপ্টিমাইজেশন করলে কোনটি ফল দিয়েছে বোঝা কঠিন হয়। গুরুত্বপূর্ণ পরিবর্তনগুলো আলাদাভাবে মাপা ভালো।

একই পেজে Lighthouse-এর একাধিক পরীক্ষায় কিছু পার্থক্য দেখা যেতে পারে। নেটওয়ার্কের অবস্থা, হার্ডওয়্যারের সক্ষমতা ও রিসোর্স ব্যবহারের চাপের কারণে পরীক্ষার ফল ওঠানামা করতে পারে। বাস্তব ব্যবহারকারীর তথ্য আবার আগের 28 দিনের অভিজ্ঞতা দেখায়।

Core Web Vitals-এর মেট্রিক ও সীমা বুঝতে “কোর ওয়েব ভাইটালস (Core Web Vitals) কী ও কেন গুরুত্বপূর্ণ” নিবন্ধটি সহায়ক অভ্যন্তরীণ লিংক হতে পারে।

মোবাইল পেজ স্পিড অডিটে যে ভুলগুলো বেশি দেখা যায়

Lighthouse Score 100-কেই লক্ষ্য ধরা:

পারফরম্যান্স স্কোর একটি সমস্যা শনাক্তের সংকেত। বাস্তব ব্যবহারকারীর অভিজ্ঞতা ভালো কি না, সেটিও আলাদা করে দেখতে হবে।

TTFB না দেখে ইমেজ অপ্টিমাইজেশন শুরু করা:

মূল ডকুমেন্ট রেসপন্স দেরি হলে নির্ভরশীল রিসোর্স শনাক্ত করাও পিছিয়ে যেতে পারে।

LCP ইমেজ lazy-load করা:

এতে গুরুত্বপূর্ণ ইমেজের ডাউনলোড শুরু হতে দেরি হতে পারে।

সব রিসোর্স preload করা:

অতিরিক্ত preload করলে ব্যান্ডউইথের প্রতিযোগিতা বাড়তে পারে এবং প্রয়োজন না থাকা রিসোর্সও আগেভাগে ডাউনলোড হতে পারে।

একটি Lighthouse পরীক্ষাকেই চূড়ান্ত ফল ধরা:

পরীক্ষাগারভিত্তিক ফল কিছুটা পরিবর্তিত হতে পারে। সম্ভব হলে একাধিক পরীক্ষা এবং বাস্তব ব্যবহারকারীর তথ্য মিলিয়ে দেখুন।

তৃতীয় পক্ষের কোডকে অডিটের বাইরে রাখা:

নিজের থিম হালকা হলেও বিজ্ঞাপন, অ্যানালিটিকস, এমবেড বা ট্যাগ ম্যানেজার নেটওয়ার্ক ও CPU—দুই দিকেই অতিরিক্ত চাপ তৈরি করতে পারে।

প্রথম অপ্টিমাইজেশন কোথা থেকে শুরু করবেন

মোবাইল পেজ স্পিড কমে গেলে প্রথম কাজ ইমেজ, CSS বা JavaScript-এর মধ্যে কাউকে স্বয়ংক্রিয়ভাবে দায়ী করা নয়।

যদি ডকুমেন্ট রেসপন্সেই দেরি থাকে, TTFB ও সার্ভারের ডেলিভারি পথ আগে ঠিক করুন। সেটি গ্রহণযোগ্য হলে LCP রিসোর্স কোথায় সময় হারাচ্ছে দেখুন। এরপর রেন্ডার-ব্লকিং রিসোর্স এবং অব্যবহৃত JavaScript/CSS পরীক্ষা করুন। ফন্ট ও তৃতীয় পক্ষের স্ক্রিপ্ট তখনই বেশি অগ্রাধিকার পাবে, যখন পরিমাপ দেখাচ্ছে সেগুলোই মূল বাধা তৈরি করছে।

এই ক্রম মেনে কাজ করলে প্রতিটি অপ্টিমাইজেশনের কারণ পরিষ্কার থাকে। একসঙ্গে অনেক সেটিং বদলে শুধু স্কোর বাড়ানোর চেষ্টা না করে একটি মূল বাধা শনাক্ত করুন, একটি পরিবর্তন করুন, তারপর ফল মাপুন।

নিবন্ধের শেষে এই অংশটি যোগ করতে পারেন:

শেষ কথা

মোবাইল ওয়েবসাইট ধীর হলে সমস্যার সমাধান শুরু করা উচিত অনুমান দিয়ে নয়, পরিমাপ দিয়ে। সব সাইটে একই কারণে গতি কমে না—কোথাও TTFB মূল বাধা, কোথাও LCP ইমেজ, আবার কোথাও অতিরিক্ত JavaScript, ফন্ট বা তৃতীয় পক্ষের স্ক্রিপ্ট সমস্যা তৈরি করে।

তাই কার্যকর Mobile page speed optimization-এর সবচেয়ে বাস্তবসম্মত পদ্ধতি হলো প্রথমে PageSpeed Insights ও DevTools দিয়ে মূল bottleneck শনাক্ত করা, তারপর একটি করে পরিবর্তন করা এবং ফল পুনরায় মাপা। এতে অপ্রয়োজনীয় optimization কমে, কোন পরিবর্তনে আসল উন্নতি এসেছে তা বোঝা যায় এবং মোবাইল ব্যবহারকারীর অভিজ্ঞতা উন্নত করার কাজটি আরও নির্ভুলভাবে করা সম্ভব হয়।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

প্রায়শই জিজ্ঞাসিত প্রশ্ন

১. মোবাইল ওয়েবসাইট ধীর হলে প্রথমে কোন রিসোর্স পরীক্ষা করা উচিত?

সব সাইটে একই রিসোর্স আগে পরীক্ষা করার নিয়ম নেই। PageSpeed Insights বা DevTools দিয়ে আগে bottleneck শনাক্ত করুন। TTFB বেশি হলে সার্ভার ও ডকুমেন্ট রেসপন্স, আর TTFB ভালো কিন্তু LCP খারাপ হলে LCP ইমেজ বা সংশ্লিষ্ট রিসোর্স আগে পরীক্ষা করা বেশি যুক্তিযুক্ত।

২. LCP ইমেজে lazy loading ব্যবহার করা উচিত কি?

সাধারণভাবে LCP হিসেবে ব্যবহৃত প্রধান ইমেজে loading=”lazy” ব্যবহার না করাই ভালো। এতে ব্রাউজার গুরুত্বপূর্ণ ইমেজটি দেরিতে লোড শুরু করতে পারে। প্রয়োজন হলে fetchpriority=”high” বা নির্দিষ্ট ক্ষেত্রে preload ব্যবহার করা যেতে পারে, তবে পরিবর্তনের পর ফল মেপে দেখা জরুরি।

৩. PageSpeed Insights-এ ভালো স্কোর পেলেই কি মোবাইল সাইট দ্রুত?

অবশ্যই নয়। Lighthouse-এর Performance Score মূলত পরীক্ষাগারভিত্তিক একটি নির্দেশক। বাস্তব ব্যবহারকারীর অভিজ্ঞতা বুঝতে PageSpeed Insights-এর Field Data এবং LCP, INP ও CLS-এর মতো Core Web Vitals-ও দেখতে হবে। একাধিক পরীক্ষার ফল মিলিয়ে সিদ্ধান্ত নেওয়াই বেশি নির্ভরযোগ্য।