স্ক্রিপ্ট মূল্যায়ন এবং দীর্ঘ কাজ

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

Jeremy Wagner

যখন ইন্টারঅ্যাকশন টু নেক্সট পেইন্ট (INP) অপ্টিমাইজ করার কথা আসে, তখন আপনি বেশিরভাগ পরামর্শই পাবেন ইন্টারঅ্যাকশনগুলোকেই অপ্টিমাইজ করার বিষয়ে। উদাহরণস্বরূপ, 'অপ্টিমাইজ লং টাস্কস' গাইডে setTimeout সাথে yielding-এর মতো কৌশল এবং অন্যান্য বিষয় নিয়ে আলোচনা করা হয়েছে। এই কৌশলগুলো উপকারী, কারণ এগুলো দীর্ঘ টাস্ক এড়িয়ে মূল থ্রেডকে কিছুটা স্বস্তির সুযোগ দেয়, যার ফলে ইন্টারঅ্যাকশন এবং অন্যান্য কার্যকলাপ একটিমাত্র দীর্ঘ টাস্কের জন্য অপেক্ষা করার পরিবর্তে আরও দ্রুত চলার সুযোগ পায়।

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

স্ক্রিপ্ট মূল্যায়ন বলতে কী বোঝায়?

আপনি যদি এমন কোনো অ্যাপ্লিকেশনের প্রোফাইলিং করে থাকেন যেখানে প্রচুর জাভাস্ক্রিপ্ট ব্যবহৃত হয়েছে, তাহলে হয়তো এমন দীর্ঘ টাস্ক দেখে থাকবেন যেখানে মূল টাস্কটির নাম ‘Evaluate Script’ হিসেবে চিহ্নিত করা থাকে।

ব্রাউজারে জাভাস্ক্রিপ্ট চালানোর জন্য স্ক্রিপ্ট ইভ্যালুয়েশন একটি অপরিহার্য অংশ, কারণ জাভাস্ক্রিপ্ট এক্সিকিউশনের ঠিক আগে জাস্ট-ইন-টাইম কম্পাইল করা হয়। যখন একটি স্ক্রিপ্ট ইভ্যালুয়েট করা হয়, তখন প্রথমে এটিকে ত্রুটির জন্য পার্স করা হয়। যদি পার্সার কোনো ত্রুটি খুঁজে না পায়, তবে স্ক্রিপ্টটিকে বাইটকোডে কম্পাইল করা হয় এবং তারপর এটি এক্সিকিউশনের জন্য এগিয়ে যেতে পারে।

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

স্ক্রিপ্ট এবং যে কাজগুলো সেগুলোর মূল্যায়ন করে তাদের মধ্যে সম্পর্ক

স্ক্রিপ্ট ইভ্যালুয়েশনের জন্য দায়ী টাস্কগুলো কীভাবে শুরু হবে তা নির্ভর করে আপনি যে স্ক্রিপ্টটি লোড করছেন সেটি একটি সাধারণ <script> এলিমেন্ট দিয়ে লোড করা হয়েছে, নাকি type=module দিয়ে লোড করা একটি মডিউল। যেহেতু ব্রাউজারগুলো ভিন্নভাবে বিষয়গুলো পরিচালনা করার প্রবণতা দেখায়, তাই প্রধান ব্রাউজার ইঞ্জিনগুলো কীভাবে স্ক্রিপ্ট ইভ্যালুয়েশন পরিচালনা করে, তা আলোচনা করা হবে যেখানে তাদের মধ্যে স্ক্রিপ্ট ইভ্যালুয়েশনের আচরণে ভিন্নতা দেখা যায়।

<script> এলিমেন্ট দিয়ে লোড করা স্ক্রিপ্টগুলো

স্ক্রিপ্ট মূল্যায়নের জন্য প্রেরিত টাস্কের সংখ্যা সাধারণত একটি পৃষ্ঠায় থাকা <script> এলিমেন্টের সংখ্যার সাথে সরাসরি সম্পর্কিত। প্রতিটি <script> এলিমেন্ট অনুরোধ করা স্ক্রিপ্টটি মূল্যায়নের জন্য একটি টাস্ক শুরু করে, যাতে এটিকে পার্স, কম্পাইল এবং এক্সিকিউট করা যায়। ক্রোমিয়াম-ভিত্তিক ব্রাউজার সাফারি এবং ফায়ারফক্সের ক্ষেত্রে এটি প্রযোজ্য।

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

আপনি জাভাস্ক্রিপ্টের বড় অংশ লোড করা এড়িয়ে এবং অতিরিক্ত <script> এলিমেন্ট ব্যবহার করে আরও স্বতন্ত্র ও ছোট ছোট স্ক্রিপ্ট লোড করার মাধ্যমে স্ক্রিপ্ট মূল্যায়নের কাজকে ভাগ করে নিতে পারেন।

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

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

<script> এলিমেন্ট এবং type=module অ্যাট্রিবিউট দিয়ে লোড করা স্ক্রিপ্ট।

এখন <script> এলিমেন্টে type=module অ্যাট্রিবিউট ব্যবহার করে ব্রাউজারে সরাসরি ES মডিউল লোড করা সম্ভব। স্ক্রিপ্ট লোড করার এই পদ্ধতির কিছু ডেভেলপার-অভিজ্ঞতার সুবিধা রয়েছে, যেমন প্রোডাকশন ব্যবহারের জন্য কোড রূপান্তর করার প্রয়োজন হয় না—বিশেষ করে যখন এটি import maps-এর সাথে একত্রে ব্যবহার করা হয়। তবে, এইভাবে স্ক্রিপ্ট লোড করলে যে টাস্কগুলোর শিডিউল হয়, তা ব্রাউজারভেদে ভিন্ন হয়।

ক্রোমিয়াম-ভিত্তিক ব্রাউজার

ক্রোম বা এর থেকে উদ্ভূত ব্রাউজারগুলিতে, type=module অ্যাট্রিবিউট ব্যবহার করে ES মডিউল লোড করলে এমন কিছু ভিন্ন ধরনের কাজ সম্পন্ন হয়, যা সাধারণত type=module ব্যবহার না করলে দেখা যায় না। উদাহরণস্বরূপ, প্রতিটি মডিউল স্ক্রিপ্টের জন্য একটি টাস্ক রান হবে, যার মধ্যে 'Compile module' লেবেলযুক্ত কার্যকলাপ অন্তর্ভুক্ত থাকবে।

মডিউলগুলো একবার কম্পাইল হয়ে গেলে, পরবর্তীতে সেগুলোর মধ্যে রান করা যেকোনো কোড 'Evaluate module' নামক একটি অ্যাক্টিভিটি চালু করবে।

এর ফলে—অন্তত ক্রোম এবং এর সাথে সম্পর্কিত ব্রাউজারগুলোতে—ES মডিউল ব্যবহার করলে কম্পাইলেশনের ধাপগুলো বিভক্ত হয়ে যায়। দীর্ঘ কাজগুলো পরিচালনার ক্ষেত্রে এটি একটি সুস্পষ্ট সুবিধা; তবে, এর ফলে যে মডিউল ইভ্যালুয়েশনের কাজ করতে হয়, তার জন্য আপনাকে কিছু অনিবার্য খরচ বহন করতে হয়। যদিও আপনার যথাসম্ভব কম জাভাস্ক্রিপ্ট ব্যবহার করার চেষ্টা করা উচিত, ব্রাউজার নির্বিশেষে ES মডিউল ব্যবহার করলে নিম্নলিখিত সুবিধাগুলো পাওয়া যায়:

• সমস্ত মডিউল কোড স্বয়ংক্রিয়ভাবে স্ট্রিক্ট মোডে রান হয়, যা জাভাস্ক্রিপ্ট ইঞ্জিনগুলোকে এমন সব অপটিমাইজেশনের সুযোগ করে দেয় যা অন্যথায় নন-স্ট্রিক্ট প্রেক্ষাপটে করা সম্ভব হতো না।
• type=module ব্যবহার করে লোড করা স্ক্রিপ্টগুলোকে ডিফল্টরূপে ডিফার্ড হিসেবে গণ্য করা হয়। type=module দিয়ে লোড করা স্ক্রিপ্টগুলোতে ` async অ্যাট্রিবিউট ব্যবহার করে এই আচরণ পরিবর্তন করা সম্ভব।

সাফারি এবং ফায়ারফক্স

সাফারি এবং ফায়ারফক্সে যখন মডিউল লোড করা হয়, তখন সেগুলোর প্রত্যেকটি একটি পৃথক টাস্কে মূল্যায়ন করা হয়। এর মানে হলো, আপনি তাত্ত্বিকভাবে অন্যান্য মডিউলের জন্য শুধুমাত্র স্ট্যাটিক import স্টেটমেন্ট সম্বলিত একটি একক টপ-লেভেল মডিউল লোড করতে পারেন, এবং লোড হওয়া প্রতিটি মডিউলের মূল্যায়নের জন্য একটি পৃথক নেটওয়ার্ক রিকোয়েস্ট ও টাস্ক তৈরি হবে।

ডাইনামিক import() দিয়ে লোড করা স্ক্রিপ্ট

ডাইনামিক import() হলো স্ক্রিপ্ট লোড করার আরেকটি পদ্ধতি। স্ট্যাটিক import স্টেটমেন্টের মতো নয়, যা একটি ES মডিউলের একেবারে শুরুতে থাকা আবশ্যক, একটি ডাইনামিক import() কল স্ক্রিপ্টের যেকোনো জায়গায় থাকতে পারে এবং প্রয়োজন অনুযায়ী জাভাস্ক্রিপ্টের একটি অংশ লোড করতে পারে। এই কৌশলটিকে কোড স্প্লিটিং বলা হয়।

INP উন্নত করার ক্ষেত্রে Dynamic import() দুটি সুবিধা রয়েছে:

1. যে মডিউলগুলো পরে লোড হওয়ার জন্য স্থগিত রাখা হয়, সেগুলো স্টার্টআপের সময় লোড হওয়া জাভাস্ক্রিপ্টের পরিমাণ কমিয়ে মেইন থ্রেডের ওপর চাপ কমায়। এর ফলে মেইন থ্রেড মুক্ত থাকে এবং ব্যবহারকারীর ইন্টারঅ্যাকশনের প্রতি আরও বেশি সাড়া দিতে পারে।
2. যখন ডাইনামিক import() কল করা হয়, তখন প্রতিটি কল কার্যকরভাবে প্রতিটি মডিউলের কম্পাইলেশন এবং ইভ্যালুয়েশনকে তার নিজস্ব টাস্কে আলাদা করে দেয়। অবশ্যই, একটি ডাইনামিক import() যা একটি খুব বড় মডিউল লোড করে, তা একটি বেশ বড় স্ক্রিপ্ট ইভ্যালুয়েশন টাস্ক শুরু করে দেয়, এবং যদি ইন্টারঅ্যাকশনটি ডাইনামিক import() কলের সাথে একই সময়ে ঘটে, তবে এটি ব্যবহারকারীর ইনপুটে সাড়া দেওয়ার জন্য মেইন থ্রেডের ক্ষমতাকে ব্যাহত করতে পারে। অতএব, যতটা সম্ভব কম জাভাস্ক্রিপ্ট লোড করা এখনও খুব গুরুত্বপূর্ণ।

সকল প্রধান ব্রাউজার ইঞ্জিনে ডাইনামিক import() কলগুলো একইভাবে কাজ করে: এর ফলে যে স্ক্রিপ্ট ইভ্যালুয়েশন টাস্ক সম্পন্ন হয়, তা ডাইনামিকভাবে ইম্পোর্ট করা মডিউলের সংখ্যার সমান হবে।

ওয়েব ওয়ার্কারে লোড করা স্ক্রিপ্ট

ওয়েব ওয়ার্কার হলো জাভাস্ক্রিপ্টের একটি বিশেষ ব্যবহার। ওয়েব ওয়ার্কার মেইন থ্রেডে রেজিস্টার করা হয় এবং ওয়ার্কারের ভেতরের কোড তখন তার নিজস্ব থ্রেডে চলে। এটি এই অর্থে অত্যন্ত সুবিধাজনক যে—ওয়েব ওয়ার্কার রেজিস্টার করার কোডটি মেইন থ্রেডে চললেও, এর ভেতরের কোডটি চলে না। এটি মেইন থ্রেডের ভিড় কমায় এবং ব্যবহারকারীর কার্যকলাপের প্রতি মেইন থ্রেডকে আরও বেশি সক্রিয় রাখতে সাহায্য করে।

মেইন থ্রেডের কাজ কমানোর পাশাপাশি, ওয়েব ওয়ার্কাররা নিজেরাও ওয়ার্কার কনটেক্সটে ব্যবহারের জন্য এক্সটার্নাল স্ক্রিপ্ট লোড করতে পারে। এটি করা যায় importScripts মাধ্যমে অথবা মডিউল ওয়ার্কার সমর্থনকারী ব্রাউজারগুলিতে স্ট্যাটিক import স্টেটমেন্ট ব্যবহার করে। এর ফলে, ওয়েব ওয়ার্কারের অনুরোধ করা যেকোনো স্ক্রিপ্ট মেইন থ্রেডের বাইরে মূল্যায়ন করা হয়।

বিনিময় এবং বিবেচ্য বিষয়

কম সংখ্যক বড় ফাইল লোড করার পরিবর্তে আপনার স্ক্রিপ্টগুলোকে আলাদা ছোট ছোট ফাইলে ভাগ করলে দীর্ঘ কাজ সীমিত করতে সাহায্য হলেও, স্ক্রিপ্টগুলো কীভাবে ভাগ করবেন সেই সিদ্ধান্ত নেওয়ার সময় কিছু বিষয় বিবেচনা করা গুরুত্বপূর্ণ।

সংকোচন দক্ষতা

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

আপনার ওয়েবসাইট যে স্ক্রিপ্টগুলোর ওপর নির্ভরশীল, সেগুলোর আউটপুট সাইজ ব্যবস্থাপনার জন্য বান্ডলার একটি আদর্শ টুল।

• ওয়েবপ্যাকের ক্ষেত্রে, এর SplitChunksPlugin প্লাগইনটি সাহায্য করতে পারে। অ্যাসেটের আকার ব্যবস্থাপনার জন্য আপনি যে অপশনগুলো সেট করতে পারেন, সেগুলোর জন্য SplitChunksPlugin ডকুমেন্টেশন দেখুন।
• Rollup এবং esbuild-এর মতো অন্যান্য বান্ডলারের ক্ষেত্রে, আপনি আপনার কোডে ডাইনামিক import() কল ব্যবহার করে স্ক্রিপ্ট ফাইলের আকার নিয়ন্ত্রণ করতে পারেন। এই বান্ডলারগুলো—এবং সেই সাথে webpack-ও—স্বয়ংক্রিয়ভাবে ডাইনামিকভাবে ইম্পোর্ট করা অ্যাসেটটিকে তার নিজস্ব ফাইলে আলাদা করে ফেলে, যার ফলে প্রাথমিক বান্ডলের আকার বড় হওয়া এড়ানো যায়।

ক্যাশে অবৈধকরণ

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

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

নেস্টেড মডিউল এবং লোডিং পারফরম্যান্স

আপনি যদি প্রোডাকশনে ES মডিউল শিপিং করেন এবং সেগুলোকে type=module অ্যাট্রিবিউট দিয়ে লোড করেন, তাহলে মডিউল নেস্টিং কীভাবে স্টার্টআপ টাইমকে প্রভাবিত করতে পারে সে সম্পর্কে আপনাকে সচেতন থাকতে হবে। মডিউল নেস্টিং বলতে বোঝায় যখন একটি ES মডিউল স্ট্যাটিক্যালি অন্য একটি ES মডিউলকে ইম্পোর্ট করে, যা আবার স্ট্যাটিক্যালি অন্য একটি ES মডিউলকে ইম্পোর্ট করে:

// a.js
import {b} from './b.js';

// b.js
import {c} from './c.js';

যদি আপনার ES মডিউলগুলো একসাথে বান্ডল করা না থাকে, তাহলে পূর্ববর্তী কোডটির ফলে একটি নেটওয়ার্ক রিকোয়েস্ট চেইন তৈরি হয়: যখন একটি <script> এলিমেন্ট থেকে a.js জন্য রিকোয়েস্ট করা হয়, তখন b.js এর জন্য আরেকটি নেটওয়ার্ক রিকোয়েস্ট পাঠানো হয়, যার ফলে c.js এর জন্য আরও একটি রিকোয়েস্ট পাঠানো হয়। এটি এড়ানোর একটি উপায় হলো বান্ডলার ব্যবহার করা—তবে নিশ্চিত হয়ে নেবেন যে আপনি আপনার বান্ডলারটিকে এমনভাবে কনফিগার করেছেন যাতে স্ক্রিপ্টগুলোকে ভেঙে স্ক্রিপ্ট ইভ্যালুয়েশনের কাজ ভাগ করে দেওয়া যায়।

আপনি যদি বান্ডলার ব্যবহার করতে না চান, তাহলে নেস্টেড মডিউল কল এড়ানোর আরেকটি উপায় হলো modulepreload রিসোর্স হিন্ট ব্যবহার করা, যা নেটওয়ার্ক রিকোয়েস্ট চেইন এড়ানোর জন্য আগে থেকেই ES মডিউলগুলো প্রি-লোড করে রাখবে।

উপসংহার

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

সংক্ষেপে বলতে গেলে, বড় স্ক্রিপ্ট মূল্যায়ন কাজগুলোকে ছোট ছোট অংশে ভাগ করার জন্য আপনি কিছু উপায় অবলম্বন করতে পারেন:

• type=module অ্যাট্রিবিউট ছাড়া <script> এলিমেন্ট ব্যবহার করে স্ক্রিপ্ট লোড করার সময়, খুব বড় স্ক্রিপ্ট লোড করা থেকে বিরত থাকুন, কারণ এগুলো রিসোর্স-ইনটেনসিভ স্ক্রিপ্ট ইভ্যালুয়েশন টাস্ক শুরু করে যা মেইন থ্রেডকে ব্লক করে দেয়। এই কাজটি ভাগ করে দেওয়ার জন্য আপনার স্ক্রিপ্টগুলোকে একাধিক <script> এলিমেন্টে ছড়িয়ে দিন।
• ব্রাউজারে নেটিভভাবে ES মডিউল লোড করার জন্য type=module অ্যাট্রিবিউট ব্যবহার করলে, প্রতিটি আলাদা মডিউল স্ক্রিপ্টের জন্য মূল্যায়নের স্বতন্ত্র কাজ শুরু হবে।
• ডাইনামিক import() কল ব্যবহার করে আপনার প্রাথমিক বান্ডেলের আকার হ্রাস করুন। এটি বান্ডলারের ক্ষেত্রেও কাজ করে, কারণ বান্ডলার প্রতিটি ডাইনামিকভাবে ইম্পোর্ট করা মডিউলকে একটি 'স্প্লিট পয়েন্ট' হিসেবে বিবেচনা করে, যার ফলে প্রতিটি ডাইনামিকভাবে ইম্পোর্ট করা মডিউলের জন্য একটি পৃথক স্ক্রিপ্ট তৈরি হয়।
• কম্প্রেশন দক্ষতা এবং ক্যাশ ইনভ্যালিডেশনের মতো বিষয়গুলোর সুবিধা-অসুবিধা অবশ্যই বিবেচনা করুন। বড় স্ক্রিপ্টগুলো ভালোভাবে কম্প্রেস হয়, কিন্তু সেগুলোতে কম সংখ্যক টাস্কের মধ্যে আরও ব্যয়বহুল স্ক্রিপ্ট ইভ্যালুয়েশনের কাজ জড়িত থাকার সম্ভাবনা বেশি থাকে, যার ফলে ব্রাউজার ক্যাশ ইনভ্যালিডেশন ঘটে এবং সার্বিকভাবে ক্যাশিং দক্ষতা কমে যায়।
• বান্ডলিং ছাড়াই সরাসরি ES মডিউল ব্যবহার করলে, স্টার্টআপের সময় সেগুলোর লোডিং অপ্টিমাইজ করতে modulepreload রিসোর্স হিন্টটি ব্যবহার করুন।
• বরাবরের মতোই, যতটা সম্ভব কম জাভাস্ক্রিপ্ট অন্তর্ভুক্ত করুন।

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