document.write() এর বিরুদ্ধে হস্তক্ষেপ করা

পল কিনলান

আপনি কি সম্প্রতি Chrome এ আপনার ডেভেলপার কনসোলে নিচের মতো একটি সতর্কতা দেখেছেন এবং ভাবছেন এটি কী?

(index):34 A Parser-blocking, cross-origin script,
https://paul.kinlan.me/ad-inject.js, is invoked via document.write().
This may be blocked by the browser if the device has poor network connectivity.

কম্পোজেবিলিটি হল ওয়েবের মহান শক্তিগুলির মধ্যে একটি, যা আমাদেরকে সহজেই তৃতীয় পক্ষের দ্বারা নির্মিত পরিষেবাগুলির সাথে একীভূত করার অনুমতি দেয় যাতে দুর্দান্ত নতুন পণ্য তৈরি করা যায়! কম্পোজেবিলিটির একটি খারাপ দিক হল যে এটি ব্যবহারকারীর অভিজ্ঞতার উপর একটি ভাগ করা দায়িত্ব বোঝায়। যদি ইন্টিগ্রেশন উপ-অনুকূল হয়, ব্যবহারকারীর অভিজ্ঞতা নেতিবাচকভাবে প্রভাবিত হবে।

দুর্বল কর্মক্ষমতার একটি পরিচিত কারণ হল পৃষ্ঠার ভিতরে document.write() ব্যবহার করা, বিশেষ করে সেগুলি ব্যবহার করে যা স্ক্রিপ্ট ইনজেক্ট করে। নিম্নলিখিত দেখায় হিসাবে নিরীহ, এটি ব্যবহারকারীদের জন্য বাস্তব সমস্যা সৃষ্টি করতে পারে.

document.write('<script src="https://example.com/ad-inject.js"></script>');

ব্রাউজার একটি পৃষ্ঠা রেন্ডার করার আগে, এটিকে HTML মার্কআপ পার্স করে DOM ট্রি তৈরি করতে হবে। যখনই পার্সার একটি স্ক্রিপ্টের মুখোমুখি হয় তখন এটি এইচটিএমএল পার্সিং চালিয়ে যাওয়ার আগে এটিকে থামাতে এবং কার্যকর করতে হয়। যদি স্ক্রিপ্টটি গতিশীলভাবে অন্য একটি স্ক্রিপ্ট ইনজেক্ট করে, পার্সারকে রিসোর্সটি ডাউনলোড করার জন্য আরও বেশি সময় অপেক্ষা করতে বাধ্য করা হয়, যার ফলে এক বা একাধিক নেটওয়ার্ক রাউন্ডট্রিপ হতে পারে এবং পৃষ্ঠাটির প্রথম রেন্ডার হতে সময় বিলম্বিত হতে পারে।

2G-এর মতো ধীর সংযোগে থাকা ব্যবহারকারীদের জন্য, document.write() মাধ্যমে গতিশীলভাবে ইনজেক্ট করা বাহ্যিক স্ক্রিপ্টগুলি মূল পৃষ্ঠার বিষয়বস্তু প্রদর্শনে কয়েক সেকেন্ডের জন্য বিলম্ব করতে পারে, অথবা পৃষ্ঠাগুলি লোড হতে ব্যর্থ হতে পারে বা এত বেশি সময় নিতে পারে যে ব্যবহারকারী কেবলমাত্র দেয়। আপ ক্রোমের ইন্সট্রুমেন্টেশনের উপর ভিত্তি করে, আমরা শিখেছি যে document.write() মাধ্যমে ঢোকানো তৃতীয়-পক্ষের স্ক্রিপ্ট সমন্বিত পৃষ্ঠাগুলি সাধারণত 2G-তে অন্যান্য পৃষ্ঠাগুলির তুলনায় দ্বিগুণ ধীর গতিতে লোড হয়৷

আমরা 1% Chrome স্থিতিশীল ব্যবহারকারীদের 28 দিনের ফিল্ড ট্রায়াল থেকে ডেটা সংগ্রহ করেছি, যা 2G সংযোগের ব্যবহারকারীদের জন্য সীমাবদ্ধ। আমরা দেখেছি যে 2G-তে সমস্ত পৃষ্ঠা লোডের 7.6% অন্তত একটি ক্রস-সাইট, পার্সার-ব্লকিং স্ক্রিপ্ট অন্তর্ভুক্ত করে যা document.write() এর মাধ্যমে শীর্ষ স্তরের নথিতে সন্নিবেশ করা হয়েছিল। এই স্ক্রিপ্টগুলির লোড ব্লক করার ফলস্বরূপ, আমরা সেই লোডগুলিতে নিম্নলিখিত উন্নতিগুলি দেখেছি:

  • 10% বেশি পৃষ্ঠা লোড প্রথম কন্টেন্টফুল পেইন্টে পৌঁছায় (ব্যবহারকারীর জন্য একটি ভিজ্যুয়াল নিশ্চিতকরণ যে পৃষ্ঠাটি কার্যকরভাবে লোড হচ্ছে), 25% বেশি পৃষ্ঠা লোড সম্পূর্ণরূপে পার্স করা অবস্থায় পৌঁছেছে এবং 10% কম রিলোড ব্যবহারকারীর হতাশা হ্রাসের পরামর্শ দিচ্ছে৷
  • প্রথম কন্টেন্টফুল পেইন্ট পর্যন্ত গড় সময়ের 21% হ্রাস (এক সেকেন্ডের বেশি দ্রুত)
  • একটি পৃষ্ঠা পার্স করতে যে গড় সময় লাগে তার 38% হ্রাস, প্রায় ছয় সেকেন্ডের উন্নতির প্রতিনিধিত্ব করে, ব্যবহারকারীর কাছে যা গুরুত্বপূর্ণ তা প্রদর্শন করতে সময় নাটকীয়ভাবে হ্রাস করে৷

এই ডেটার কথা মাথায় রেখে, ক্রোম, সংস্করণ 55 থেকে শুরু করে, সমস্ত ব্যবহারকারীর পক্ষে হস্তক্ষেপ করে যখন আমরা Chrome-এ document.write() কীভাবে পরিচালনা করা হয় তা পরিবর্তন করে এই পরিচিত-খারাপ প্যাটার্ন শনাক্ত করি ( Chrome Status দেখুন)। নিম্নলিখিত সমস্ত শর্ত পূরণ হলে Chrome নির্দিষ্টভাবে <script> উপাদানগুলিকে document.write() এর মাধ্যমে ইনজেকশন করবে না:

  1. ব্যবহারকারী একটি ধীর সংযোগে থাকে, বিশেষত যখন ব্যবহারকারী 2G ব্যবহার করেন। (ভবিষ্যতে, পরিবর্তনটি ধীরগতির সংযোগে অন্যান্য ব্যবহারকারীদের কাছে প্রসারিত হতে পারে, যেমন ধীর 3G বা ধীর ওয়াইফাই।)
  2. document.write() একটি শীর্ষ স্তরের নথিতে রয়েছে। আইফ্রেমের মধ্যে থাকা document.written স্ক্রিপ্টগুলিতে হস্তক্ষেপ প্রযোজ্য নয় কারণ তারা মূল পৃষ্ঠার রেন্ডারিংকে ব্লক করে না।
  3. document.write() এর স্ক্রিপ্টটি পার্সার-ব্লকিং। ' async ' বা ' defer ' বৈশিষ্ট্য সহ স্ক্রিপ্টগুলি এখনও কার্যকর হবে৷
  4. স্ক্রিপ্ট একই সাইটে হোস্ট করা হয় না. অন্য কথায়, ক্রোম একটি মিলে যাওয়া eTLD+1 সহ স্ক্রিপ্টগুলির জন্য হস্তক্ষেপ করবে না (যেমন js.example.org-এ হোস্ট করা একটি স্ক্রিপ্ট www.example.org-এ ঢোকানো হয়েছে)৷
  5. স্ক্রিপ্টটি ইতিমধ্যে ব্রাউজার HTTP ক্যাশে নেই। ক্যাশে থাকা স্ক্রিপ্টগুলি কোনও নেটওয়ার্ক বিলম্বের কারণ হবে না এবং এখনও কার্যকর হবে৷
  6. পৃষ্ঠার জন্য অনুরোধ একটি পুনরায় লোড নয়. ব্যবহারকারী পুনরায় লোড ট্রিগার করলে Chrome হস্তক্ষেপ করবে না এবং পৃষ্ঠাটিকে স্বাভাবিক হিসাবে চালাবে।

থার্ড পার্টি স্নিপেট কখনো কখনো document.write() ব্যবহার করে স্ক্রিপ্ট লোড করতে। সৌভাগ্যবশত, অধিকাংশ তৃতীয় পক্ষই অসিঙ্ক্রোনাস লোডিং বিকল্প প্রদান করে, যা পৃষ্ঠার বাকি বিষয়বস্তু প্রদর্শনকে অবরুদ্ধ না করে তৃতীয় পক্ষের স্ক্রিপ্টগুলিকে লোড করার অনুমতি দেয়।

আমি কিভাবে এটা ঠিক করব?

এই সহজ উত্তর হল document.write() ব্যবহার করে স্ক্রিপ্ট ইনজেক্ট করবেন না। আমরা অ্যাসিঙ্ক্রোনাস লোডার সমর্থনের জন্য পরিচিত পরিষেবাগুলির একটি সেট বজায় রাখি যা আমরা আপনাকে পরীক্ষা চালিয়ে যেতে উত্সাহিত করি।

যদি আপনার প্রদানকারী তালিকায় না থাকে এবং অ্যাসিঙ্ক্রোনাস স্ক্রিপ্ট লোডিং সমর্থন করে তবে দয়া করে আমাদের জানান এবং আমরা সমস্ত ব্যবহারকারীদের সাহায্য করার জন্য পৃষ্ঠাটি আপডেট করতে পারি ।

যদি আপনার প্রদানকারী আপনার পৃষ্ঠায় অ্যাসিঙ্ক্রোনাসভাবে স্ক্রিপ্টগুলি লোড করার ক্ষমতা সমর্থন না করে তাহলে আমরা আপনাকে তাদের সাথে যোগাযোগ করতে উত্সাহিত করি এবং আমাদের এবং তাদের জানান যে তারা কীভাবে প্রভাবিত হবে।

যদি আপনার প্রদানকারী আপনাকে একটি স্নিপেট দেয় যাতে document.write() অন্তর্ভুক্ত থাকে, তাহলে আপনার পক্ষে স্ক্রিপ্ট এলিমেন্টে একটি async অ্যাট্রিবিউট যোগ করা সম্ভব হতে পারে, অথবা আপনার জন্য ডকুমেন্ট এপিআই-এর মতো স্ক্রিপ্ট এলিমেন্ট যোগ করা সম্ভব হতে পারে যেমন document.appendChild() বা parentNode.insertBefore() ।

আপনার সাইট প্রভাবিত হলে কিভাবে সনাক্ত করা যায়

বিধিনিষেধ প্রয়োগ করা হয়েছে কিনা তা নির্ধারণ করে এমন একটি বড় সংখ্যক মানদণ্ড রয়েছে, তাই আপনি প্রভাবিত হলে কীভাবে জানবেন?

একজন ব্যবহারকারী কখন 2G-তে থাকে তা সনাক্ত করা

এই পরিবর্তনের সম্ভাব্য প্রভাব বোঝার জন্য আপনাকে প্রথমে বুঝতে হবে আপনার কতজন ব্যবহারকারী 2G-তে থাকবে। আপনি Chrome-এ উপলব্ধ নেটওয়ার্ক ইনফরমেশন API ব্যবহার করে ব্যবহারকারীর বর্তমান নেটওয়ার্কের ধরন এবং গতি শনাক্ত করতে পারেন এবং তারপর আপনার বিশ্লেষণাত্মক বা রিয়েল ইউজার মেট্রিক্স (RUM) সিস্টেমে একটি হেড-আপ পাঠাতে পারেন।

if(navigator.connection &&
    navigator.connection.type === 'cellular' &&
    navigator.connection.downlinkMax <= 0.115) {
    // Notify your service to indicate that you might be affected by this restriction.
}

Chrome DevTools-এ সতর্কতা দেখুন

Chrome 53 থেকে, DevTools সমস্যাযুক্ত document.write() স্টেটমেন্টের জন্য সতর্কতা জারি করে। বিশেষভাবে, যদি কোনো document.write() অনুরোধ 2 থেকে 5 মানদণ্ড পূরণ করে (Chrome এই সতর্কবার্তা পাঠানোর সময় সংযোগের মানদণ্ড উপেক্ষা করে), সতর্কতাটি এরকম কিছু দেখাবে:

নথি লেখার সতর্কতা।

Chrome DevTools-এ সতর্কতা দেখা দুর্দান্ত, কিন্তু আপনি কীভাবে এটি স্কেলে সনাক্ত করবেন? হস্তক্ষেপ ঘটলে আপনি HTTP শিরোনামগুলি পরীক্ষা করতে পারেন যা আপনার সার্ভারে পাঠানো হয়।

স্ক্রিপ্ট রিসোর্সে আপনার HTTP হেডার চেক করুন

যখন document.write এর মাধ্যমে ঢোকানো একটি স্ক্রিপ্ট ব্লক করা হয়, Chrome অনুরোধ করা সংস্থানে নিম্নলিখিত শিরোনামটি পাঠাবে:

Intervention: <https://shorturl/relevant/spec>;

যখন document.write এর মাধ্যমে ঢোকানো একটি স্ক্রিপ্ট পাওয়া যায় এবং বিভিন্ন পরিস্থিতিতে ব্লক করা যেতে পারে, তখন Chrome পাঠাতে পারে:

Intervention: <https://shorturl/relevant/spec>; level="warning"

হস্তক্ষেপ শিরোনামটি স্ক্রিপ্টের জন্য GET অনুরোধের অংশ হিসাবে পাঠানো হবে (একটি প্রকৃত হস্তক্ষেপের ক্ষেত্রে অ্যাসিঙ্ক্রোনাসভাবে)।

ভবিষ্যৎ কি ধরে?

প্রাথমিক পরিকল্পনা হল এই হস্তক্ষেপটি কার্যকর করা যখন আমরা সনাক্ত করি যে মানদণ্ড পূরণ করা হচ্ছে। আমরা Chrome 53-এ ডেভেলপার কনসোলে শুধুমাত্র একটি সতর্কতা দেখানোর মাধ্যমে শুরু করেছি। (বিটা জুলাই 2016-এ ছিল। আমরা আশা করি যে সেপ্টেম্বর 2016-এ সমস্ত ব্যবহারকারীদের জন্য Stable উপলব্ধ হবে।)

আমরা 2G ব্যবহারকারীদের জন্য ইনজেক্টেড স্ক্রিপ্টগুলিকে ব্লক করতে হস্তক্ষেপ করব যা অস্থায়ীভাবে Chrome 54 থেকে শুরু করে, যা 2016 সালের অক্টোবরের মাঝামাঝি সময়ে সমস্ত ব্যবহারকারীদের জন্য একটি স্থিতিশীল প্রকাশে অনুমান করা হয়৷ আরও আপডেটের জন্য Chrome স্থিতি এন্ট্রিটি দেখুন৷

সময়ের সাথে সাথে, আমরা হস্তক্ষেপ করতে চাইছি যখন কোনো ব্যবহারকারীর একটি ধীর সংযোগ থাকে (যেমন, ধীর 3G বা WiFi)। এই ক্রোম স্ট্যাটাস এন্ট্রি অনুসরণ করুন।

আরো জানতে চান?

আরও জানতে, এই অতিরিক্ত সংস্থানগুলি দেখুন: