এইচটিএমএল এবং ইন্টারঅ্যাক্টিভিটির ক্লায়েন্ট-সাইড রেন্ডারিং

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

Jeremy Wagner

HTML এর পার্সিং এবং রেন্ডারিং এমন কিছু যা ব্রাউজারগুলি ডিফল্টভাবে এমন ওয়েবসাইটগুলির জন্য খুব ভাল করে যা ব্রাউজারের অন্তর্নির্মিত নেভিগেশন লজিক ব্যবহার করে—কখনও কখনও "প্রথাগত পৃষ্ঠা লোড" বা "হার্ড নেভিগেশন" বলা হয়। এই ধরনের ওয়েবসাইটগুলিকে কখনও কখনও মাল্টি-পেজ অ্যাপ্লিকেশন (এমপিএ) বলা হয়।

যাইহোক, ডেভেলপাররা তাদের অ্যাপ্লিকেশনের প্রয়োজন অনুসারে ব্রাউজার ডিফল্টের কাছাকাছি কাজ করতে পারে। এটি অবশ্যই একক পৃষ্ঠা অ্যাপ্লিকেশন (SPA) প্যাটার্ন ব্যবহার করে ওয়েবসাইটগুলির ক্ষেত্রে, যা জাভাস্ক্রিপ্ট সহ ক্লায়েন্টে গতিশীলভাবে HTML/DOM-এর বড় অংশ তৈরি করে৷ ক্লায়েন্ট-সাইড রেন্ডারিং এই ডিজাইন প্যাটার্নের নাম, এবং এটি আপনার ওয়েবসাইটের ইন্টারঅ্যাকশন টু নেক্সট পেইন্ট (INP) এর উপর প্রভাব ফেলতে পারে যদি জড়িত কাজটি অতিরিক্ত হয়।

এই নির্দেশিকা আপনাকে সার্ভারের দ্বারা ব্রাউজারে পাঠানো HTML ব্যবহার বনাম জাভাস্ক্রিপ্ট দিয়ে ক্লায়েন্টে তৈরি করার মধ্যে পার্থক্য এবং পরবর্তীটি কীভাবে গুরুত্বপূর্ণ মুহুর্তে উচ্চ মিথস্ক্রিয়া বিলম্বিত হতে পারে তা বোঝাতে সহায়তা করবে।

কিভাবে ব্রাউজার সার্ভার দ্বারা প্রদত্ত HTML রেন্ডার করে

ঐতিহ্যগত পৃষ্ঠা লোডগুলিতে ব্যবহৃত নেভিগেশন প্যাটার্ন প্রতিটি নেভিগেশনে সার্ভার থেকে এইচটিএমএল গ্রহণ করে। আপনি যদি আপনার ব্রাউজারের ঠিকানা বারে একটি URL প্রবেশ করেন বা একটি MPA-এর একটি লিঙ্কে ক্লিক করেন, নিম্নলিখিত ঘটনাগুলির সিরিজ ঘটে:

1. ব্রাউজার প্রদত্ত URL এর জন্য একটি নেভিগেশন অনুরোধ পাঠায়।
2. সার্ভারটি খণ্ডে HTML দিয়ে প্রতিক্রিয়া জানায়।

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

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

টেকঅ্যাওয়ে? আপনি যখন সার্ভার থেকে এইচটিএমএল স্ট্রিম করেন, তখন আপনি এইচটিএমএল এর ক্রমবর্ধমান পার্সিং এবং রেন্ডারিং এবং মূল থ্রেডে স্বয়ংক্রিয় ফলন বিনামূল্যে পান। আপনি ক্লায়েন্ট-সাইড রেন্ডারিংয়ের সাথে এটি পান না।

কিভাবে ব্রাউজার জাভাস্ক্রিপ্ট দ্বারা প্রদত্ত HTML রেন্ডার করে

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

ক্লায়েন্ট-সাইড রেন্ডারিং আরও সীমিত ক্ষেত্রে নন-এসপিএ-তেও ঘটতে পারে যেখানে জাভাস্ক্রিপ্টের মাধ্যমে এইচটিএমএল গতিশীলভাবে DOM-এ যোগ করা হয়।

জাভাস্ক্রিপ্টের মাধ্যমে এইচটিএমএল তৈরি বা DOM-এ যোগ করার কয়েকটি সাধারণ উপায় রয়েছে:

1. innerHTML বৈশিষ্ট্য আপনাকে একটি স্ট্রিংয়ের মাধ্যমে বিদ্যমান উপাদানের উপর সামগ্রী সেট করতে দেয়, যা ব্রাউজারটি DOM-এ পার্স করে।
2. document.createElement পদ্ধতি আপনাকে কোনো ব্রাউজার HTML পার্সিং ব্যবহার না করে DOM-এ যোগ করার জন্য নতুন উপাদান তৈরি করতে দেয়।
3. document.write পদ্ধতি আপনাকে ডকুমেন্টে HTML লিখতে দেয় (এবং ব্রাউজার এটিকে পার্স করে, ঠিক যেমন পদ্ধতি #1)। অনেক কারণে , যাইহোক, document.write ব্যবহার দৃঢ়ভাবে নিরুৎসাহিত করা হয়।

ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্টের মাধ্যমে HTML/DOM তৈরির ফলাফলগুলি উল্লেখযোগ্য হতে পারে:

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

ক্লায়েন্ট-সাইড রেন্ডারিংয়ের কর্মক্ষমতা প্রভাব সম্পর্কে আপনি কী করতে পারেন

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

কারণ যাই হোক না কেন, এখানে কিছু সম্ভাব্য কারণ রয়েছে যেগুলিকে আপনি ট্র্যাকে ফিরিয়ে আনতে সাহায্য করতে পারেন।

সার্ভার থেকে যতটা সম্ভব HTML প্রদান করুন

পূর্বে উল্লিখিত হিসাবে, ব্রাউজারটি ডিফল্টরূপে একটি খুব পারফরম্যান্স উপায়ে সার্ভার থেকে HTML পরিচালনা করে। এটি HTML এর পার্সিং এবং রেন্ডারিংকে এমনভাবে ভেঙে দেবে যা দীর্ঘ কাজ এড়িয়ে যায় এবং মোট মূল থ্রেড সময়ের পরিমাণকে অপ্টিমাইজ করে। এটি একটি কম টোটাল ব্লকিং টাইম (TBT) বাড়ে, এবং TBT দৃঢ়ভাবে INP এর সাথে সম্পর্কযুক্ত ।

আপনি আপনার ওয়েবসাইট তৈরি করতে ফ্রন্টএন্ড ফ্রেমওয়ার্কের উপর নির্ভর করতে পারেন। যদি তাই হয়, আপনি নিশ্চিত করতে চাইবেন যে আপনি সার্ভারে কম্পোনেন্ট HTML রেন্ডার করছেন। এটি আপনার ওয়েবসাইটের প্রাথমিক ক্লায়েন্ট-সাইড রেন্ডারিংয়ের পরিমাণ সীমিত করবে এবং এর ফলে আরও ভাল অভিজ্ঞতা পাওয়া উচিত।

• প্রতিক্রিয়ার জন্য, আপনি সার্ভারে HTML রেন্ডার করতে সার্ভার DOM API ব্যবহার করতে চাইবেন। কিন্তু সচেতন থাকুন: সার্ভার-সাইড রেন্ডারিং-এর ঐতিহ্যগত পদ্ধতি একটি সিঙ্ক্রোনাস পদ্ধতি ব্যবহার করে, যা ফার্স্ট কনটেন্টফুল পেইন্ট (FCP) এবং LCP-এর মতো পরবর্তী মেট্রিকগুলির জন্য দীর্ঘ সময় হতে পারে (TTFB) । যেখানে সম্ভব, নিশ্চিত করুন যে আপনি Node.js বা অন্যান্য JavaScript রানটাইমের জন্য স্ট্রিমিং API ব্যবহার করছেন যাতে সার্ভার যত তাড়াতাড়ি সম্ভব ব্রাউজারে HTML স্ট্রিমিং শুরু করতে পারে। Next.js—একটি প্রতিক্রিয়া-ভিত্তিক কাঠামো—ডিফল্টরূপে অনেক সেরা অনুশীলন প্রদান করে। সার্ভারে স্বয়ংক্রিয়ভাবে এইচটিএমএল রেন্ডার করার পাশাপাশি, এটি এমন পৃষ্ঠাগুলির জন্য স্ট্যাটিকভাবে এইচটিএমএল তৈরি করতে পারে যা ব্যবহারকারীর প্রসঙ্গের (যেমন প্রমাণীকরণ) উপর ভিত্তি করে পরিবর্তন হয় না।
• Vue ডিফল্টরূপে ক্লায়েন্ট-সাইড রেন্ডারিংও করে। যাইহোক, React এর মত, Vue সার্ভারে আপনার কম্পোনেন্ট HTML রেন্ডার করতে পারে। হয় এই সার্ভার-সাইড APIগুলির সুবিধা নিন যেখানে সম্ভব, বা আপনার Vue প্রকল্পের জন্য একটি উচ্চ-স্তরের বিমূর্ততা বিবেচনা করুন যাতে সর্বোত্তম অনুশীলনগুলি বাস্তবায়ন করা সহজ হয়৷
• Svelte ডিফল্টরূপে সার্ভারে HTML রেন্ডার করে —যদিও আপনার কম্পোনেন্ট কোডের ব্রাউজার-এক্সক্লুসিভ নেমস্পেসগুলিতে অ্যাক্সেসের প্রয়োজন হলে (উদাহরণস্বরূপ window ), আপনি সার্ভারে সেই উপাদানটির HTML রেন্ডার করতে পারবেন না। যেখানেই সম্ভব বিকল্প পন্থা অন্বেষণ করুন যাতে আপনি অপ্রয়োজনীয় ক্লায়েন্ট-সাইড রেন্ডারিং ঘটাচ্ছেন না। SvelteKit— যা Svelte-এর জন্য Next.js হল প্রতিক্রিয়া দেখানো—আপনার Svelte প্রোজেক্টগুলিতে যতটা সম্ভব সেরা অনুশীলনগুলি এম্বেড করে, যাতে আপনি শুধুমাত্র Svelte ব্যবহার করে এমন প্রজেক্টগুলিতে সম্ভাব্য ত্রুটিগুলি এড়াতে পারেন।

ক্লায়েন্টে তৈরি DOM নোডের পরিমাণ সীমিত করুন

যখন DOMগুলি বড় হয়, তখন সেগুলিকে রেন্ডার করার জন্য প্রয়োজনীয় প্রক্রিয়াকরণ বাড়তে থাকে। আপনার ওয়েবসাইট একটি পূর্ণাঙ্গ SPA হোক বা MPA-এর জন্য মিথস্ক্রিয়ার ফলে বিদ্যমান DOM-এ নতুন নোড ইনজেকশন করা হোক না কেন, সেই DOMগুলিকে যতটা সম্ভব ছোট রাখার কথা বিবেচনা করুন৷ এটি সেই HTML প্রদর্শনের জন্য ক্লায়েন্ট-সাইড রেন্ডারিংয়ের সময় প্রয়োজনীয় কাজ কমাতে সাহায্য করবে, আশা করি আপনার ওয়েবসাইটের INP কম রাখতে সাহায্য করবে।

একটি স্ট্রিমিং পরিষেবা কর্মী আর্কিটেকচার বিবেচনা করুন

এটি একটি উন্নত কৌশল—যেটি প্রতিটি ব্যবহারের ক্ষেত্রে সহজে কাজ নাও করতে পারে—কিন্তু এটি এমন একটি যা আপনার MPA-কে এমন একটি ওয়েবসাইটে পরিণত করতে পারে যা ব্যবহারকারীদের এক পৃষ্ঠা থেকে অন্য পৃষ্ঠায় নেভিগেট করার সময় তা সঙ্গে সঙ্গে লোড হচ্ছে বলে মনে হয়৷ সার্ভার থেকে একটি পৃষ্ঠার বাকি এইচটিএমএল আনতে ReadableStream API ব্যবহার করার সময় আপনি CacheStorage এ আপনার ওয়েবসাইটের স্ট্যাটিক অংশগুলি প্রিক্যাশে করার জন্য একজন পরিষেবা কর্মী ব্যবহার করতে পারেন।

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

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

উপসংহার

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

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

আপনি যদি আপনার ওয়েবসাইটের ক্লায়েন্ট-সাইড রেন্ডারিং যতটা সম্ভব ন্যূনতম করতে পারেন, আপনি কেবল আপনার ওয়েবসাইটের INP নয়, অন্যান্য মেট্রিক যেমন LCP, TBT এবং সম্ভবত কিছু ক্ষেত্রে আপনার TTFBও উন্নত করবেন।

আনস্প্ল্যাশ থেকে হিরো ইমেজ, মাইক জোনিৎজ দ্বারা।

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

Jeremy Wagner

HTML এর পার্সিং এবং রেন্ডারিং এমন কিছু যা ব্রাউজারগুলি ডিফল্টভাবে এমন ওয়েবসাইটগুলির জন্য খুব ভাল করে যা ব্রাউজারের অন্তর্নির্মিত নেভিগেশন লজিক ব্যবহার করে—কখনও কখনও "প্রথাগত পৃষ্ঠা লোড" বা "হার্ড নেভিগেশন" বলা হয়। এই ধরনের ওয়েবসাইটগুলিকে কখনও কখনও মাল্টি-পেজ অ্যাপ্লিকেশন (এমপিএ) বলা হয়।

যাইহোক, ডেভেলপাররা তাদের অ্যাপ্লিকেশনের প্রয়োজন অনুসারে ব্রাউজার ডিফল্টের কাছাকাছি কাজ করতে পারে। এটি অবশ্যই একক পৃষ্ঠা অ্যাপ্লিকেশন (SPA) প্যাটার্ন ব্যবহার করে ওয়েবসাইটগুলির ক্ষেত্রে, যা জাভাস্ক্রিপ্ট সহ ক্লায়েন্টে গতিশীলভাবে HTML/DOM-এর বড় অংশ তৈরি করে৷ ক্লায়েন্ট-সাইড রেন্ডারিং এই ডিজাইন প্যাটার্নের নাম, এবং এটি আপনার ওয়েবসাইটের ইন্টারঅ্যাকশন টু নেক্সট পেইন্ট (INP) এর উপর প্রভাব ফেলতে পারে যদি জড়িত কাজটি অতিরিক্ত হয়।

এই নির্দেশিকা আপনাকে সার্ভারের দ্বারা ব্রাউজারে পাঠানো HTML ব্যবহার বনাম জাভাস্ক্রিপ্ট দিয়ে ক্লায়েন্টে তৈরি করার মধ্যে পার্থক্য এবং পরবর্তীটি কীভাবে গুরুত্বপূর্ণ মুহুর্তে উচ্চ মিথস্ক্রিয়া বিলম্বিত হতে পারে তা বোঝাতে সহায়তা করবে।

কিভাবে ব্রাউজার সার্ভার দ্বারা প্রদত্ত HTML রেন্ডার করে

ঐতিহ্যগত পৃষ্ঠা লোডগুলিতে ব্যবহৃত নেভিগেশন প্যাটার্ন প্রতিটি নেভিগেশনে সার্ভার থেকে এইচটিএমএল গ্রহণ করে। আপনি যদি আপনার ব্রাউজারের ঠিকানা বারে একটি URL প্রবেশ করেন বা একটি MPA-এর একটি লিঙ্কে ক্লিক করেন, নিম্নলিখিত ঘটনাগুলির সিরিজ ঘটে:

1. ব্রাউজার প্রদত্ত URL এর জন্য একটি নেভিগেশন অনুরোধ পাঠায়।
2. সার্ভারটি খণ্ডে HTML দিয়ে প্রতিক্রিয়া জানায়।

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

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

টেকঅ্যাওয়ে? আপনি যখন সার্ভার থেকে এইচটিএমএল স্ট্রিম করেন, তখন আপনি এইচটিএমএল এর ক্রমবর্ধমান পার্সিং এবং রেন্ডারিং এবং মূল থ্রেডে স্বয়ংক্রিয় ফলন বিনামূল্যে পান। আপনি ক্লায়েন্ট-সাইড রেন্ডারিংয়ের সাথে এটি পান না।

কিভাবে ব্রাউজার জাভাস্ক্রিপ্ট দ্বারা প্রদত্ত HTML রেন্ডার করে

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

ক্লায়েন্ট-সাইড রেন্ডারিং আরও সীমিত ক্ষেত্রে নন-এসপিএ-তেও ঘটতে পারে যেখানে জাভাস্ক্রিপ্টের মাধ্যমে এইচটিএমএল গতিশীলভাবে DOM-এ যোগ করা হয়।

জাভাস্ক্রিপ্টের মাধ্যমে এইচটিএমএল তৈরি বা DOM-এ যোগ করার কয়েকটি সাধারণ উপায় রয়েছে:

1. innerHTML বৈশিষ্ট্য আপনাকে একটি স্ট্রিংয়ের মাধ্যমে বিদ্যমান উপাদানের উপর সামগ্রী সেট করতে দেয়, যা ব্রাউজারটি DOM-এ পার্স করে।
2. document.createElement পদ্ধতি আপনাকে কোনো ব্রাউজার HTML পার্সিং ব্যবহার না করে DOM-এ যোগ করার জন্য নতুন উপাদান তৈরি করতে দেয়।
3. document.write পদ্ধতি আপনাকে ডকুমেন্টে HTML লিখতে দেয় (এবং ব্রাউজার এটিকে পার্স করে, ঠিক যেমন পদ্ধতি #1)। অনেক কারণে , যাইহোক, document.write ব্যবহার দৃঢ়ভাবে নিরুৎসাহিত করা হয়।

ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্টের মাধ্যমে HTML/DOM তৈরির ফলাফলগুলি উল্লেখযোগ্য হতে পারে:

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

ক্লায়েন্ট-সাইড রেন্ডারিংয়ের কর্মক্ষমতা প্রভাব সম্পর্কে আপনি কী করতে পারেন

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

কারণ যাই হোক না কেন, এখানে কিছু সম্ভাব্য কারণ রয়েছে যেগুলিকে আপনি ট্র্যাকে ফিরিয়ে আনতে সাহায্য করতে পারেন।

সার্ভার থেকে যতটা সম্ভব HTML প্রদান করুন

পূর্বে উল্লিখিত হিসাবে, ব্রাউজারটি ডিফল্টরূপে একটি খুব পারফরম্যান্স উপায়ে সার্ভার থেকে HTML পরিচালনা করে। এটি HTML এর পার্সিং এবং রেন্ডারিংকে এমনভাবে ভেঙে দেবে যা দীর্ঘ কাজ এড়িয়ে যায় এবং মোট মূল থ্রেড সময়ের পরিমাণকে অপ্টিমাইজ করে। এটি একটি কম টোটাল ব্লকিং টাইম (TBT) বাড়ে, এবং TBT দৃঢ়ভাবে INP এর সাথে সম্পর্কযুক্ত ।

আপনি আপনার ওয়েবসাইট তৈরি করতে ফ্রন্টএন্ড ফ্রেমওয়ার্কের উপর নির্ভর করতে পারেন। যদি তাই হয়, আপনি নিশ্চিত করতে চাইবেন যে আপনি সার্ভারে কম্পোনেন্ট HTML রেন্ডার করছেন। এটি আপনার ওয়েবসাইটের প্রাথমিক ক্লায়েন্ট-সাইড রেন্ডারিংয়ের পরিমাণ সীমিত করবে এবং এর ফলে আরও ভাল অভিজ্ঞতা পাওয়া উচিত।

• প্রতিক্রিয়ার জন্য, আপনি সার্ভারে HTML রেন্ডার করতে সার্ভার DOM API ব্যবহার করতে চাইবেন। কিন্তু সচেতন থাকুন: সার্ভার-সাইড রেন্ডারিং-এর ঐতিহ্যগত পদ্ধতি একটি সিঙ্ক্রোনাস পদ্ধতি ব্যবহার করে, যা ফার্স্ট কনটেন্টফুল পেইন্ট (FCP) এবং LCP-এর মতো পরবর্তী মেট্রিকগুলির জন্য দীর্ঘ সময় হতে পারে (TTFB) । যেখানে সম্ভব, নিশ্চিত করুন যে আপনি Node.js বা অন্যান্য JavaScript রানটাইমের জন্য স্ট্রিমিং API ব্যবহার করছেন যাতে সার্ভার যত তাড়াতাড়ি সম্ভব ব্রাউজারে HTML স্ট্রিমিং শুরু করতে পারে। Next.js—একটি প্রতিক্রিয়া-ভিত্তিক কাঠামো—ডিফল্টরূপে অনেক সেরা অনুশীলন প্রদান করে। সার্ভারে স্বয়ংক্রিয়ভাবে এইচটিএমএল রেন্ডার করার পাশাপাশি, এটি এমন পৃষ্ঠাগুলির জন্য স্ট্যাটিকভাবে এইচটিএমএল তৈরি করতে পারে যা ব্যবহারকারীর প্রসঙ্গের (যেমন প্রমাণীকরণ) উপর ভিত্তি করে পরিবর্তন হয় না।
• Vue ডিফল্টরূপে ক্লায়েন্ট-সাইড রেন্ডারিংও করে। যাইহোক, React এর মত, Vue সার্ভারে আপনার কম্পোনেন্ট HTML রেন্ডার করতে পারে। হয় এই সার্ভার-সাইড APIগুলির সুবিধা নিন যেখানে সম্ভব, বা আপনার Vue প্রকল্পের জন্য একটি উচ্চ-স্তরের বিমূর্ততা বিবেচনা করুন যাতে সর্বোত্তম অনুশীলনগুলি বাস্তবায়ন করা সহজ হয়৷
• Svelte ডিফল্টরূপে সার্ভারে HTML রেন্ডার করে —যদিও আপনার কম্পোনেন্ট কোডের ব্রাউজার-এক্সক্লুসিভ নেমস্পেসগুলিতে অ্যাক্সেসের প্রয়োজন হলে (উদাহরণস্বরূপ window ), আপনি সার্ভারে সেই উপাদানটির HTML রেন্ডার করতে পারবেন না। যেখানেই সম্ভব বিকল্প পন্থা অন্বেষণ করুন যাতে আপনি অপ্রয়োজনীয় ক্লায়েন্ট-সাইড রেন্ডারিং ঘটাচ্ছেন না। SvelteKit— যা Svelte-এর জন্য Next.js হল প্রতিক্রিয়া দেখানো—আপনার Svelte প্রোজেক্টগুলিতে যতটা সম্ভব সেরা অনুশীলনগুলি এম্বেড করে, যাতে আপনি শুধুমাত্র Svelte ব্যবহার করে এমন প্রজেক্টগুলিতে সম্ভাব্য ত্রুটিগুলি এড়াতে পারেন।

ক্লায়েন্টে তৈরি DOM নোডের পরিমাণ সীমিত করুন

যখন DOMগুলি বড় হয়, তখন সেগুলিকে রেন্ডার করার জন্য প্রয়োজনীয় প্রক্রিয়াকরণ বাড়তে থাকে। আপনার ওয়েবসাইট একটি পূর্ণাঙ্গ SPA হোক বা MPA-এর জন্য মিথস্ক্রিয়ার ফলে বিদ্যমান DOM-এ নতুন নোড ইনজেকশন করা হোক না কেন, সেই DOMগুলিকে যতটা সম্ভব ছোট রাখার কথা বিবেচনা করুন৷ এটি সেই HTML প্রদর্শনের জন্য ক্লায়েন্ট-সাইড রেন্ডারিংয়ের সময় প্রয়োজনীয় কাজ কমাতে সাহায্য করবে, আশা করি আপনার ওয়েবসাইটের INP কম রাখতে সাহায্য করবে।

একটি স্ট্রিমিং পরিষেবা কর্মী আর্কিটেকচার বিবেচনা করুন

এটি একটি উন্নত কৌশল—যেটি প্রতিটি ব্যবহারের ক্ষেত্রে সহজে কাজ নাও করতে পারে—কিন্তু এটি এমন একটি যা আপনার MPA-কে এমন একটি ওয়েবসাইটে পরিণত করতে পারে যা ব্যবহারকারীদের এক পৃষ্ঠা থেকে অন্য পৃষ্ঠায় নেভিগেট করার সময় তা সঙ্গে সঙ্গে লোড হচ্ছে বলে মনে হয়৷ সার্ভার থেকে একটি পৃষ্ঠার বাকি এইচটিএমএল আনতে ReadableStream API ব্যবহার করার সময় আপনি CacheStorage এ আপনার ওয়েবসাইটের স্ট্যাটিক অংশগুলি প্রিক্যাশে করার জন্য একজন পরিষেবা কর্মী ব্যবহার করতে পারেন।

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

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

উপসংহার

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

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

আপনি যদি আপনার ওয়েবসাইটের ক্লায়েন্ট-সাইড রেন্ডারিং যতটা সম্ভব ন্যূনতম করতে পারেন, আপনি কেবল আপনার ওয়েবসাইটের INP নয়, অন্যান্য মেট্রিক যেমন LCP, TBT এবং সম্ভবত কিছু ক্ষেত্রে আপনার TTFBও উন্নত করবেন।

আনস্প্ল্যাশ থেকে হিরো ইমেজ, মাইক জোনিৎজ দ্বারা।

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

Jeremy Wagner

HTML এর পার্সিং এবং রেন্ডারিং এমন কিছু যা ব্রাউজারগুলি ডিফল্টভাবে এমন ওয়েবসাইটগুলির জন্য খুব ভাল করে যা ব্রাউজারের অন্তর্নির্মিত নেভিগেশন লজিক ব্যবহার করে—কখনও কখনও "প্রথাগত পৃষ্ঠা লোড" বা "হার্ড নেভিগেশন" বলা হয়। এই ধরনের ওয়েবসাইটগুলিকে কখনও কখনও মাল্টি-পেজ অ্যাপ্লিকেশন (এমপিএ) বলা হয়।

যাইহোক, ডেভেলপাররা তাদের অ্যাপ্লিকেশনের প্রয়োজন অনুসারে ব্রাউজার ডিফল্টের কাছাকাছি কাজ করতে পারে। এটি অবশ্যই একক পৃষ্ঠা অ্যাপ্লিকেশন (SPA) প্যাটার্ন ব্যবহার করে ওয়েবসাইটগুলির ক্ষেত্রে, যা জাভাস্ক্রিপ্ট সহ ক্লায়েন্টে গতিশীলভাবে HTML/DOM-এর বড় অংশ তৈরি করে৷ ক্লায়েন্ট-সাইড রেন্ডারিং এই ডিজাইন প্যাটার্নের নাম, এবং এটি আপনার ওয়েবসাইটের ইন্টারঅ্যাকশন টু নেক্সট পেইন্ট (INP) এর উপর প্রভাব ফেলতে পারে যদি জড়িত কাজটি অতিরিক্ত হয়।

এই নির্দেশিকা আপনাকে সার্ভারের দ্বারা ব্রাউজারে পাঠানো HTML ব্যবহার বনাম জাভাস্ক্রিপ্ট দিয়ে ক্লায়েন্টে তৈরি করার মধ্যে পার্থক্য এবং পরবর্তীটি কীভাবে গুরুত্বপূর্ণ মুহুর্তে উচ্চ মিথস্ক্রিয়া বিলম্বিত হতে পারে তা বোঝাতে সহায়তা করবে।

কিভাবে ব্রাউজার সার্ভার দ্বারা প্রদত্ত HTML রেন্ডার করে

ঐতিহ্যগত পৃষ্ঠা লোডগুলিতে ব্যবহৃত নেভিগেশন প্যাটার্ন প্রতিটি নেভিগেশনে সার্ভার থেকে এইচটিএমএল গ্রহণ করে। আপনি যদি আপনার ব্রাউজারের ঠিকানা বারে একটি URL প্রবেশ করেন বা একটি MPA-এর একটি লিঙ্কে ক্লিক করেন, নিম্নলিখিত ঘটনাগুলির সিরিজ ঘটে:

1. ব্রাউজার প্রদত্ত URL এর জন্য একটি নেভিগেশন অনুরোধ পাঠায়।
2. সার্ভারটি খণ্ডে HTML দিয়ে প্রতিক্রিয়া জানায়।

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

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

টেকঅ্যাওয়ে? আপনি যখন সার্ভার থেকে এইচটিএমএল স্ট্রিম করেন, তখন আপনি এইচটিএমএল এর ক্রমবর্ধমান পার্সিং এবং রেন্ডারিং এবং মূল থ্রেডে স্বয়ংক্রিয় ফলন বিনামূল্যে পান। আপনি ক্লায়েন্ট-সাইড রেন্ডারিংয়ের সাথে এটি পান না।

কিভাবে ব্রাউজার জাভাস্ক্রিপ্ট দ্বারা প্রদত্ত HTML রেন্ডার করে

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

ক্লায়েন্ট-সাইড রেন্ডারিং আরও সীমিত ক্ষেত্রে নন-এসপিএ-তেও ঘটতে পারে যেখানে জাভাস্ক্রিপ্টের মাধ্যমে এইচটিএমএল গতিশীলভাবে DOM-এ যোগ করা হয়।

জাভাস্ক্রিপ্টের মাধ্যমে এইচটিএমএল তৈরি বা DOM-এ যোগ করার কয়েকটি সাধারণ উপায় রয়েছে:

1. innerHTML বৈশিষ্ট্য আপনাকে একটি স্ট্রিংয়ের মাধ্যমে বিদ্যমান উপাদানের উপর সামগ্রী সেট করতে দেয়, যা ব্রাউজারটি DOM-এ পার্স করে।
2. document.createElement পদ্ধতি আপনাকে কোনো ব্রাউজার HTML পার্সিং ব্যবহার না করে DOM-এ যোগ করার জন্য নতুন উপাদান তৈরি করতে দেয়।
3. document.write পদ্ধতি আপনাকে ডকুমেন্টে HTML লিখতে দেয় (এবং ব্রাউজার এটিকে পার্স করে, ঠিক যেমন পদ্ধতি #1)। অনেক কারণে , যাইহোক, document.write ব্যবহার দৃঢ়ভাবে নিরুৎসাহিত করা হয়।

ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্টের মাধ্যমে HTML/DOM তৈরি করার ফলাফলগুলি উল্লেখযোগ্য হতে পারে:

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

ক্লায়েন্ট-সাইড রেন্ডারিংয়ের কর্মক্ষমতা প্রভাব সম্পর্কে আপনি কী করতে পারেন

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

কারণ যাই হোক না কেন, এখানে কিছু সম্ভাব্য কারণ রয়েছে যেগুলিকে আপনি ট্র্যাকে ফিরিয়ে আনতে সাহায্য করতে পারেন।

সার্ভার থেকে যতটা সম্ভব HTML প্রদান করুন

পূর্বে উল্লিখিত হিসাবে, ব্রাউজারটি ডিফল্টরূপে একটি খুব পারফরম্যান্স উপায়ে সার্ভার থেকে HTML পরিচালনা করে। এটি HTML এর পার্সিং এবং রেন্ডারিংকে এমনভাবে ভেঙে দেবে যা দীর্ঘ কাজ এড়িয়ে যায় এবং মোট মূল থ্রেড সময়ের পরিমাণকে অপ্টিমাইজ করে। এটি একটি কম টোটাল ব্লকিং টাইম (TBT) বাড়ে, এবং TBT দৃঢ়ভাবে INP এর সাথে সম্পর্কযুক্ত ।

আপনি আপনার ওয়েবসাইট তৈরি করতে ফ্রন্টএন্ড ফ্রেমওয়ার্কের উপর নির্ভর করতে পারেন। যদি তাই হয়, আপনি নিশ্চিত করতে চাইবেন যে আপনি সার্ভারে কম্পোনেন্ট HTML রেন্ডার করছেন। এটি আপনার ওয়েবসাইটের প্রাথমিক ক্লায়েন্ট-সাইড রেন্ডারিংয়ের পরিমাণ সীমিত করবে এবং এর ফলে আরও ভাল অভিজ্ঞতা পাওয়া উচিত।

• প্রতিক্রিয়ার জন্য, আপনি সার্ভারে HTML রেন্ডার করতে সার্ভার DOM API ব্যবহার করতে চাইবেন। কিন্তু সচেতন থাকুন: সার্ভার-সাইড রেন্ডারিং-এর ঐতিহ্যগত পদ্ধতি একটি সিঙ্ক্রোনাস পদ্ধতি ব্যবহার করে, যা ফার্স্ট কনটেন্টফুল পেইন্ট (FCP) এবং LCP-এর মতো পরবর্তী মেট্রিকগুলির জন্য দীর্ঘ সময় হতে পারে (TTFB) । যেখানে সম্ভব, নিশ্চিত করুন যে আপনি Node.js বা অন্যান্য JavaScript রানটাইমের জন্য স্ট্রিমিং API ব্যবহার করছেন যাতে সার্ভার যত তাড়াতাড়ি সম্ভব ব্রাউজারে HTML স্ট্রিমিং শুরু করতে পারে। Next.js—একটি প্রতিক্রিয়া-ভিত্তিক কাঠামো—ডিফল্টরূপে অনেক সেরা অনুশীলন প্রদান করে। সার্ভারে স্বয়ংক্রিয়ভাবে এইচটিএমএল রেন্ডারিং করার পাশাপাশি, এটি ব্যবহারকারীর প্রসঙ্গে (যেমন প্রমাণীকরণ) ভিত্তিতে পরিবর্তন হয় না এমন পৃষ্ঠাগুলির জন্য স্ট্যাটিকভাবে এইচটিএমএল তৈরি করতে পারে।
• ভ্যু ডিফল্টরূপে ক্লায়েন্ট-সাইড রেন্ডারিংও সম্পাদন করে। যাইহোক, প্রতিক্রিয়াগুলির মতো, ভ্যু আপনার উপাদানটি সার্ভারে এইচটিএমএলও রেন্ডার করতে পারে। হয় যেখানে সম্ভব এই সার্ভার-সাইড এপিআইগুলির সুবিধা নিন, বা আপনার ভিইউ প্রকল্পের জন্য সর্বোত্তম অনুশীলনগুলি কার্যকর করা সহজ করার জন্য একটি উচ্চ-স্তরের বিমূর্ততা বিবেচনা করুন।
• ডিফল্টরূপে সার্ভারে এসভেল্ট এইচটিএমএল রেন্ডার করে -যদিও আপনার উপাদান কোডের ব্রাউজার-এক্সক্লুসিভ নেমস্পেসগুলিতে অ্যাক্সেস প্রয়োজন (উদাহরণস্বরূপ window ), আপনি সার্ভারে সেই উপাদানটির এইচটিএমএল রেন্ডার করতে সক্ষম নাও হতে পারেন। যেখানেই সম্ভব বিকল্প পদ্ধতির অন্বেষণ করুন যাতে আপনি অপ্রয়োজনীয় ক্লায়েন্ট-সাইড রেন্ডারিং না করে। Sveltekit - যা পরের হিসাবে svelte হতে পারে j জেএস প্রতিক্রিয়া জানাতে হয় - আপনার স্বরেভেট প্রকল্পগুলিতে যতটা সম্ভব সেরা অনুশীলনগুলি এমবেড করে, যাতে আপনি একা স্যাভেল্ট ব্যবহার করে এমন প্রকল্পগুলিতে সম্ভাব্য সমস্যাগুলি এড়াতে পারেন।

ক্লায়েন্টে তৈরি ডিওএম নোডের পরিমাণ সীমাবদ্ধ করুন

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

একটি স্ট্রিমিং পরিষেবা কর্মী আর্কিটেকচার বিবেচনা করুন

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

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

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

উপসংহার

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

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

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

মাইক জোনিয়েটজ রচিত আনস্প্ল্যাশ থেকে হিরো ইমেজ।