ফ্রি পারফরম্যান্স টুল

ওয়েবসাইট স্পিড টেস্ট

আমরা ধীর 4G সংযোগে একটি মাঝারি মানের ফোনের মতো করে আপনার পেজ লোড করি, মূল কনটেন্ট কত দ্রুত দেখা যায় এবং পেজ কতটা নড়েচড়ে ওঠে তা মাপি, আর পেজটি কী কারণে ভারী তা দেখাই। আপনার সাইটের জন্য Google-এর কাছে রিয়েল-ইউজার ডেটা থাকলে সেটিও দেখতে পান।

ফ্রি। সাধারণত এক মিনিটের কম সময়ে শেষ হয়।

এই টুল কী যাচাই করে

  • ধীর 4G-তে একটি ফোন

    পেজটি Chromium-এ Moto G Power শ্রেণির একটি ফোন (412 × 823) হিসেবে লোড হয়, সঙ্গে 150 ms লেটেন্সি, প্রায় 1.6 Mbps ডাউনলোড ও 750 Kbps আপলোড, এবং 4× ধীর CPU। Lighthouse মোবাইল পরীক্ষায় এই প্রোফাইলই ব্যবহার করে।

  • Largest Contentful Paint

    প্রথম স্ক্রিনের সবচেয়ে বড় ছবি বা লেখার ব্লক কখন রেন্ডার হওয়া শেষ করেছে, এবং সেটি কোন এলিমেন্ট ছিল।

  • Cumulative Layout Shift

    পেজ লোড হওয়ার সময় দৃশ্যমান কনটেন্ট অপ্রত্যাশিতভাবে কতটা সরে গেছে।

  • Total Blocking Time

    স্ক্রিপ্টগুলো কতক্ষণ ব্রাউজারকে এতটাই ব্যস্ত রেখেছে যে সেটি ট্যাপে সাড়া দিতে পারেনি: প্রতিটি লম্বা টাস্কের 50 ms-এর বেশি অংশগুলোর যোগফল। ল্যাবে এটি Interaction to Next Paint-এর বিকল্প হিসেবে কাজ করে।

  • পেজ কী কী ডাউনলোড করে

    মোট বাইট ও রিকোয়েস্ট, ছবি, স্ক্রিপ্ট, CSS ও ফন্টে ভাগ করে, এবং তার কত অংশ থার্ড পার্টি থেকে আসে।

  • ভারী ছবি ও রেন্ডার-ব্লকিং ফাইল

    150 KB-এর বেশি ছবি, বা যেসব ছবি দেখানোর জায়গার চেয়ে অনেক বেশি চওড়া, এবং যেসব CSS ও স্ক্রিপ্ট ফাইল প্রথম রেন্ডার আটকে রাখে।

  • Chrome থেকে রিয়েল-ইউজার ডেটা

    ফোনে আপনার অরিজিনের জন্য 75তম পার্সেন্টাইলে Google-এর Chrome UX Report: LCP, INP ও CLS, যদি সাইটটির জন্য Google-এর কাছে যথেষ্ট ট্রাফিক থাকে।

যা এটি যাচাই করতে পারে না

  • প্রতিবার একই সংখ্যা দেওয়া। ল্যাবের ফলাফল নেটওয়ার্ক, সার্ভারের লোড ও থার্ড-পার্টি স্ক্রিপ্টের সঙ্গে বদলায়, তাই একক রানের বদলে প্রবণতা তুলনা করুন।
  • PageSpeed Insights-এর সঙ্গে হুবহু মেলা। দুটিই একই ধরনের ফোন প্রোফাইল ব্যবহার করে, কিন্তু ভিন্ন মেশিন ও নেটওয়ার্কে চলে।
  • ল্যাবে INP মাপা। INP-এর জন্য আসল ইন্টারঅ্যাকশন দরকার, তাই ল্যাব পরীক্ষা TBT দেখায়, আর ফিল্ড ডেটা থাকলে তা INP দেখায়।
  • প্রতিটি সাইটের জন্য ফিল্ড ডেটা দেখানো। Chrome UX Report শেষ 28 দিনের তথ্য রাখে, এবং কেবল সেইসব অরিজিনের, যেগুলোতে যথেষ্ট Chrome ট্রাফিক আছে।
  • আপনার দেওয়া একটি পেজের বেশি পরীক্ষা করা। পেইড পারফরম্যান্স সংশোধন রিপোর্ট 3টি গুরুত্বপূর্ণ পেজ পরীক্ষা করে এবং কারণগুলো সমাধানসহ গুরুত্ব অনুযায়ী সাজায়।

কেন এটি গুরুত্বপূর্ণ

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

Core Web Vitals হলো সেই অভিজ্ঞতা মাপার জন্য Google-এর মাপকাঠি: লোডিং (LCP), সাড়া দেওয়ার ক্ষমতা (INP) ও দৃশ্যগত স্থিতিশীলতা (CLS)। Google র‍্যাংকিংয়ে এগুলো ব্যবহার করে, তবে বলে যে ভালো পেজ অভিজ্ঞতা প্রাসঙ্গিক কনটেন্টের চেয়ে বেশি গুরুত্ব পায় না। এগুলোর বড় প্রভাব পড়ে মানুষের ওপর: ধীর বা লাফিয়ে ওঠা পেজ কিছু পড়ার আগেই ভিজিটর হারায়।

কারণগুলো সাধারণত সুনির্দিষ্ট: কয়েক মেগাবাইটের একটি অসংকুচিত হিরো ছবি, কনটেন্টের আগে লোড হওয়া একটি চ্যাট উইজেট, লেখা লুকিয়ে রাখা একটি ওয়েব ফন্ট, কিংবা পেজ দেখা দেওয়ার পর তার ওপরে ঢোকানো একটি ব্যানার। পরীক্ষাটি LCP এলিমেন্ট ও সবচেয়ে ভারী ফাইলগুলোর নাম জানায়, যাতে আপনি দেখতে পান এর কোনটি আপনার ক্ষেত্রে প্রযোজ্য।

ফলাফল কীভাবে বুঝবেন

Largest Contentful Paint (LCP)
2.5 s-এর কম হলে ভালো, 4 s-এর বেশি হলে খারাপ। LCP এলিমেন্ট ছবি হলে তার আকার ও লোডিং অগ্রাধিকারই সবচেয়ে গুরুত্বপূর্ণ; লেখা হলে ওয়েব ফন্ট ও রেন্ডার-ব্লকিং CSS দেখুন।
Cumulative Layout Shift (CLS)
0.1-এর কম হলে ভালো, 0.25-এর বেশি হলে খারাপ। এটি এককবিহীন একটি স্কোর, যা স্ক্রিনের কতটা অংশ সরেছে এবং কতদূর সরেছে তা মিলিয়ে হিসাব করে।
Total Blocking Time (TBT)
200 ms-এর কম হলে ভালো, 600 ms-এর বেশি হলে খারাপ। TBT বেশি হলে ধরে নেওয়া যায় যে আসল ব্যবহারকারীদের ট্যাপে পেজ ধীরে সাড়া দেবে।
বাইট ও রিকোয়েস্ট
কোনো আনুষ্ঠানিক সীমা নেই; দেখুন কোন ধরন প্রাধান্য পাচ্ছে। সাধারণত ছবিই সবচেয়ে বড় অংশ, আর থার্ড পার্টির অংশ বেশি হলে তা অ্যাপ, ট্যাগ ও উইজেটের দিকে ইঙ্গিত করে।
ভারী ছবি
150 KB-এর বেশি প্রতিটি ছবি, বা যেসব ছবি দেখানোর চেয়ে অনেক বেশি চওড়া অবস্থায় ডাউনলোড হয়, তাদের ফাইলের আকার ও মাপসহ।
রেন্ডার-ব্লকিং ফাইল
CSS ও সিঙ্ক্রোনাস স্ক্রিপ্ট, যা কিছু দেখানোর আগে ব্রাউজারকে ডাউনলোড করতেই হয়।
ফিল্ড ডেটা (75তম পার্সেন্টাইল)
শেষ 28 দিনে ফোনে আসল Chrome ব্যবহারকারীদের অভিজ্ঞতা। 75তম পার্সেন্টাইল মানে প্রতি চারটি পেজ লোডের তিনটি অন্তত এতটা দ্রুত ছিল। INP 200 ms-এর কম হলে ভালো এবং 500 ms-এর বেশি হলে খারাপ।
কোনো ফিল্ড ডেটা নেই
আপনার অরিজিনের জন্য Google-এর কাছে যথেষ্ট Chrome ট্রাফিক নেই। এটি আপনার স্পিড সম্পর্কে কিছুই বলে না; ল্যাবের ফলাফলের ওপর নির্ভর করুন।

সবচেয়ে সাধারণ সমস্যাগুলো কীভাবে ঠিক করবেন

  • ধীর LCP ছবি

    হিরো ছবিটি যে আকারে দেখানো হয় সেই আকারে দিন, srcset ব্যবহার করে, WebP বা AVIF ফরম্যাটে। এটিকে lazy-load করবেন না, fetchpriority="high" যোগ করুন, এবং স্ক্রিপ্ট বা CSS ব্যাকগ্রাউন্ড থেকে লোড না করে HTML-এ img এলিমেন্ট হিসেবে রাখুন।

  • লোড হওয়ার সময় লাফিয়ে ওঠা কনটেন্ট

    ছবি, ভিডিও ও এমবেডকে width ও height অ্যাট্রিবিউট বা CSS aspect-ratio দিন। ব্যানার, কুকি নোটিশ ও বিজ্ঞাপনের জন্য জায়গা সংরক্ষণ করুন, অথবা সেগুলো এমন ওভারলে হিসেবে দেখান যা কনটেন্টকে নিচে ঠেলে দেয় না। ওয়েব ফন্টের জন্য font-display: optional ব্যবহার করুন, অথবা মাপ মিলিয়ে নেওয়া একটি ফলব্যাক ফন্ট।

  • বেশি Total Blocking Time

    আগে সেইসব অ্যাপ, ট্যাগ ও প্লাগইন সরান যা আপনি আর ব্যবহার করেন না; ব্যবহার বন্ধ করার পরও প্রায়ই সেগুলোর স্ক্রিপ্ট থেকে যায়। চ্যাট, রিভিউ ও অ্যানালিটিক্স defer দিয়ে বা পেজ ইন্টারঅ্যাক্টিভ হওয়ার পর লোড করুন। Shopify-তে Online Store › Themes › Customize › App embeds দেখুন।

  • রেন্ডার-ব্লকিং CSS ও স্ক্রিপ্ট

    প্রথম পেইন্টের আগে চলার দরকার নেই এমন স্ক্রিপ্টে defer যোগ করুন, প্রথম স্ক্রিনের জন্য প্রয়োজনীয় অল্প CSS ইনলাইন করুন, এবং পেজ ব্যবহার করে না এমন ফিচারের স্টাইলশিট বাদ দিন।

  • অতিরিক্ত ভারী ছবি

    আপলোডের আগে ছবির আকার কমান (পূর্ণ-প্রস্থের ব্যানারের জন্য প্রায় 2000 px চওড়াই যথেষ্ট) এবং সেগুলো কমপ্রেস করুন। থিম চাইলে Shopify ও WordPress স্বয়ংক্রিয়ভাবে ছোট সংস্করণ দিতে পারে, তাই দেখুন আপনার থিম রেসপন্সিভ ইমেজ সাইজ ব্যবহার করে কি না।

এই টুল নিয়ে প্রশ্ন

আমার ফলাফল PageSpeed Insights থেকে আলাদা কেন?

ল্যাব পরীক্ষা নির্ভর করে মেশিন, নেটওয়ার্ক ও মুহূর্তের ওপর। PageSpeed Insights Google-এর সার্ভারে Lighthouse চালায় এবং ধীর সংযোগ সিমুলেট করে, আর আমরা একটি আসল ব্রাউজারে থ্রটলিং প্রয়োগ করি। হুবহু এক সংখ্যা নয়, কাছাকাছি পরিসর আশা করুন।

ভালো LCP কত?

web.dev অনুযায়ী, অন্তত 75% পেজ লোডে 2.5 সেকেন্ড বা তার কম। 4 সেকেন্ডের বেশি হলে খারাপ।

আমার সাইটের জন্য রিয়েল-ইউজার ডেটা নেই কেন?

Chrome UX Report-এ কেবল সেইসব অরিজিন থাকে, যেগুলো পাবলিকভাবে খুঁজে পাওয়া যায় এবং ব্যবহারের পরিসংখ্যান শেয়ার করা Chrome ব্যবহারকারীদের কাছ থেকে যথেষ্ট ভিজিট পায়। অনেক ছোট সাইট সেই পর্যায়ে পৌঁছায় না; তবুও ল্যাব পরীক্ষা দেখায় কী ঠিক করতে হবে।

ডেস্কটপের বদলে ধীর ফোনে পরীক্ষা কেন?

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

First Input Delay-এর কী হলো?

2024 সালের মার্চে Interaction to Next Paint (INP) Core Web Vital হিসেবে First Input Delay-এর জায়গা নিয়েছে। INP শুধু প্রথমটি নয়, পুরো ভিজিট জুড়ে ইন্টারঅ্যাকশনের দেরি বিবেচনা করে।

সূত্র

সংশ্লিষ্ট টুল

পারফরম্যান্স সংশোধন রিপোর্ট ($55, এককালীন) পুরো ফ্রি স্ক্যান থেকে শুরু করে এবং যোগ করে আরও পেজ, প্রতিটি সমস্যার জন্য করণীয় পরিবর্তন, একটি PDF এবং আপনার সংশোধন যাচাইয়ের জন্য রি-টেস্ট।

পারফরম্যান্স সংশোধন রিপোর্ট সম্পর্কে