গুগল পেজস্পিড ইনসাইটস কী? ওয়েবসাইটের স্পিড পরীক্ষা ও উন্নত করার নিয়ম

Website slow মনে হলে অনেকেই একটি test চালিয়ে score দেখে সিদ্ধান্ত নেন—সবুজ হলে ভালো, লাল হলে hosting খারাপ। বাস্তবে বিষয়টি এত সরল নয়। Google PageSpeed Insights বা PSI একটি web page-এর mobile ও desktop performance বিশ্লেষণ করে, real-user data পাওয়া গেলে তা দেখায় এবং Lighthouse-এর controlled lab test থেকে উন্নতির clue দেয়। এটি সমস্যা শনাক্ত করার শক্তিশালী সূচনা, কিন্তু একটি score website-এর সব visitor, সব page বা business outcome-এর সম্পূর্ণ ছবি নয়।

PSI report-এ Field Data ও Lab Data, Core Web Vitals assessment, performance score এবং নানা audit দেখা যায়। নতুন site বা কম traffic page-এ field data নাও থাকতে পারে; lab result প্রতিবার network ও test condition-এ কিছুটা বদলাতে পারে। তাই কোন data কী বোঝায়, LCP/INP/CLS কেন গুরুত্বপূর্ণ এবং “Reduce unused JavaScript” বা “Properly size images” ধরনের পরামর্শ বাস্তবে কীভাবে কাজে লাগাতে হয় তা জানা জরুরি।

এই বাংলা গাইডে URL test থেকে শুরু করে report পড়া, bottleneck priority, WordPress optimization, before-after verification এবং common misconception সব দেখানো হয়েছে। কোনো cache, minify, database বা code change-এর আগে verified backup নিন এবং staging-এ পরীক্ষা করুন। PSI recommendation কপি করে production-এ অন্ধভাবে প্রয়োগ করবেন না; site-এর design, accessibility, analytics, consent, checkout ও নিরাপত্তা অক্ষত রাখা সমান গুরুত্বপূর্ণ।

এই গাইডে যা জানবেন

• Google PageSpeed Insights কী এবং এটি কী কাজ করে?
• PageSpeed Insights দিয়ে speed test করার ধাপ
• Field Data ও Lab Data-এর পার্থক্য
• LCP, INP ও CLS: Core Web Vitals বুঝুন
• Performance score ও অন্যান্য Lab Metric কী বোঝায়?
• Opportunities ও Diagnostics পড়ার সঠিক নিয়ম
• সাধারণ PSI recommendation থেকে বাস্তব action
• WordPress site-এর PSI score ও বাস্তব speed উন্নত করার ধাপ
• Report থেকে ৩০ দিনের improvement workflow
• PageSpeed Insights ব্যবহারের সীমাবদ্ধতা ও সাধারণ ভুল
• একটি বাস্তব priority উদাহরণ

Google PageSpeed Insights কী এবং এটি কী কাজ করে?

PageSpeed Insights একটি নির্দিষ্ট public URL analyze করে mobile ও desktop tab-এ ফল দেখায়। Report-এর উপরে real users-এর experience section থাকতে পারে, যার উৎস Chrome User Experience Report বা CrUX। নিচে Lighthouse controlled environment-এ page load করে performance diagnostics তৈরি করে। তাই PSI একই report-এ “বাস্তবে গত সময়ে কী ঘটেছে” এবং “বর্তমান lab run-এ কী bottleneck দেখা গেল”—দুটি আলাদা lens দেয়।

Toolটি hosting benchmark মাত্র নয়। Server response-এর পাশাপাশি image, CSS, JavaScript, font, third-party code, layout shift ও main-thread work বিশ্লেষণ করে। একটি external chat widget score কমাতে পারে; আবার fast front end-এর origin response slow হতে পারে। Report developer ও non-technical owner-এর মধ্যে common language তৈরি করে, কিন্তু root cause নিশ্চিত করতে browser DevTools, server log, analytics বা real-user monitoring লাগতে পারে।

PSI একটি URL test করে, পুরো site স্বয়ংক্রিয়ভাবে নয়। Homepage ভালো হলেও article template, product page বা checkout ধীর হতে পারে। একই template-এর representative URL, highest-traffic landing page এবং revenue-critical flow আলাদা পরীক্ষা করুন। Private dashboard বা login-dependent page public PSI থেকে পুরোপুরি test নাও হতে পারে; সেগুলোর জন্য Lighthouse local run বা authenticated monitoring প্রয়োজন।

PageSpeed Insights দিয়ে speed test করার ধাপ

1. Browser-এ official PageSpeed Insights page খুলুন।
2. সম্পূর্ণ canonical URL, যেমন https://example.com/page/, দিন।
3. Analyze চাপুন এবং report সম্পূর্ণ হওয়া পর্যন্ত অপেক্ষা করুন।
4. প্রথমে Mobile tab, তারপর Desktop tab দেখুন।
5. Field data আছে কি না এবং Core Web Vitals assessment পড়ুন।
6. Performance score-এর নিচে metric ও audit expand করুন।
7. Report URL/save date নোট করে baseline রাখুন।

একবারের result-এ সিদ্ধান্ত নেবেন না। একই URL কয়েকবার test করে median বা consistent bottleneck দেখুন। Cache warm/cold, server load এবং third-party response-এ lab score বদলায়। পরিবর্তনের আগে ও পরে একই URL, একই device tab এবং কাছাকাছি সময়ে test করলে তুলনা অর্থপূর্ণ হয়। Test চলাকালে বড় campaign traffic বা deployment থাকলে note করুন।

URL redirect হলে PSI final URL দেখাতে পারে। http, www/non-www, tracking parameter বা language path দিয়ে আলাদা test করলে redirect cost ও cache variation ধরা যায়। তবে duplicate report দেখে বিভ্রান্ত না হয়ে canonical destination-কে baseline করুন। robots/firewall automated test block করলে report fail হতে পারে; security পুরো বন্ধ না করে verified PSI/Lighthouse request ও provider guidance অনুযায়ী troubleshoot করুন।

Field Data ও Lab Data-এর পার্থক্য

Field section page-level data না পেলে origin-level data দেখাতে পারে—অর্থাৎ একই domain-এর একাধিক page-এর aggregate। Label দেখে বুঝুন আপনি নির্দিষ্ট URL নাকি পুরো origin দেখছেন। নতুন page, private URL বা কম sample-এ “No Data” মানে page fast বা slow—কোনোটিই প্রমাণ নয়। তখন lab, analytics ও নিজের real-user monitoring ব্যবহার করুন।

Fix deploy করার পর lab score সঙ্গে সঙ্গে বদলাতে পারে, কিন্তু field data ২৮ দিনের rolling window হওয়ায় পুরোনো experience ধীরে বের হয়। তাই আজ image optimize করে কাল field assessment না বদলালে fix ব্যর্থ ভাববেন না। Deployment date annotation রাখুন এবং পরবর্তী সপ্তাহগুলো trend দেখুন। বিপরীতে lab green কিন্তু field poor হলে real devices, geography, consented users বা production traffic-এর difference খুঁজুন।

LCP, INP ও CLS: Core Web Vitals বুঝুন

Largest Contentful Paint (LCP) viewport-এর প্রধান বড় content কত দ্রুত render হয়েছে তার signal। ভালো field threshold সাধারণত ২.৫ সেকেন্ড বা কম। Slow server, render-blocking CSS, late-discovered hero image, large file এবং client-side rendering LCP খারাপ করতে পারে। Report-এ LCP element দেখলে সেটি image, heading বা container কোনটি বুঝে delivery path অনুসরণ করুন।

Interaction to Next Paint (INP) user interaction-এর responsiveness দেখে; ভালো threshold ২০০ millisecond বা কম। Heavy JavaScript, long task, expensive event handler বা বড় DOM interaction-এর পর visual update দেরি করাতে পারে। Lab run-এ real user interaction না থাকায় INP সরাসরি না-ও পাওয়া যায়; Total Blocking Time debugging proxy হিসেবে clue দেয়, কিন্তু INP-এর সমান নয়।

Cumulative Layout Shift (CLS) unexpected visual movement মাপে; ভালো threshold ০.১ বা কম। Dimension ছাড়া image/ad, late banner, injected content ও font swap সাধারণ কারণ। Field assessment 75th percentile-এ metric দেখে, অর্থাৎ অধিকাংশ user-এর ভালো experience লক্ষ্য। তিন metric-এর একটি poor হলে overall Core Web Vitals assessment pass নাও করতে পারে। Threshold guide হলেও accessibility ও task success-কে বাদ দেবেন না।

Performance score ও অন্যান্য Lab Metric কী বোঝায়?

Lighthouse performance score একাধিক weighted metric থেকে তৈরি এবং ০–১০০ scale-এ দেখানো হয়। সাধারণভাবে ৯০–১০০ good, ৫০–৮৯ needs improvement, ০–৪৯ poor রঙে দেখা যায়। কিন্তু score একটি simulated run-এর summary; 89 থেকে 91 যাওয়া business success নয়। Metric ও waterfall না দেখে শুধু circle-এর রঙ optimize করলে ছোট scoring opportunity-তে সময় নষ্ট হতে পারে।

First Contentful Paint প্রথম text/image paint-এর ইঙ্গিত, Speed Index visual content কত দ্রুত ভরেছে দেখায়, Total Blocking Time lab-এর long main-thread task বোঝাতে সাহায্য করে। LCP ও CLS lab-এও থাকে। Metric expand করলে element বা phase breakdown পাওয়া যেতে পারে। Server wait বেশি হলে image compression একা যথেষ্ট নয়; TBT বেশি হলে JavaScript execution দেখুন।

Mobile score desktop-এর চেয়ে কম হওয়া অস্বাভাবিক নয়, কারণ simulated device/network আলাদা এবং mobile CPU সীমিত। বাস্তব audience যদি mobile-heavy হয়, mobile report priority দিন; তবু desktop business users উপেক্ষা করবেন না। Score fluctuation কমাতে একাধিক run, median এবং consistent audit ব্যবহার করুন। Lighthouse version বদলালে weighting/auditও বদলাতে পারে, তাই মাসের ব্যবধানে raw score তুলনায় version/context লিখুন।

Opportunities ও Diagnostics পড়ার সঠিক নিয়ম

Audit title যেমন “Eliminate render-blocking resources”, “Reduce unused JavaScript”, “Properly size images” বা “Avoid enormous network payloads” সম্ভাব্য bottleneck বোঝায়। Estimated savings lab model-এর অনুমান; সব savings যোগ করলে final load time সরাসরি সেই পরিমাণ কমবে না, কারণ request parallel এবং dependency overlap করে। Audit expand করে কোন URL, transfer size ও execution time জড়িত দেখুন।

প্রথমে failed Core Web Vital-এর সঙ্গে যুক্ত resource বেছে নিন। LCP poor এবং hero image বিশাল হলে resize/format/priority high impact। TBT বেশি ও third-party bundle heavy হলে script audit। CLS বেশি হলে missing dimension বা dynamic slot। “Minify CSS” কয়েক kilobyte বাঁচালেও ২ MB hero-এর আগে সেটি low priority হতে পারে। Effort বনাম impact matrix বানান।

Passed audit উপকারী হলেও perfection guarantee নয়। “Not applicable” মানে সেই run-এ audit প্রযোজ্য নয়। Accessibility, Best Practices ও SEO category performance-এর বাইরে আরও issue দেখায়; এগুলোও review করুন, কিন্তু automated audit মানুষের full accessibility/security review নয়। Red item fix করতে গিয়ে green item ভাঙছে কি না regression test করুন।

সাধারণ PSI recommendation থেকে বাস্তব action

Action নেওয়ার আগে resource first-party না third-party এবং page-এর কোন function চালায় বুঝুন। Unused JavaScript report করা script checkout fraud detection বা consent-এর জন্য দেরিতে দরকার হতে পারে। Remove নয়, route-specific loading বা lightweight alternative বিবেচনা করুন। Delay করলে user interaction-এর মুহূর্তে large download শুরু হয়ে INP খারাপ হতে পারে; বাস্তবে tap test করুন।

Image optimization-এ visual quality ও accessibility বজায় রাখুন। CSS critical extraction automation বিভিন্ন template-এ test করুন। Font preload শুধু above-the-fold প্রয়োজনীয় file-এ দিন। Server response slow হলে application cache, database query, external API এবং hosting resource আলাদা মাপুন। একটি generic cache plugin underlying timeout ঢাকতে পারে; logged-in/checkout uncached path পরীক্ষা করুন।

WordPress site-এর PSI score ও বাস্তব speed উন্নত করার ধাপ

প্রথমে theme ও plugin inventory করুন। Plugin count নয়, কোনটি কত query, asset ও external call যোগ করছে তা গুরুত্বপূর্ণ। Staging-এ সন্দেহভাজন plugin disable করে report ও function compare করুন। Page cache, browser cache এবং compatible object cache ব্যবহার করুন। Hosting-level cache থাকলে duplicate plugin configuration এড়িয়ে provider guide অনুসরণ করুন। Login, cart ও checkout exclusion test করুন।

Media library-তে oversized image চিহ্নিত করে backup নিয়ে regenerate/replace করুন। Future upload-এর dimension guideline তৈরি করুন। Hero image eager/priority, নিচের gallery lazy; iframe facade ব্যবহার করা যায়। Theme-এর unused font/weight, icon library ও page-builder widget কমান। CSS/JS minify ও delay option একবারে একটি চালিয়ে mobile menu, form, cookie consent, search ও payment test করুন।

Database revision/transient পরিষ্কার করার আগে full backup নিন। Autoload data ও slow query profile করুন; generic cleanup দিয়ে unknown table delete করবেন না। Cron backlog, external API ও admin-ajax request দেখুন। WordPress-এর পূর্ণ checklist পেতে WordPress Speed Optimization-এর ১৫টি উপায় পড়ুন। Server resource bottleneck হলে উপযুক্ত hosting নির্বাচনের গাইড দেখুন।

Report থেকে ৩০ দিনের improvement workflow

দিন ১–৩: পাঁচটি representative URL-এর mobile/desktop baseline, field status, lab median ও business metric নিন। দিন ৪–৭: oversized image, broken asset, redirect chain, cache এবং obvious third-party quick win ঠিক করুন। প্রতিটি change staging-এ test ও deployment annotation দিন।

সপ্তাহ ২: LCP path ও server response optimize করুন—hosting resource, full-page cache, hero delivery, critical CSS/font। সপ্তাহ ৩: INP/TBT-এর জন্য JavaScript long task, widget, tag manager ও interaction test। CLS-এর জন্য media/ad dimension, dynamic banner ও font fallback ঠিক করুন। একই sprint-এ unrelated redesign না করলে ফল বোঝা সহজ।

সপ্তাহ ৪: regression test, accessibility, form/checkout, analytics ও security যাচাই করুন। Lab rerun-এর পাশাপাশি own monitoring এবং available field trend দেখুন। Improvement document করুন এবং performance budget—image size, script weight, font count—content/development team-কে দিন। Field data rolling হওয়ায় আরও কয়েক সপ্তাহ monitor করুন; নতুন deployment-এর প্রভাব আলাদা note করুন।

PageSpeed Insights ব্যবহারের সীমাবদ্ধতা ও সাধারণ ভুল

প্রথম ভুল এক run-এর score client বা developer-এর quality verdict হিসেবে ব্যবহার করা। PSI একটি diagnostic sample; architecture, security, maintainability বা conversion পুরোপুরি মাপে না। দ্বিতীয় ভুল homepage-কে পুরো site ধরা। তৃতীয় ভুল lab “estimated savings” যোগ করে guaranteed time saving বলা। চতুর্থ ভুল field data না থাকাকে pass মনে করা।

VPN, firewall, geolocation, consent state ও third-party A/B test PSI bot/run-কে visitor থেকে ভিন্ন content দিতে পারে। Personalized dashboard public tool-এ test করা যায় না। Service worker/cache কখনো result বদলায়। তাই Chrome DevTools, WebPageTest ধরনের waterfall, server APM, Search Console Core Web Vitals, analytics ও real user monitoring সঙ্গে ব্যবহার করুন। Tool disagreement হলে test condition তুলনা করুন।

সবচেয়ে ক্ষতিকর ভুল score বাড়াতে feature ভাঙা। “Delay all JS” করে menu/checkout বন্ধ, image quality নষ্ট, font accessibility খারাপ বা consent script বাদ দেওয়া গ্রহণযোগ্য নয়। Backup, staging, visual regression, keyboard/mobile test এবং real transaction check বাধ্যতামূলক করুন। Optimization-এর শেষে cache purge করে anonymous ও logged-in দুই state দেখুন।

একটি বাস্তব priority উদাহরণ

ধরা যাক mobile PSI-তে LCP ৪.৮ সেকেন্ড, CLS ০.০৫ এবং TBT মাঝারি। Audit দেখাল hero image ১.৯ MB, image lazy-loaded এবং server response ১.২ সেকেন্ড। এখানে প্রথমে hero resize/compress, responsive source ও lazy-load exclusion; তারপর page cache/server profiling। CLS ইতিমধ্যে ভালো, তাই layout নিয়ে unnecessary কাজের priority কম।

পরের run-এ LCP ২.৯ সেকেন্ড, কিন্তু chat widget interaction-এ delay। এখন field INP ও DevTools long task দেখুন। Widget revenue/support value থাকলে সরাসরি remove নয়; click-to-load, lighter version বা selected page-এ load পরীক্ষা করুন। Before/after support conversion ও user complaint তুলনা করুন।

এই example দেখায় score নয়, bottleneck sequence গুরুত্বপূর্ণ। একটি বড় fix ছোট দশটি minification-এর চেয়ে বেশি ফল দেয়। একই approach generic site-এ প্রয়োগের জন্য WordPress performance guide এবং network locality বুঝতে BDIX বনাম International Hosting তুলনা ব্যবহার করতে পারেন।

কাজ শুরুর আগে সংক্ষিপ্ত চেকলিস্ট

• Official PSI-তে canonical URL mobile ও desktop উভয় tab-এ কয়েকবার test করা হয়েছে।
• Field Data page-level নাকি origin-level এবং sample আছে কি না বোঝা হয়েছে।
• Score-এর বদলে failed LCP, INP, CLS ও বড় lab bottleneck অগ্রাধিকার পেয়েছে।
• প্রতিটি audit-এর resource, owner ও business function বুঝে action নেওয়া হচ্ছে।
• Change-এর আগে backup এবং staging functional/visual test সম্পন্ন হয়েছে।
• Before/after একই condition-এ মাপা ও deployment date নথিভুক্ত হয়েছে।
• Lab improvement-এর পরে rolling field trend ও business KPI পর্যবেক্ষণ চলছে।

সম্পর্কিত আরও গাইড

PSI report হাতে নিয়ে কাজ শুরু করতে WordPress speed বাড়ানোর ১৫টি উপায় অনুসরণ করুন। Server response বারবার ধীর হলে বাংলাদেশে সেরা hosting বাছাই এবং management feature বুঝতে WordPress control panel তুলনা দেখুন।

সাধারণ প্রশ্ন ও উত্তর

Google PageSpeed Insights score কত হলে ভালো?

Lighthouse-এ ৯০–১০০ সাধারণত good রঙে দেখায়, কিন্তু একক score চূড়ান্ত লক্ষ্য নয়। Field Core Web Vitals, critical page function, accessibility এবং business metric সঙ্গে দেখুন।

Mobile score desktop-এর চেয়ে কম কেন?

PSI mobile test তুলনামূলক সীমিত device/network simulate করে এবং mobile CPU heavy JavaScript-এ বেশি সময় নেয়। এটি common; mobile audience বেশি হলে bottleneck priority দিন।

Field Data নেই কেন?

URL নতুন, private বা পর্যাপ্ত eligible Chrome sample না থাকলে CrUX page/origin data দেখাতে পারে না। এটি ভালো বা খারাপ performance-এর verdict নয়; lab এবং নিজের real-user data ব্যবহার করুন।

Fix করার পর Field Data সঙ্গে সঙ্গে বদলায় না কেন?

Field report rolling 28-day window-এর aggregated experience। পুরোনো sample ধীরে সরে যায়, তাই lab change দ্রুত দেখা গেলেও field trend বদলাতে সময় লাগে।

PageSpeed score কি Google ranking ঠিক করে?

Page experience signal গুরুত্বপূর্ণ হতে পারে, কিন্তু relevance, helpful content এবং বহু signal-এর মধ্যে এটি একটি অংশ। শুধু score 100 করলেই ranking নিশ্চিত নয়। বাস্তব ব্যবহারকারীর অভিজ্ঞতা উন্নত করুন।

PSI-এর সব recommendation কি প্রয়োগ করা উচিত?

না। Impact, effort, compatibility ও business function দেখে priority দিন। Estimated savings clue; production change-এর আগে staging, backup এবং functional regression test জরুরি।

শেষ কথা

Google PageSpeed Insights সঠিকভাবে ব্যবহার করলে “site slow” অভিযোগকে measurable problem-এ রূপ দেওয়া যায়। Field Data বাস্তব trend, Lab Data debugging clue; LCP, INP ও CLS user experience-এর প্রধান signal। Score নিয়ে আতঙ্কিত না হয়ে representative URL মাপুন, বড় bottleneck আগে ঠিক করুন, একটি করে change verify করুন এবং rolling field trend পর্যবেক্ষণ করুন। Tool-এর পরামর্শের সঙ্গে মানুষের task, accessibility, security ও business result মিললেই optimization সত্যিকারের সফল।

PageSpeed Insights, Lighthouse, CrUX metric, scoring weight ও interface সময়ের সঙ্গে পরিবর্তিত হতে পারে। Threshold বা recommendation প্রয়োগের আগে Google-এর বর্তমান official PageSpeed Insights ও Web Vitals documentation যাচাই করুন।