প্রথমে সিদ্ধান্ত নির্ধারণ করুন, তারপর টুল নির্বাচন করুন
কোন পেজ, কোন দর্শক এবং কোন ঝুঁকিপূর্ণ কাজ আছে তা নামকরণ করে নিন—যেমন মোবাইল প্রোডাক্ট পেজ, চেকআউট বা লিড ফর্ম—তারপর কিছু চালান। তারপর প্রমাণের ধরন নির্বাচন করুন। ল্যাব ডেটা হচ্ছে পুনরাবৃত্তি যোগ্য ডিবাগিংয়ের জন্য নিয়ন্ত্রিত টেস্ট। ফিল্ড ডেটা হচ্ছে গ্রুপকৃত বাস্তব-ব্যবহারকারী অভিজ্ঞতা যা অগ্রাধিকার নির্ধারণে সাহায্য করে। একটি ব্রাউজার ট্রেস লোকাল রানটাইম কাজ ব্যাখ্যা করতে সহায়ক। এগুলো পরস্পর পরিপূরক; বিনিমেয় নয়।
কোন স্কোর অর্জন করবেন তার বদলে জিজ্ঞেস করুন কী বাধা দেয় যে একজন ভিজিটর একটি গুরুত্বপূর্ণ কাজ সম্পন্ন করতে পারছে না।
অধিক পণ্য যোগ করার আগে একটি অডিট, প্রাপ্য ফিল্ড ডেটা, এবং একটি ডায়াগনসিস টুল ব্যবহার করুন।
একটি ফলাফল প্রযোজ্য হবে টেস্ট করা URL, শর্ত বা স্যাম্পলের জন্য; এটি প্রতিটি ভিজিটারের ওপর একটি সর্বসম্মত রায় নয়।
পেজ-লোড অডিটের জন্য Lighthouse এবং PageSpeed Insights ব্যবহার করুন
Lighthouse একটি ওপেন-সোর্স স্বয়ংক্রিয় অডিট যা Chrome DevTools এ, কমান্ড লাইন থেকে, বা কন্টিনিউস ইন্টিগ্রেশনে চালানো যায়। এটি পারফরম্যান্স, অ্যাক্সেসিবিলিটি, SEO এবং আরও অনেককিছু অডিট করে। PageSpeed Insights একটি URL-এর জন্য Lighthouse ডায়াগনস্টিকস চালায় এবং উপলব্ধ থাকলে বাস্তব-ব্যবহারকারীর ডেটা প্রদর্শন করে। একটি প্রতিনিধিত্বশীল পেজে বেসলাইন নিতে, ব্যর্থ অডিট তদন্ত করতে এবং নির্ধারিত পরিবর্তনের পরে নিয়ন্ত্রিত রিটেস্ট তুলনা করতে এগুলো ব্যবহার করুন।
টেস্ট সেটআপে অডিট করা পেজটি কীভাবে আচরণ করেছে এবং কোন অডিটগুলো তদন্তের যোগ্য।
একটি ভালো Lighthouse স্কোর অবশ্যই বাস্তব-ব্যবহারকারীর অভিজ্ঞতা ভালো হবে তা নিশ্চিত করে না; Google সংরক্ষণ করেছে যে ল্যাব এবং ফিল্ড ফলাফল আলাদা হতে পারে।
পরিবর্তনের পরে একই পেজ ও সেটিংস দিয়ে পুনরায় পরীক্ষা করুন; এককালীন গেট হিসেবে ব্যবহার করবেন না।
ফিল্ড ডেটা ব্যবহার করে ব্যবহারকারীদের প্রকৃত অভিজ্ঞতার অগ্রাধিকার নির্ধারণ করুন
PageSpeed Insights-এর ফিল্ড ডেটা Chrome User Experience Report (CrUX) থেকে আসে এবং একটি গত 28‑দিনের সময়কাল কভার করে। এটি Largest Contentful Paint (LCP), Interaction to Next Paint (INP), এবং Cumulative Layout Shift (CLS) সহ মেট্রিক রিপোর্ট করে। যখন আপনাকে একটির বদলে পেজগুলোর গ্রুপ দেখা দরকার, তখন Search Console‑এর Core Web Vitals রিপোর্টিং সাহায্য করে। কোন টেমপ্লেট, ডিভাইস গ্রুপ বা সমস্যা আগে সমাধান করবেন তা নির্ধারণ করতে ফিল্ড ডেটা ব্যবহার করুন।
চেক করুন ফলাফলটি পেজ-লেভেল নাকি অরিজিন-লেভেল এবং URL‑টিতে পর্যাপ্ত ডেটা ছিল কিনা।
ফিল্ড ডেটা ঐতিহাসিক এবং প্রাইভেসি-এগ্রিগেটেড, তাই এটি রিলিজের প্রভাব তৎক্ষণাৎ নিশ্চিত করতে পারবে না।
Google LCP 2.5 সেকেন্ডের মধ্যে, INP 200 মিলিসেকেন্ডের নিচে, এবং CLS 0.1 এর নিচে থাকা সুপারিশ করে।
অডিট যদি ব্যাখ্যার দাবি করে তবে Chrome DevTools ব্যবহার করুন
যখন একটি অডিট বা ফিল্ড প্যাটার্ন ধীর লোডিং, ডিলে হওয়া ইন্টারঅ্যাকশন বা ভিজ্যুয়াল মুভমেন্ট নির্দেশ করে, তখন Chrome DevTools Performance তে যাত্রাটি রেকর্ড করুন। এটি CPU প্রোফাইল রেকর্ড করে এবং লোকাল LCP, CLS, এবং ইন্টারঅ্যাকশনের পরে INP দেখাতে পারে। এর টাইমলাইন ডেভেলপারকে সুপারিশ-তালিকার থেকে অনুমান করার পরিবর্তে ব্রাউজার কাজ তদন্তে সহায়তা করে।
এমন ভিউপোর্ট, CPU এবং নেটওয়ার্ক কন্ডিশন ব্যবহার করুন যা প্রভাবিত দর্শকদের সাথে যৌক্তিকভাবে মিল রেখে।
একটি ট্রেস যেই ডিভাইস, কানেকশন, ক্যাশ স্টেট এবং রেকর্ড করা যাত্রাকে প্রতিফলিত করে। সাধারণীকরণের আগে প্রাসঙ্গিক যাত্রাগুলো পুনরুৎপাদন করুন।
শরমসঙ্কেত কারণ, পরিবর্তন এবং প্রত্যাশিত ভিজিটর প্রভাব রেকর্ড করুন।
স্বয়ংক্রিয় অ্যাক্সেসিবিলিটি চেককে জ্ঞানসম্পন্ন মানব মূল্যায়নের সঙ্গে মিলান
মেশিন-টেস্টেবল সমস্যা দ্রুত এবং বারংবার ধরার জন্য একটি অ্যাক্সেসিবিলিটি মূল্যায়ন টুল ব্যবহার করুন। W3C WAI একটি টুল তালিকা ও নির্বাচনের নির্দেশিকা বজায় রাখে, কিন্তু বলে কোনো একক টুল একা করে নির্ধারণ করতে পারে না যে সাইটটি অ্যাক্সেসিবিলিটি স্ট্যান্ডার্ড পূরণ করে কি না। স্বয়ংক্রিয় আবিষ্কারগুলো ব্যবহার করে একটি রিভিউ কিউ তৈরি করুন, তারপর প্রতিনিধিত্বশীল পেজ, কিবোর্ড অপারেশন, ফোকাস আচরণ, এরর হ্যান্ডলিং এবং কনটেন্ট যোগ্য রিভিউয়াদের সঙ্গে পরিদর্শন করুন।
দ্রুত আবিষ্কার এবং পুনরাবৃত্তি যোগ্য ডিফেক্ট প্রতিরোধ।
পূর্ণ অ্যাক্সেসিবিলিটি সম্মতি নির্ধারণ বা মানব মূল্যায়নের বিকল্প হতে পারে না।
একটি স্বয়ংক্রিয় ফলাফলকে আইনি সম্মতিরূপে মার্কেট করবেন না; যেখানে গুরুত্বপূর্ণ সেখানে যোগ্য অ্যাক্সেসিবিলিটি ও আইনি পর্যালোচনা গ্রহণ করুন।
কেন্দ্রীভূত সিকিউরিটি টুল সাবধানে এবং অনুমোদনের মধ্যে ব্যবহার করুন
Mozilla‑এর HTTP Observatory HTTP হেডার এবং অন্যান্য মূল সিকিউরিটি কনফিগারেশন পরীক্ষা করে এবং পাবলিক-ফেসিং হেডার হাইজিনের জন্য প্রশাসকদের একটি শুরু পয়েন্ট দেয়। প্রস্তাবিত হেডার পরিবর্তনগুলো প্রোডাকশনের বাইরে যাচাই করুন কারণ নীতিগুলি স্ক্রিপ্ট, এমবেডেড সার্ভিস এবং ইউজার ফ্লোকে প্রভাবিত করতে পারে। এটি সিকিউরিটির একটি অংশ বিশ্লেষণ করে, প্রতিটি অ্যাপ্লিকেশন ঝুঁকি নয়।
OWASP ZAP প্যাসিভভাবে ট্র্যাফিক স্ক্যান এবং অ্যাকটিভভাবে অ্যাপ্লিকেশন টেস্ট করতে পারে, কিন্তু শুধুমাত্র সেই সিস্টেমগুলো পরীক্ষা করুন যেগুলো আপনি অনুমোদিত।
ZAP বলে এক্টিভ স্ক্যানিং একটি বাস্তব আক্রমণ যা টার্গেটকে ঝুঁকিতে ফেলতে পারে। প্যাসিভ স্ক্যানিং অথেন্টিকেটেড বা অনাবিক্ষৃত এরিয়া মিস করতে পারে।
পেমেন্ট, অথেনটিকেশন, সংবেদনশীল ডেটা বা গুরুত্বপূর্ণ ফলাফলের জন্য যোগ্য সিকিউরিটি পেশাদারদের জড়িত করুন।
টুল আউটপুটকে SIU প্রতিকার হিসেবে পরিণত করুন, স্কোর-চেসিং হিসেবে নয়
একটি টেকসই লুপ ব্যবহার করুন: একটি বেসলাইন ক্যাপচার করুন, একটি সম্ভাব্য কারণ শনাক্ত করুন, সবচেয়ে ছোট নিরাপদ পরিবর্তন করুন, একই পথ পুনরায় পরীক্ষা করুন, এবং পর্যাপ্ত সময় পরে ফিল্ড ট্রেন্ড পর্যবেক্ষণ করুন। ভিজিটরের কাজকে কেন্দ্রে রাখুন। একটি ব্লকিং অ্যাসেট কমানো তখনই মূল্যবান যদি এটি উপযোগী অভিজ্ঞতা উন্নত করে এবং কিনতে, সাইন-ইন, অ্যাক্সেসিবিলিটি, কনসেন্ট বা অ্যানালিটিক্স আচরণ ভাঙে না।
ফিল্ড ইমপ্যাক্ট, পুনরুৎপাদনযোগ্য ট্রেস, বা স্পষ্ট ব্যবহারকারী-সামনে ত্রুটির দ্বারা সমর্থিত পরিবর্তনকে পছন্দ করুন।
স্টেজিং, একটি অনিবার্য মালিক, অ্যাকসেপ্ট্যান্স ক্রাইটেরিয়া এবং একটি রোলব্যাক প্ল্যান ব্যবহার করুন। SIU অনিচ্ছাকৃত অভিজ্ঞতা অবনতি প্রতিরোধ করে।
পরিবর্তন রেকর্ডে কেবল স্কোর নয়—মেট্রিক, টেস্ট কন্ডিশন এবং সম্পন্ন ভিজিটর টাস্ক অন্তর্ভুক্ত রাখুন।