ব্রাউজার যেটা লোড করে তা থেকে একক ইনভেন্টরি তৈরি করুন
প্রতিনিধিত্বমূলক পেজ দিয়ে শুরু করুন: হোম, ল্যান্ডিং, ডিটেইল, সার্চ, কার্ট, চেকআউট, অ্যাকাউন্ট এবং ক্যাম্পেইন। Chrome DevTools‑এ নতুন এবং রিটার্ন ভিজিট রেকর্ড করুন। ব্রাউজার প্রমাণকে ট্যাগ ম্যানেজার, CMS প্লাগ-ইন এবং কোড নির্ভরতার সঙ্গে তুলনা করুন; একটি ভিউ ইনজেক্টেড স্ক্রিপ্ট মিস করতে পারে।
প্রতি URL নয়, প্রতি বিক্রেতা বা ইন্টিগ্রেশনের জন্য একটি সারি ব্যবহার করুন। এটি যে কোন ডোমেইনের সাথে যোগাযোগ করে এবং ট্যাগ যোগ করতে পারে কি না তা ধরে রাখুন। একটি ব্যবসায়িক মালিক দিন যে উদ্দেশ্য রক্ষা করতে এবং অপসারণ অনুমোদন করতে পারে। ক্যাম্পেইন, বিক্রেতা পরিবর্তন, টেমপ্লেট রিলিজ এবং রিডিজাইন করার পরে পুনরায় যাচাই করুন।
পেজ, জার্নি, বিক্রেতার ডোমেইন, অনুরোধ, ট্রান্সফার সাইজ, মেইন‑থ্রেড কাজ, এবং টেস্ট অবস্থার সেভ করুন। একটি ল্যাব ট্রেস নির্ণায়ক প্রমাণ; এটি প্রতিটি দর্শকের জন্য প্রতিশ্রুতি নয়।
উদ্দেশ্য, মালিক, সম্মতি শ্রেণি, ট্রিগার, উন্মোচিত ডেটা, নির্ভরশীলতার ক্রম, ব্যাকআপ এবং পর্যালোচনার তারিখ অন্তর্ভুক্ত করুন।
রাখুন, সরান এবং বাজেট সিদ্ধান্ত দৃশ্যমান করুন
প্রতিটি মালিককে জিজ্ঞাসা করুন ইন্টিগ্রেশন না থাকলে কোনটা সবচেয়ে খারাপ হবে। যদি অস্পষ্ট হয়, সেটি নিষ্ক্রিয় বা সরিয়ে দিন। web.dev বাজেট ব্যবহার, কাজের দ্বৈততা এড়ানো এবং অপ্রয়োজনীয় স্ক্রিপ্ট পরিষ্কারের পরামর্শ দেয়।
বাজেট হলো একটি দলের গার্ডরেইল, সার্বজনীন থ্রেশহোল্ড নয়। বাইট, অনুরোধ, মেইন‑থ্রেড সময় এবং লোড টাইমিং‑এর জন্য বিক্রেতা ও পেজভিত্তিক অনুমতি নির্ধারণ করুন। বেসলাইনকে একটি পরিবর্তনের সাথে তুলনা করুন। মালিককে অনুমতি সীমার মধ্যে থাকা, অন্য একটি ব্যয় অপসারণ করা বা মেয়াদসীমাযুক্ত ব্যতিক্রম নেওয়ার জন্য বলুন। তুলনীয় জার্নি এবং ব্যবহারকারী-কেন্দ্রিক মেট্রিক ব্যবহার করুন।
শুধুমাত্র সেই নির্ভরশীলতাগুলো রাখুন যেগুলোর বর্তমান উদ্দেশ্য আছে, মালিকের দ্বারা গৃহীত খরচ ও ডেটা ব্যবহার রয়েছে, এবং গ্রহণযোগ্য ব্যর্থতার পথ আছে।
মেয়াদোত্তীর্ণ পিক্সেল, ডুপ্লিকেট অ্যানালিটিক্স, নিষ্ক্রিয় চ্যাট, অব্যবহৃত পরীক্ষা এবং পরিত্যক্ত প্লাগ-ইন ধাপে ধাপে রিটায়ার করুন।
কারণ, খরচ, অনুমোদনকারী, প্রতিপূরণমূলক পদক্ষেপ এবং পুনরায় পর্যালোচনার তারিখ রেকর্ড করুন।
শুধুমাত্র তখন বিলম্ব করুন যখন বিলম্ব করা নিরাপদ
লোডিং আচরণ সচেতনভাবে নির্বাচন করুন। ক্লাসিক বহির্মুখী স্ক্রিপ্ট যা async, defer বা module আচরণ ছাড়াই আছে তা HTML পার্সিং চালিয়ে যাওয়ার আগে ফেচ এবং এক্সিকিউট হয়। async-এর সাথে, ডাউনলোড প্যারালাল হয় কিন্তু এক্সিকিউশন প্রস্তুত হলে শুরু হয়, তাই ক্রম গ্যারান্টিযুক্ত নয়। defer‑এর সাথে, ক্লাসিক বহির্মুখী স্ক্রিপ্ট পার্সিংয়ের পরে এবং ডকুমেন্ট ক্রমে DOMContentLoaded (ডকুমেন্ট লোড হওয়ার আগে) এর আগে চলবে; defer ক্রম প্রয়োজনীয় স্ক্রিপ্টের জন্য উপযুক্ত, তবে সার্বজনীন নয়।
অপশনাল চ্যাট, সোশ্যাল, মানচিত্র, ভিডিও, বা রিকমেন্ডেশন ইন্টারফেসের জন্য একটি হালকা প্লেসহোল্ডার রেন্ডার করে বিক্রেতাকে ক্লিকের পর বা প্রাসঙ্গিক হলে লোড করুন। এই ফ্যাসাড প্যাটার্নটি সম্পূর্ণ এম্বেডের বদলে আপনার নিয়ন্ত্রণ থেকে শুরু করে। কীবোর্ড ইন্টারঅ্যাকশন সংরক্ষণ করুন এবং স্থান রিজার্ভ করুন। মূল্য গণনা, সাইন‑ইন, পেমেন্ট প্রসেস করা, অপরিহার্য অ্যাক্সেসিবিলিটি প্রদান বা নিশ্চিত বাধ্যবাধকতা মেটাতে প্রয়োজনীয় কোড বিলম্ব করবেন না—এমন কেসে পর্যালোচিত বিকল্প ছাড়া বিলম্ব গ্রহণযোগ্য নয়।
শুধুমাত্র প্রথম‑টাস্ক নির্ভরশীলতার জন্য তাৎক্ষণিক লোড করুন; অর্ডার প্রয়োজন হলে পার্সের পর, এবং অপশনাল এম্বেডের জন্য ইন্টারঅ্যাকশন বা দৃশ্যমানতা ট্রিগার ব্যবহার করুন।
অন্তঃনির্ভর স্ক্রিপ্টগুলোকে async চিহ্নিত করে ক্রম ধরে রাখার প্রত্যাশা করবেন না। প্রকাশিত চেইন ডকুমেন্ট করুন এবং পরীক্ষা করুন।
ক্রিটিক্যাল UI‑কে window load‑এর উপর বেঁধে দেবেন না; তৃতীয়‑পক্ষ এম্বেডগুলো async বা defer ব্যবহার করলেও এটাকে ধীর করতে পারে।
সম্মতিকে গেট করুন, পরে চিন্তা নয়
প্রতিটি বিক্রেতাকে গোপনীয়তা ও আইনি স্টেকহোল্ডারদের সাথে শ্রেণীবদ্ধ করুন যারা অঞ্চলভিত্তিক নিয়ম এবং ডেটা ফ্লো বুঝে। সম্মতি-নির্ভর ইন্টিগ্রেশনের জন্য, ট্যাগ প্রাসঙ্গিক ডেটা পাঠানোর আগে সম্মতি অবস্থা প্রতিষ্ঠা করুন। Google বলে যে তার ডিফল্ট কনসেন্ট কমান্ডটি মেজারমেন্ট কমান্ডগুলোর আগে চালানো উচিত এবং পছন্দ পরিবর্তন হলে আপডেট করা উচিত। এই পণ্য নির্দেশিকা আইনি পরামর্শ নয়।
প্রথম ভিজিটে কোনও পছন্দ নেই, গ্রহণ, প্রত্যাখ্যান এবং প্রত্যাহারের ক্ষেত্রে পরীক্ষা করুন। ইন্টারফেস এবং নেটওয়ার্ক দেখুন: একটি লুকানো উইজেট কোনো অনুরোধ বা শনাক্তকারী পাঠানো হয়নি বোঝায় না। যদি সম্মতি প্ল্যাটফর্ম অ্যাসিঙ্ক্রোনাসভাবে লোড হয়, সময়িং পরীক্ষা করুন। পছন্দগুলো যথাযথভাবে স্থায়ীকরণ করুন এবং বর্তমান পেজ ও পরবর্তি ভিজিটে পরিবর্তন প্রয়োগ করুন।
বিক্রেতার লেবেলে নির্ভর করবেন না। ট্যাগ কেন অপরিহার্য, অপশনাল বা একটি অঞ্চল/জার্নির জন্য নিষিদ্ধ তা রেকর্ড করে অনুমোদন নিন।
প্রত্যাহারের পরে কনফিগার করা অপ্রয়োজনীয় ট্যাগ লোড বা ডেটা পাঠাচ্ছে না তা নিশ্চিত করুন এবং টেস্ট প্রমাণ রাখুন।
আপনি নিয়ন্ত্রণ করেন না এমন কোডের বিস্ফোরণ ক্ষেত্র (blast radius) কমান
OWASP ক্লায়েন্ট‑সাইড পরিবর্তনে নিয়ন্ত্রণ হারানো, ব্রাউজারে অপরিবর্তিত কোড এক্সিকিউশন, এবং সংবেদনশীল ডেটা ফাঁসকে কেন্দ্রীয় ঝুঁকি হিসেবে চিহ্নিত করে। ট্যাগ‑পাবলিশিং এক্সেস সীমাবদ্ধ করুন, কাস্টম HTML বা任意 কোড ফিচার পর্যালোচনা করুন, এবং অনুমোদিত ডেটা‑লেয়ার ফিল্ড নথিভুক্ত করুন। উচ্চ‑ঝুঁকির ইন্টিগ্রেশনের জন্য বিক্রেতা চুক্তি ও যোগ্যতাসম্পন্ন নিরাপত্তা পর্যালোচনা সহায়ক হতে পারে; তবুও এগুলো পরীক্ষার বিকল্প নয়।
Subresource Integrity (SRI) ব্রাউজারকে ক্রিপ্টোগ্রাফিক হ্যাশ দিয়ে স্ক্রিপ্ট যাচাই করতে দেয়। এটি তখনই সহায়ক যখন একটি রিসোর্স পিন করা যায় এবং ক্রস‑অরিজিন ডেলিভারি CORS সমর্থন করে; W3C বলে CORS ছাড়া SRI ব্যবহার করা যৌক্তিক ত্রুটি। অনেক পরিবর্তনশীল বিক্রেতা URL‑এর জন্য এটি প্রায়ই অনুপযুক্ত। একটি iframe sandbox হোস্ট DOM এবং কুকিজে সরাসরি অ্যাক্সেস কমাতে পারে, তবে বিশেষজ্ঞ পর্যালোচনা দরকার। পেমেন্ট এবং নিরাপত্তা‑সংবেদনশীল ফ্লো‑র জন্য যোগ্য পর্যালোচনা প্রয়োজন।
উদ্দেশ্যের জন্য প্রয়োজনীয়ই কেবল ডকুমেন্টেড ফিল্ড পাস করুন। সিক্রেট, পেমেন্ট ডেটা বা অপ্রয়োজনীয় গ্রাহক অ্যাট্রিবিউট উন্মুক্ত করবেন না।
SRI কেবল বাইট যাচাই করে, পরে ডেটা ব্যবহার বা অনুরোধ উপযুক্ত কি না তা নয়; বিচ্ছিন্নতা (isolation) স্বয়ংক্রিয় সমাধান নয়।
গ্রাহকদের আগে বিক্রেতার ব্যর্থতা অনুশীলন করুন
প্রতিটি রাখা বিক্রেতার জন্য, একটি পরীক্ষামূলক পরিবেশ বা ব্রাউজার অনুরোধ ব্লকারে তার ডোমেইন ব্লক করুন এবং তারপর জার্নি অনুশীলন করুন। ধীর প্রতিক্রিয়া এবং ট্যাগ‑ম্যানেজারের কনফিগারেশন ছাড়া ট্যাগও পরীক্ষা করুন। নিশ্চিত করুন প্রাথমিক কনটেন্ট, নেভিগেশন, ফর্ম, চেকআউট এবং অ্যাকাউন্ট অ্যাক্সেস প্রত্যাশিতভাবে আচরণ করে—এটি মুক্তির আগে অনুমানগুলো প্রকাশ করে।
ঘটনার আগে প্রতিকার সংজ্ঞায়িত করুন: কে ট্যাগ নিষ্ক্রিয় করতে পারে, ফ্ল্যাগ বা ট্যাগ‑ম্যানেজার পাবলিশ প্রয়োজন কি না, কিভাবে রোলব্যাক করবেন, এবং কিভাবে যাচাই করবেন। SIU হলো সক্রিয় আপটাইম অপটিমাইজেশন ও প্রতিকার: ইনভেন্টরি, বাজেট, প্রিফ্লাইট এবং রোলব্যাক অনুশীলন ব্যবহার করে নির্ভরশীলতা ঝুঁকি কমান। SIU বিক্রেতার অবকাঠামো নিয়ন্ত্রণ করতে পারে না, উপলভ্যতার গ্যারান্টি দেয় না, এবং পর্যালোচনার বদলি নয়।
বিক্রেতা ছাড়া কী ব্যবহারযোগ্য থাকে, কী মন্থর হতে পারে, ব্যাকআপ কী, এবং নিষ্ক্রিয় করার সর্বোচ্চ বিলম্ব কত তা নির্ধারণ করুন।
পরিবর্তনের রেকর্ডে আগে‑ওপরের ট্রেস, সম্মতির ফল, ব্লক‑কৃত‑বিক্রেতা ফল এবং রোলব্যাক মালিক সংযুক্ত করুন।