ব্রাউজার প্রিলোড স্ক্যানারকে উপেক্ষা করবেন না

ব্রাউজার প্রিলোড স্ক্যানার কী, এটি কীভাবে পারফর্ম্যান্স উন্নত করতে সাহায্য করে এবং আপনি কীভাবে এর থেকে দূরে থাকতে পারেন তা জানুন।

Jeremy Wagner

পৃষ্ঠা লোড হওয়ার গতি অপ্টিমাইজ করার একটি উপেক্ষিত দিক হল ব্রাউজারের ইন্টার্নাল সম্পর্কে কিছুটা জানা। ব্রাউজার পারফর্ম্যান্স উন্নত করার জন্য নির্দিষ্ট কিছু অপ্টিমাইজেশন করে যা ডেভেলপার হিসেবে আমরা করতে পারি না—তবে শুধুমাত্র ততক্ষণ পর্যন্ত যতক্ষণ না সেই অপ্টিমাইজেশনগুলি অনিচ্ছাকৃতভাবে বাধাগ্রস্ত হয়।

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

প্রিলোড স্ক্যানার কী?

প্রতিটি ব্রাউজারে একটি প্রাথমিক HTML পার্সার থাকে যা র মার্কআপকে টোকেনাইজ করে এবং এটিকে একটি অবজেক্ট মডেলে প্রসেস করে। পার্সার কোনও ব্লকিং রিসোর্স খুঁজে না পাওয়া পর্যন্ত এই প্রক্রিয়া চলতে থাকে। ব্লকিং রিসোর্স হল <link> এলিমেন্ট সহ লোড করা স্টাইলশিট অথবা async বা defer অ্যাট্রিবিউট ছাড়া <script> এলিমেন্ট সহ লোড করা স্ক্রিপ্ট।

CSS ফাইলের ক্ষেত্রে, ফ্ল্যাশ অফ আনস্টাইলড কন্টেন্ট (FOUC) প্রতিরোধ করার জন্য রেন্ডারিং ব্লক করা হয়, যা হল কোনও পৃষ্ঠার স্টাইল প্রয়োগ করার আগে পৃষ্ঠার একটি আনস্টাইলড ভার্সন সংক্ষেপে দেখা যেতে পারে।

এছাড়াও, defer বা async অ্যাট্রিবিউট ছাড়া <script> এলিমেন্ট পেলে, ব্রাউজার পৃষ্ঠার পার্সিং ও রেন্ডারিং ব্লক করে দেয়।

এর কারণ হল, প্রাইমারি HTML পার্সার কাজ করার সময় কোনও স্ক্রিপ্ট DOM-এ পরিবর্তন করবে কিনা তা ব্রাউজার নিশ্চিতভাবে জানতে পারে না। এই কারণে, ডকুমেন্টের শেষে জাভাস্ক্রিপ্ট লোড করা একটি সাধারণ প্র্যাকটিস, যাতে ব্লক করা পার্সিং এবং রেন্ডারিংয়ের প্রভাব ন্যূনতম হয়।

ব্রাউজার কেন পার্সিং ও রেন্ডারিং, দুটিই ব্লক করবে, তার জন্য এগুলি হল ভালো কারণ। তবুও, এই গুরুত্বপূর্ণ পদক্ষেপগুলির মধ্যে যেকোনও একটি ব্লক করা অবাঞ্ছিত, কারণ তারা অন্যান্য গুরুত্বপূর্ণ রিসোর্স আবিষ্কারে বিলম্ব করে শোটি আটকে রাখতে পারে। তবে, ব্রাউজারগুলি প্রিলোড স্ক্যানার নামে একটি সেকেন্ডারি HTML পার্সারের মাধ্যমে এই সমস্যাগুলি কমানোর জন্য যথাসাধ্য চেষ্টা করে।

প্রিলোড স্ক্যানারের ভূমিকা হল অনুমান করা, অর্থাৎ এটি প্রাইমারি HTML পার্সার আবিষ্কার করার আগেই সুযোগ বুঝে রিসোর্স খুঁজে পেতে র মার্কআপ পরীক্ষা করে।

প্রিলোড স্ক্যানার কখন কাজ করছে তা কীভাবে বুঝবেন

ব্লক করা রেন্ডারিং ও পার্সিংয়ের কারণে প্রিলোড স্ক্যানার থাকে। পারফর্ম্যান্স সংক্রান্ত এই দুটি সমস্যা না থাকলে, প্রিলোড স্ক্যানার খুব একটা কাজে লাগত না। কোনও ওয়েব পেজ প্রিলোড স্ক্যানার থেকে সুবিধা পায় কিনা তা বোঝার মূল উপায় হল এই ব্লকিংয়ের ঘটনা। এটি করার জন্য, প্রিলোড স্ক্যানার কোথায় কাজ করছে তা খুঁজে বের করার অনুরোধের জন্য আপনি একটি কৃত্রিম বিলম্বের ব্যবস্থা করতে পারেন।

উদাহরণ হিসেবে স্টাইলশিট সহ সাধারণ টেক্সট ও ছবির এই পৃষ্ঠাটি দেখুন। যেহেতু CSS ফাইল রেন্ডারিং ও পার্সিং, দুটিকেই ব্লক করে, তাই আপনি প্রক্সি পরিষেবার মাধ্যমে স্টাইলশিটের জন্য দুই সেকেন্ডের একটি কৃত্রিম বিলম্বের সূচনা করেন। এই বিলম্বের ফলে নেটওয়ার্ক ওয়াটারফলে প্রিলোড স্ক্যানার কোথায় কাজ করছে তা দেখতে সুবিধা হয়।

আপনি ওয়াটারফলে দেখতে পাচ্ছেন যে প্রিলোড স্ক্যানার <img> এলিমেন্ট খুঁজে পায় এমনকি রেন্ডারিং ও ডকুমেন্ট পার্সিং ব্লক করা থাকলেও। এই অপ্টিমাইজেশন ছাড়া, ব্রাউজার ব্লকিং পিরিয়ডের সময় সুযোগ বুঝে জিনিসপত্র ফেচ করতে পারে না এবং আরও রিসোর্স অনুরোধ সমবর্তী হওয়ার পরিবর্তে পরপর হবে।

খেলনার উদাহরণটি বাদ দিয়ে, আসুন কিছু বাস্তব-জগতের প্যাটার্ন দেখে নেওয়া যাক যেখানে প্রিলোড স্ক্যানারকে পরাজিত করা যেতে পারে—এবং সেগুলি ঠিক করার জন্য কী করা যেতে পারে।

asyncটি স্ক্রিপ্ট ইনজেক্ট করা হয়েছে

ধরা যাক, আপনার <head>-এ HTML আছে যার মধ্যে এই ধরনের কিছু ইনলাইন জাভাস্ক্রিপ্ট আছে:

<script>
  const scriptEl = document.createElement('script');
  scriptEl.src = '/yall.min.js';

  document.head.appendChild(scriptEl);
</script>

ইনজেক্ট করা স্ক্রিপ্ট ডিফল্ট হিসেবে async হয়, তাই এই স্ক্রিপ্ট ইনজেক্ট করা হলে, এটি এমনভাবে কাজ করবে যেন async অ্যাট্রিবিউট এতে প্রয়োগ করা হয়েছে। এর অর্থ হল, এটি যত তাড়াতাড়ি সম্ভব রান করবে এবং রেন্ডারিং ব্লক করবে না। দারুণ, তাই না? তবুও, আপনি যদি মনে করেন যে এই ইনলাইন <script>, <link> এলিমেন্টের পরে আসে যা একটি এক্সটার্নাল CSS ফাইল লোড করে, তাহলে আপনি সাবঅপ্টিমাল ফলাফল পাবেন:

এখানে কী ঘটেছে তা বিশ্লেষণ করা যাক:

1. ০ সেকেন্ডে, প্রধান ডকুমেন্টের অনুরোধ করা হয়েছে।
2. ১.৪ সেকেন্ডে, নেভিগেশন অনুরোধের প্রথম বাইট আসে।
3. ২.০ সেকেন্ডে, CSS এবং ছবির জন্য অনুরোধ করা হয়েছে।
4. যেহেতু পার্সার স্টাইলশিট লোড করা ব্লক করে এবং ইনলাইন জাভাস্ক্রিপ্ট যা async স্ক্রিপ্ট ইনজেক্ট করে তা ২.৬ সেকেন্ডে সেই স্টাইলশিটের পরে আসে, তাই স্ক্রিপ্ট যে কার্যকারিতা প্রদান করে তা যত তাড়াতাড়ি সম্ভব উপলভ্য হয় না।

এটি সাবঅপ্টিমাল কারণ স্টাইলশিট ডাউনলোড করা শেষ হওয়ার পরেই স্ক্রিপ্টের জন্য অনুরোধ করা হয়। এর ফলে স্ক্রিপ্ট যত তাড়াতাড়ি সম্ভব রান করার ক্ষেত্রে দেরি হয়। অন্যদিকে, <img> এলিমেন্টটি সার্ভার-প্রদত্ত মার্কআপে খুঁজে পাওয়া যায় বলে, এটি প্রিলোড স্ক্যানার খুঁজে পায়।

তাহলে, DOM-এ স্ক্রিপ্ট ইনজেক্ট করার পরিবর্তে async অ্যাট্রিবিউট সহ সাধারণ <script> ট্যাগ ব্যবহার করলে কী হবে?

<script src="/yall.min.js" async></script>

এই হল ফলাফল:

rel=preload ব্যবহার করে এইসব সমস্যার সমাধান করা যেতে পারে বলে সাজেস্ট করার প্রলোভন থাকতে পারে। এটি অবশ্যই কাজ করবে, তবে এর কিছু পার্শ্বপ্রতিক্রিয়া থাকতে পারে। DOM-এ <script> এলিমেন্ট ইনজেক্ট না করে যে সমস্যা এড়ানো যায়, তা সমাধান করার জন্য rel=preload ব্যবহার করার প্রয়োজন কী?

প্রিলোড করা এখানে সমস্যার "সমাধান" করে, তবে এটি একটি নতুন সমস্যা তৈরি করে: প্রথম দুটি ডেমোতে async স্ক্রিপ্ট—<head>-এ লোড করা সত্ত্বেও—"কম" প্রায়োরিটিতে লোড করা হয়, যেখানে স্টাইলশিট "সর্বোচ্চ" প্রায়োরিটিতে লোড করা হয়। শেষ ডেমোতে যেখানে async স্ক্রিপ্ট প্রিলোড করা হয়েছে, সেখানে স্টাইলশিট এখনও "সর্বোচ্চ" অগ্রাধিকার দিয়ে লোড করা হয়েছে, তবে স্ক্রিপ্টের অগ্রাধিকার "বেশি"তে উন্নীত করা হয়েছে।

কোনও রিসোর্সের অগ্রাধিকার বাড়ানো হলে, ব্রাউজার সেটির জন্য আরও বেশি ব্যান্ডউইথ বরাদ্দ করে। এর অর্থ হল—স্টাইলশিটের সর্বোচ্চ অগ্রাধিকার থাকলেও—স্ক্রিপ্টের অগ্রাধিকার বাড়ানোর ফলে ব্যান্ডউইথ নিয়ে সমস্যা হতে পারে। ইন্টারনেট কানেকশন স্লো হলে বা রিসোর্স অনেক বড় হলে এটি হতে পারে।

এর উত্তর খুব সহজ: স্টার্টআপের সময় স্ক্রিপ্টের প্রয়োজন হলে, DOM-এ এটি ইনজেক্ট করে প্রিলোড স্ক্যানারকে পরাস্ত করবেন না। প্রয়োজন অনুযায়ী <script> এলিমেন্ট প্লেসমেন্ট এবং defer ও async-এর মতো অ্যাট্রিবিউট নিয়ে পরীক্ষা করে দেখুন।

জাভাস্ক্রিপ্টের মাধ্যমে ধীরে ধীরে লোড করা

ধীরে ধীরে লোড করা হল ডেটা সাশ্রয় করার একটি দুর্দান্ত পদ্ধতি, যা প্রায়শই ছবির ক্ষেত্রে প্রয়োগ করা হয়। তবে, কিছু ক্ষেত্রে "ভাঁজের উপরে" থাকা ছবিতে ধীরে ধীরে লোড হওয়ার পদ্ধতি ভুলভাবে প্রয়োগ করা হয়।

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

<img data-src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">

JavaScript-এর মাধ্যমে পরিচালিত লেজি লোডারে data- প্রিফিক্স ব্যবহার করা একটি সাধারণ প্যাটার্ন। ছবিটি ভিউপোর্টে স্ক্রল করা হলে, লেজি লোডার data- প্রিফিক্সটি সরিয়ে দেয়, যার অর্থ হল পূর্ববর্তী উদাহরণে, data-src হয়ে যায় src। এই আপডেট ব্রাউজারকে রিসোর্স ফেচ করার জন্য প্রম্পট করে।

স্টার্টআপের সময় ভিউপোর্টে থাকা ছবিতে প্রয়োগ না করা পর্যন্ত এই প্যাটার্নটি সমস্যাজনক নয়। প্রিলোড স্ক্যানার data-src অ্যাট্রিবিউটকে src (বা srcset) অ্যাট্রিবিউটের মতো করে পড়ে না, তাই ছবির রেফারেন্স আগে থেকে খুঁজে পাওয়া যায় না। আরও খারাপ হল, লেজি লোডার জাভাস্ক্রিপ্ট ডাউনলোড, কম্পাইল ও এক্সিকিউট হওয়ার পরে ইমেজ লোড হতে দেরি হয়।

ছবির সাইজের উপর নির্ভর করে—যা ভিউপোর্টের সাইজের উপর নির্ভর করতে পারে—এটি Largest Contentful Paint (LCP)-এর জন্য একটি ক্যান্ডিডেট এলিমেন্ট হতে পারে। প্রিলোড স্ক্যানার যখন সময়ের আগে ইমেজ রিসোর্স স্পেকুলেটিভভাবে ফেচ করতে পারে না—সম্ভবত সেই সময় যখন পৃষ্ঠার স্টাইলশিট রেন্ডারিং ব্লক করে—LCP-র উপর প্রভাব পড়ে।

সমাধান হল, ছবির মার্কআপ পরিবর্তন করা:

<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">

স্টার্টআপের সময় ভিউপোর্টে থাকা ছবির জন্য এটি হল সবচেয়ে ভালো প্যাটার্ন, কারণ প্রিলোড স্ক্যানার আরও দ্রুত ছবির রিসোর্স খুঁজে নিয়ে আসবে।

এই সরলীকৃত উদাহরণের ফলাফল হল, স্লো কানেকশনে LCP-তে ১০০-মিলিসেকেন্ডের উন্নতি। এটি হয়ত বিশাল কিছু শোনাচ্ছে না, তবে আপনি যদি কোনও ম্যাচ চলাকালীন লেভেল ৩ বর্ম খুঁজে পান, তাহলে এই অতিরিক্ত স্থায়িত্ব একটি ম্যাচের শেষ মুহূর্তে বড় সুবিধা করে দেয়। এর অর্থ হল, LCP ক্যান্ডিডেটকে অন্যান্য অনেক রিসোর্সের সাথে ব্যান্ডউইথের জন্য প্রতিযোগিতা করতে হতে পারে, তাই এই ধরনের অপ্টিমাইজেশন ক্রমশ গুরুত্বপূর্ণ হয়ে উঠছে।

CSS ব্যাকগ্রাউন্ড ছবি

মনে রাখবেন যে ব্রাউজার প্রিলোড স্ক্যানার মার্কআপ স্ক্যান করে। এটি অন্যান্য রিসোর্সের ধরন স্ক্যান করে না, যেমন CSS, যার মধ্যে background-image প্রপার্টি দ্বারা রেফারেন্স করা ছবির জন্য ফেচ করা অন্তর্ভুক্ত থাকতে পারে।

HTML-এর মতো, ব্রাউজার CSS-কে নিজস্ব অবজেক্ট মডেলে প্রসেস করে, যা CSSOM নামে পরিচিত। CSSOM তৈরি করার সময় এক্সটার্নাল রিসোর্স খুঁজে পাওয়া গেলে, খুঁজে পাওয়ার সময় সেই রিসোর্সের জন্য অনুরোধ করা হয়, প্রিলোড স্ক্যানারের মাধ্যমে নয়।

ধরা যাক, আপনার পৃষ্ঠার LCP ক্যান্ডিডেট হল CSS background-image প্রপার্টি সহ একটি এলিমেন্ট। রিসোর্স লোড হওয়ার সময় নিম্নলিখিত ঘটনাগুলি ঘটে:

এই ক্ষেত্রে, প্রিলোড স্ক্যানারটি খুব বেশি পরাজিত হয় না কারণ এটি জড়িত নয়। এমনকি, পৃষ্ঠায় LCP ক্যান্ডিডেট background-image CSS প্রপার্টি থেকে হলে, আপনি সেই ছবি প্রিলোড করতে চাইবেন:

<!-- Make sure this is in the <head> below any
     stylesheets, so as not to block them from loading -->
<link rel="preload" as="image" href="lcp-image.jpg">

এই rel=preload ইঙ্গিতটি ছোট, তবে এটি ব্রাউজারকে অন্যথায় যে সময়ের মধ্যে ছবিটি আবিষ্কার করতে পারে তার চেয়ে দ্রুত ছবিটি আবিষ্কার করতে সহায়তা করে:

rel=preload হিন্টের মাধ্যমে, LCP ক্যান্ডিডেট আরও দ্রুত খুঁজে পাওয়া যায়, যার ফলে LCP-এর সময় কমে যায়। এই ইঙ্গিতটি এই সমস্যার সমাধান করতে সাহায্য করলেও, আপনার ইমেজ LCP ক্যান্ডিডেট CSS থেকে লোড করতে হবে কিনা তা মূল্যায়ন করা আরও ভালো বিকল্প হতে পারে। <img> ট্যাগের মাধ্যমে, আপনি ভিউপোর্টের জন্য উপযুক্ত ছবি লোড করার উপর আরও নিয়ন্ত্রণ পাবেন এবং প্রিলোড স্ক্যানারকে এটি খুঁজে পেতে অনুমতি দেবেন।

অনেক বেশি রিসোর্স ইনলাইন করা হচ্ছে

ইনলাইনিং হল এমন একটি পদ্ধতি যা HTML-এর মধ্যে রিসোর্স যোগ করে। আপনি <style> এলিমেন্টে স্টাইলশিট, <script> এলিমেন্টে স্ক্রিপ্ট এবং base64 এনকোডিং ব্যবহার করে কার্যত অন্য যেকোনও রিসোর্স ইনলাইন করতে পারবেন।

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

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

উদাহরণ হিসেবে এই পৃষ্ঠা দেখুন। কিছু পরিস্থিতিতে LCP ক্যান্ডিডেট হল পৃষ্ঠার সবচেয়ে উপরে থাকা ছবি এবং CSS হল আলাদা ফাইলে থাকা <link> এলিমেন্ট দ্বারা লোড করা কন্টেন্ট। এছাড়াও, পৃষ্ঠাটি চারটি ওয়েব ফন্ট ব্যবহার করে যেগুলি CSS রিসোর্স থেকে আলাদা ফাইল হিসেবে অনুরোধ করা হয়।

এখন, CSS এবং সব ফন্ট base64 রিসোর্স হিসেবে ইনলাইন করা থাকলে কী হবে?

এই উদাহরণে ইনলাইনিংয়ের প্রভাব LCP-এর উপর নেতিবাচক ফলাফল দেয়—এবং সাধারণভাবে পারফর্ম্যান্সের উপর। পৃষ্ঠার যে ভার্সনে কোনও কিছু ইনলাইন করা হয় না, সেটি প্রায় ৩.৫ সেকেন্ডে LCP ছবি পেইন্ট করে। যে পৃষ্ঠায় সবকিছু ইনলাইন করা থাকে, সেখানে ৭ সেকেন্ডের বেশি সময় না হওয়া পর্যন্ত LCP ইমেজ পেইন্ট করা হয় না।

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

এখানে কি প্রিলোড করলে সুবিধা হবে? নিশ্চয়ই। আপনি LCP ইমেজ প্রিলোড করতে পারেন এবং LCP সময় কমাতে পারেন, তবে ইনলাইন রিসোর্স সহ আপনার সম্ভাব্য আনক্যাশেবল HTML-এর সাইজ বাড়ালে পারফর্ম্যান্সের উপর অন্যান্য নেতিবাচক প্রভাব পড়ে। First Contentful Paint (FCP)-এর উপরেও এই প্যাটার্নের প্রভাব পড়ে। পৃষ্ঠার যে ভার্সনে কিছুই ইনলাইন করা নেই, সেখানে FCP হল প্রায় ২.৭ সেকেন্ড। যে ভার্সনে সবকিছু ইনলাইন করা আছে, সেখানে FCP হল প্রায় ৫.৮ সেকেন্ড।

HTML-এ ইনলাইন করার সময় খুব সতর্ক থাকুন, বিশেষ করে base64-এনকোড করা রিসোর্সের ক্ষেত্রে। সাধারণত, খুব ছোট রিসোর্স ছাড়া এটি সাজেস্ট করা হয় না। যতটা সম্ভব কম ইনলাইন করুন, কারণ খুব বেশি ইনলাইন করা মানে আগুন নিয়ে খেলা।

ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্টের মাধ্যমে মার্কআপ রেন্ডার করা

এই বিষয়ে কোনও সন্দেহ নেই: জাভাস্ক্রিপ্ট অবশ্যই পৃষ্ঠা লোড হওয়ার গতির উপর প্রভাব ফেলে। ইন্টার‍্যাক্টিভিটি প্রদান করার জন্য ডেভেলপাররা শুধু এর উপর নির্ভর করেন না, কন্টেন্ট ডেলিভার করার জন্যও এর উপর নির্ভর করার প্রবণতা দেখা গেছে। এর ফলে কিছু ক্ষেত্রে ডেভেলপাররা আরও ভালো অভিজ্ঞতা পান; তবে ডেভেলপারদের জন্য সুবিধাগুলি সবসময় ব্যবহারকারীদের জন্য সুবিধায় রূপান্তরিত হয় না।

একটি প্যাটার্ন যা প্রিলোড স্ক্যানারকে হারাতে পারে তা হল ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্ট সহ মার্কআপ রেন্ডার করা:

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

এটি এই নিবন্ধের মূল বিষয় থেকে একটু আলাদা, তবে ক্লায়েন্টে মার্কআপ রেন্ডার করার প্রভাব প্রিলোড স্ক্যানারকে পরাস্ত করার চেয়ে অনেক বেশি। যেমন, জাভাস্ক্রিপ্ট প্রয়োজন নেই এমন অভিজ্ঞতায় জাভাস্ক্রিপ্ট ব্যবহার করলে প্রসেসিংয়ের জন্য অপ্রয়োজনীয় সময় লাগে যা ইন্টার‍্যাকশন টু নেক্সট পেইন্ট (INP)-কে প্রভাবিত করতে পারে। সার্ভার থেকে পাঠানো একই পরিমাণ মার্কআপের তুলনায় ক্লায়েন্টে অত্যন্ত বেশি পরিমাণ মার্কআপ রেন্ডার করলে বড় টাস্ক তৈরি হওয়ার সম্ভাবনা বেশি থাকে। এর কারণ হল—জাভাস্ক্রিপ্টের সাথে জড়িত অতিরিক্ত প্রসেসিং ছাড়াও—ব্রাউজারগুলি সার্ভার থেকে মার্কআপ স্ট্রিম করে এবং এমনভাবে রেন্ডারিং করে যাতে বড় টাস্ক সীমিত করা যায়। অন্যদিকে, ক্লায়েন্ট-রেন্ডার করা মার্কআপকে একটি একক, মনোলিথিক টাস্ক হিসেবে ম্যানেজ করা হয়, যা কোনও পৃষ্ঠার INP-কে প্রভাবিত করতে পারে।

এই পরিস্থিতিতে কী করা উচিত তা এই প্রশ্নের উত্তরের উপর নির্ভর করে: এমন কোনও কারণ আছে কি যার জন্য আপনার পৃষ্ঠার মার্কআপ ক্লায়েন্টে রেন্ডার করার পরিবর্তে সার্ভার থেকে প্রদান করা যাবে না? এর উত্তর "না" হলে, যেখানে সম্ভব সেখানে সার্ভার-সাইড রেন্ডারিং (SSR) বা স্ট্যাটিক্যালি জেনারেট করা মার্কআপ বিবেচনা করা উচিত, কারণ এটি প্রিলোড স্ক্যানারকে সময়ের আগেই গুরুত্বপূর্ণ রিসোর্স খুঁজে পেতে এবং সুযোগ বুঝে ফেচ করতে সাহায্য করবে।

আপনার পৃষ্ঠার মার্কআপের কিছু অংশে কার্যকারিতা যোগ করার জন্য যদি আপনার পৃষ্ঠায় জাভাস্ক্রিপ্টের প্রয়োজন হয়, তাহলেও আপনি SSR-এর মাধ্যমে তা করতে পারেন, হয় ভ্যানিলা জাভাস্ক্রিপ্ট ব্যবহার করে অথবা হাইড্রেশন ব্যবহার করে, যাতে আপনি দুটিরই সেরা সুবিধা পেতে পারেন।

প্রিলোড স্ক্যানারকে আপনাকে সাহায্য করতে দিন

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

সংক্ষেপে, এই পোস্ট থেকে আপনি নিম্নলিখিত বিষয়গুলি জানতে পারবেন:

• ব্রাউজার প্রিলোড স্ক্যানার হল একটি সেকেন্ডারি HTML পার্সার যা প্রাইমারি পার্সার ব্লক করা থাকলে তার আগেই স্ক্যান করে যাতে এটি আরও দ্রুত ফেচ করতে পারে এমন রিসোর্স খুঁজে পেতে পারে।
• প্রাথমিক নেভিগেশন অনুরোধে সার্ভার দ্বারা প্রদত্ত মার্কআপে উপস্থিত নেই এমন রিসোর্স প্রিলোড স্ক্যানার দ্বারা খুঁজে পাওয়া যাবে না। প্রিলোড স্ক্যানারকে যেসব উপায়ে এড়িয়ে যাওয়া যেতে পারে তার মধ্যে এগুলি অন্তর্ভুক্ত (তবে এগুলির মধ্যেই সীমাবদ্ধ নয়):
  • জাভাস্ক্রিপ্টের মাধ্যমে DOM-এ রিসোর্স ইনজেক্ট করা, তা স্ক্রিপ্ট, ছবি, স্টাইলশিট বা অন্য কিছু হতে পারে যা সার্ভার থেকে প্রাথমিক মার্কআপ পেলোডে থাকলে ভালো হয়।
  • জাভাস্ক্রিপ্ট সমাধান ব্যবহার করে ধীরে ধীরে লোড করা অ্যাবাভ-দ্য-ফোল্ড ছবি বা iframe।
  • ক্লায়েন্টে মার্কআপ রেন্ডার করা যাতে জাভাস্ক্রিপ্ট ব্যবহার করে ডকুমেন্ট সাবরিসোর্সের রেফারেন্স থাকতে পারে।
• প্রিলোড স্ক্যানার শুধু HTML স্ক্যান করে। এটি অন্যান্য রিসোর্সের কন্টেন্ট পরীক্ষা করে না—বিশেষ করে CSS—যার মধ্যে LCP ক্যান্ডিডেট সহ গুরুত্বপূর্ণ অ্যাসেটের রেফারেন্স থাকতে পারে।

যদি কোনও কারণে, আপনি এমন কোনও প্যাটার্ন এড়াতে না পারেন যা প্রিলোড স্ক্যানারের লোডিং পারফর্ম্যান্সের গতি বাড়ানোর ক্ষমতাকে নেতিবাচকভাবে প্রভাবিত করে, তাহলে rel=preload রিসোর্স হিন্ট বিবেচনা করুন। আপনি rel=preload ব্যবহার করলে, ল্যাব টুলে পরীক্ষা করে দেখুন যে এটি আপনাকে কাঙ্ক্ষিত ফলাফল দিচ্ছে কিনা। সবশেষে, খুব বেশি রিসোর্স প্রিলোড করবেন না, কারণ আপনি সব কিছুকে অগ্রাধিকার দিলে, কোনও কিছুই অগ্রাধিকার পাবে না।

রিসোর্স

• স্ক্রিপ্ট-ইনজেক্ট করা "অ্যাসিঙ্ক স্ক্রিপ্ট" ক্ষতিকারক হিসেবে বিবেচিত হয়
• ব্রাউজার প্রি-লোডার কীভাবে পৃষ্ঠা আরও দ্রুত লোড করে
• লোডিং স্পিড উন্নত করতে গুরুত্বপূর্ণ অ্যাসেট প্রিলোড করুন
• পৃষ্ঠা লোড হওয়ার গতি উন্নত করতে নেটওয়ার্ক কানেকশন আগে থেকে তৈরি করুন
• Largest Contentful Paint অপ্টিমাইজ করা