প্রকাশিত: ৬ ফেব্রুয়ারি, ২০১৯, শেষবার আপডেট করা হয়েছে: ৫ জানুয়ারি, ২০২৬
ওয়েব ডেভেলপারদের অন্যতম প্রধান সিদ্ধান্ত হল, তাদের অ্যাপ্লিকেশনে কোথায় লজিক ও রেন্ডারিং প্রয়োগ করতে হবে। এটি কঠিন হতে পারে কারণ ওয়েবসাইট তৈরি করার অনেক উপায় আছে।
এই স্পেস সম্পর্কে আমাদের ধারণা গত কয়েক বছর ধরে Chrome-এ বড় সাইটের সাথে আমাদের কথোপকথনের মাধ্যমে তৈরি হয়েছে। সাধারণভাবে বলতে গেলে, আমরা ডেভেলপারদের সম্পূর্ণ রিহাইড্রেশন পদ্ধতির পরিবর্তে সার্ভার-সাইড রেন্ডারিং বা স্ট্যাটিক রেন্ডারিং বিবেচনা করতে উৎসাহিত করি।
এই সিদ্ধান্ত নেওয়ার সময় আমরা যে আর্কিটেকচার বেছে নিচ্ছি তা আরও ভালোভাবে বুঝতে, আমাদের প্রতিটি পদ্ধতির জন্য সামঞ্জস্যপূর্ণ পরিভাষা এবং একটি শেয়ার করা ফ্রেমওয়ার্ক প্রয়োজন। তারপর, আপনি পৃষ্ঠার পারফর্ম্যান্সের পরিপ্রেক্ষিতে প্রতিটি রেন্ডারিং পদ্ধতির ট্রেড-অফ আরও ভালভাবে মূল্যায়ন করতে পারবেন।
পরিভাষা
প্রথমে, আমরা ব্যবহার করব এমন কিছু পরিভাষার সংজ্ঞা দেব।
রেন্ডারিং
- সার্ভার-সাইড রেন্ডারিং (SSR)
- ক্লায়েন্টকে জাভাস্ক্রিপ্টের পরিবর্তে HTML পাঠানোর জন্য সার্ভারে অ্যাপ রেন্ডার করা।
- ক্লায়েন্ট-সাইড রেন্ডারিং (CSR)
- DOM পরিবর্তন করার জন্য জাভাস্ক্রিপ্ট ব্যবহার করে ব্রাউজারে অ্যাপ রেন্ডার করা।
- প্রি-রেন্ডারিং
- বিল্ড করার সময় ক্লায়েন্ট-সাইড অ্যাপ্লিকেশন রান করা যাতে স্ট্যাটিক HTML হিসেবে এটির প্রাথমিক অবস্থা ক্যাপচার করা যায়। মনে রাখবেন, এই অর্থে "প্রিরেন্ডারিং" হল ভবিষ্যতের নেভিগেশনের ব্রাউজার প্রিরেন্ডারিং-এর থেকে আলাদা।
- হাইড্রেশন
- সার্ভার-রেন্ডার করা HTML-এ অ্যাপ্লিকেশন স্টেট ও ইন্টার্যাক্টিভিটি যোগ করার জন্য ক্লায়েন্ট-সাইড স্ক্রিপ্ট রান করা। হাইড্রেশন ধরে নেয় যে DOM পরিবর্তন হয় না।
- রিহাইড্রেশন
- হাইড্রেশনের মতো একই জিনিস বোঝাতে প্রায়শই ব্যবহার করা হলেও, রিহাইড্রেশন বলতে বোঝায় প্রাথমিক হাইড্রেশনের পরে সহ লেটেস্ট স্ট্যাটাস সহ DOM নিয়মিত আপডেট করা।
পারফর্ম্যান্স
- Time to First Byte (TTFB)
- কোনও লিঙ্কে ক্লিক করা এবং নতুন পৃষ্ঠায় কন্টেন্টের প্রথম বাইট লোড হওয়ার মধ্যেকার সময়।
- First Contentful Paint (FCP)
- অনুরোধ করা কন্টেন্ট (আর্টিকেলের বডি ইত্যাদি) যে সময়ে দৃশ্যমান হয়।
- Interaction to Next Paint (INP)
- একটি প্রতিনিধিত্বমূলক মেট্রিক যা মূল্যায়ন করে যে কোনও পৃষ্ঠা ব্যবহারকারীর ইনপুটে ধারাবাহিকভাবে দ্রুত প্রতিক্রিয়া জানায় কিনা।
- টোটাল ব্লকিং টাইম (TBT)
- INP-এর জন্য একটি প্রক্সি মেট্রিক যা পৃষ্ঠা লোড করার সময় মূল থ্রেডটি কতক্ষণ ব্লক করা হয়েছিল তা গণনা করে।
সার্ভার-সাইড রেন্ডারিং
সার্ভার-সাইড রেন্ডারিং নেভিগেশনের উত্তরে সার্ভারে কোনও পৃষ্ঠার জন্য সম্পূর্ণ HTML জেনারেট করে। এর ফলে, ক্লায়েন্টে ডেটা ফেচ করা ও টেমপ্লেট করার জন্য অতিরিক্ত রাউন্ড ট্রিপ এড়ানো যায়, কারণ ব্রাউজার উত্তর পাওয়ার আগেই রেন্ডারার সেগুলি ম্যানেজ করে।
সার্ভার-সাইড রেন্ডারিং সাধারণত দ্রুত FCP তৈরি করে। সার্ভারে পেজ লজিক রান করা ও রেন্ডার করার ফলে, আপনাকে ক্লায়েন্টকে অনেক জাভাস্ক্রিপ্ট পাঠাতে হয় না। এটি কোনও পৃষ্ঠার TBT কমাতে সাহায্য করে, যার ফলে INP-ও কম হতে পারে, কারণ পৃষ্ঠা লোড হওয়ার সময় মূল থ্রেড প্রায়শই ব্লক হয় না। প্রধান থ্রেড কম ব্লক হলে, ব্যবহারকারীর ইন্টার্যাকশন আরও দ্রুত রান করার সুযোগ পায়।
এটি যুক্তিযুক্ত, কারণ সার্ভার-সাইড রেন্ডারিংয়ের মাধ্যমে আপনি আসলে ব্যবহারকারীর ব্রাউজারে শুধু টেক্সট ও লিঙ্ক পাঠান। এই পদ্ধতি বিভিন্ন ডিভাইস ও নেটওয়ার্কের ক্ষেত্রে ভালোভাবে কাজ করতে পারে এবং স্ট্রিমিং ডকুমেন্ট পার্সিংয়ের মতো আকর্ষণীয় ব্রাউজার অপ্টিমাইজেশন খুলে দেয়।
সার্ভার-সাইড রেন্ডারিংয়ের মাধ্যমে, ব্যবহারকারীদের আপনার সাইট ব্যবহার করার আগে CPU-বাউন্ড জাভাস্ক্রিপ্ট রান করার জন্য অপেক্ষা করতে হয় না। এমনকি আপনি থার্ড-পার্টি জাভাস্ক্রিপ্ট এড়াতে না পারলেও, আপনার নিজস্ব ফার্স্ট-পার্টি জাভাস্ক্রিপ্ট খরচ কমানোর জন্য সার্ভার-সাইড রেন্ডারিং ব্যবহার করলে, বাকিগুলির জন্য আপনি আরও বাজেট পেতে পারেন। তবে, এই পদ্ধতির একটি সম্ভাব্য ট্রেড-অফ আছে: সার্ভারে পৃষ্ঠা তৈরি করতে সময় লাগে, যা আপনার পৃষ্ঠার TTFB বাড়াতে পারে।
আপনার অ্যাপ্লিকেশনের জন্য সার্ভার-সাইড রেন্ডারিং যথেষ্ট কিনা তা মূলত নির্ভর করে আপনি কী ধরনের অভিজ্ঞতা তৈরি করছেন তার উপর। সার্ভার-সাইড রেন্ডারিং বনাম ক্লায়েন্ট-সাইড রেন্ডারিংয়ের সঠিক প্রয়োগ নিয়ে দীর্ঘদিন ধরে বিতর্ক চলছে, তবে আপনি সবসময় কিছু পৃষ্ঠার জন্য সার্ভার-সাইড রেন্ডারিং ব্যবহার করার সিদ্ধান্ত নিতে পারেন এবং অন্যগুলির জন্য নয়। কিছু সাইট হাইব্রিড রেন্ডারিং কৌশল সফলভাবে গ্রহণ করেছে। যেমন, Netflix তার তুলনামূলকভাবে স্ট্যাটিক ল্যান্ডিং পৃষ্ঠাগুলি সার্ভার-রেন্ডার করে, যেখানে prefetching ইন্টার্যাকশন-হেভি পৃষ্ঠাগুলির জন্য জাভাস্ক্রিপ্ট, এই ভারী ক্লায়েন্ট-রেন্ডার করা পৃষ্ঠাগুলিকে দ্রুত লোড হওয়ার আরও ভাল সুযোগ দেয়।
অনেক আধুনিক ফ্রেমওয়ার্ক, লাইব্রেরি ও আর্কিটেকচারের সাহায্যে আপনি ক্লায়েন্ট ও সার্ভার, উভয় জায়গাতেই একই অ্যাপ্লিকেশন রেন্ডার করতে পারবেন। সার্ভার-সাইড রেন্ডারিংয়ের জন্য আপনি এইসব টেকনিক ব্যবহার করতে পারেন। তবে, সার্ভার এবং ক্লায়েন্ট, দুটিতেই রেন্ডারিং হয় এমন আর্কিটেকচার হল তাদের নিজস্ব ধরনের সমাধান, যার পারফর্ম্যান্সের বৈশিষ্ট্য ও ট্রেড-অফ একেবারে আলাদা। React ব্যবহারকারীরা সার্ভার-সাইড রেন্ডারিংয়ের জন্য সার্ভার DOM API বা Next.js-এর মতো সেগুলির উপর তৈরি করা সমাধান ব্যবহার করতে পারেন। Vue ব্যবহারকারীরা Vue-এর সার্ভার-সাইড রেন্ডারিং গাইড বা Nuxt ব্যবহার করতে পারবেন। Angular-এ Universal আছে।
তবে, বেশিরভাগ জনপ্রিয় সলিউশন কোনও না কোনও ধরনের হাইড্রেশন ব্যবহার করে, তাই আপনার টুল কোন পদ্ধতি ব্যবহার করে সেই সম্পর্কে সচেতন থাকুন।
স্ট্যাটিক রেন্ডারিং
বিল্ড টাইমে স্ট্যাটিক রেন্ডারিং হয়। এই পদ্ধতি দ্রুত FCP এবং কম TBT ও INP অফার করে, যতক্ষণ না আপনি পৃষ্ঠায় ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্টের পরিমাণ সীমিত করছেন। সার্ভার-সাইড রেন্ডারিংয়ের মতো না হলেও, এটিও ধারাবাহিকভাবে দ্রুত TTFB অর্জন করে, কারণ কোনও পৃষ্ঠার জন্য HTML সার্ভারে ডায়নামিকভাবে জেনারেট করতে হয় না। সাধারণত, স্ট্যাটিক রেন্ডারিং বলতে প্রতিটি URL-এর জন্য আগে থেকেই আলাদা HTML ফাইল তৈরি করা বোঝায়। আগে থেকে জেনারেট করা HTML উত্তরের মাধ্যমে, আপনি এজ ক্যাশিংয়ের সুবিধা নিতে একাধিক CDN-এ স্ট্যাটিক রেন্ডার ডেপ্লয় করতে পারবেন।
স্ট্যাটিক রেন্ডারিংয়ের সমাধান বিভিন্ন ধরনের হতে পারে। Gatsby-এর মতো টুল এমনভাবে ডিজাইন করা হয়েছে যাতে ডেভেলপাররা মনে করেন যে তাদের অ্যাপ্লিকেশন ডাইনামিকভাবে রেন্ডার করা হচ্ছে, বিল্ড স্টেপ হিসেবে জেনারেট করা হচ্ছে না। 11ty, Jekyll ও Metalsmith-এর মতো স্ট্যাটিক সাইট জেনারেশন টুল তাদের স্ট্যাটিক প্রকৃতিকে গ্রহণ করে, আরও টেমপ্লেট-চালিত পদ্ধতি প্রদান করে।
স্ট্যাটিক রেন্ডারিংয়ের একটি অসুবিধা হল, এটি প্রতিটি সম্ভাব্য URL-এর জন্য আলাদা আলাদা HTML ফাইল তৈরি করে। এটি করা কঠিন বা অসম্ভব হতে পারে যখন আপনাকে আগে থেকে সেইসব URL অনুমান করতে হয় এবং অনেক অনন্য পৃষ্ঠা সহ সাইটের জন্য।
React ব্যবহারকারীরা Gatsby, Next.js স্ট্যাটিক এক্সপোর্ট অথবা Navi-এর সাথে পরিচিত হতে পারেন, যার সবকটিই কম্পোনেন্ট থেকে পৃষ্ঠা তৈরি করা সুবিধাজনক করে তোলে। তবে, স্ট্যাটিক রেন্ডারিং এবং প্রিরেন্ডারিং আলাদাভাবে কাজ করে: স্ট্যাটিক্যালি রেন্ডার করা পৃষ্ঠাগুলি ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্ট চালানোর প্রয়োজন ছাড়াই ইন্টার্যাক্টিভ হয়, যেখানে প্রিরেন্ডারিং একটি সিঙ্গেল পেজ অ্যাপ্লিকেশনের FCP উন্নত করে যা পৃষ্ঠাগুলিকে সত্যিকারের ইন্টার্যাক্টিভ করতে ক্লায়েন্টে বুট করতে হবে।
কোনও সমাধান স্ট্যাটিক রেন্ডারিং নাকি প্রিরেন্ডারিং তা নিয়ে আপনি নিশ্চিত না হলে, জাভাস্ক্রিপ্ট বন্ধ করে দিয়ে যে পৃষ্ঠাটি পরীক্ষা করতে চান সেটি লোড করে দেখুন। স্ট্যাটিক্যালি রেন্ডার করা পৃষ্ঠার ক্ষেত্রে, জাভাস্ক্রিপ্ট ছাড়াই বেশিরভাগ ইন্টার্যাক্টিভ ফিচার এখনও কাজ করে। প্রিরেন্ডার করা পৃষ্ঠায় এখনও কিছু প্রাথমিক ফিচার থাকতে পারে, যেমন জাভাস্ক্রিপ্ট বন্ধ করা আছে এমন লিঙ্ক, তবে পৃষ্ঠার বেশিরভাগ অংশই নিষ্ক্রিয়।
আরেকটি কার্যকর পরীক্ষা হল Chrome DevTools-এ নেটওয়ার্ক থ্রটলিং ব্যবহার করা এবং কোনও পৃষ্ঠা ইন্টার্যাক্টিভ হওয়ার আগে কতটা জাভাস্ক্রিপ্ট ডাউনলোড হয় তা দেখা। ইন্টার্যাক্টিভ হওয়ার জন্য প্রিরেন্ডারিংয়ের ক্ষেত্রে সাধারণত আরও বেশি জাভাস্ক্রিপ্টের প্রয়োজন হয় এবং সেই জাভাস্ক্রিপ্ট স্ট্যাটিক রেন্ডারিংয়ে ব্যবহৃত প্রোগ্রেসিভ এনহ্যান্সমেন্ট পদ্ধতির চেয়ে আরও জটিল হয়।
সার্ভার-সাইড রেন্ডারিং বনাম স্ট্যাটিক রেন্ডারিং
সার্ভার-সাইড রেন্ডারিং সবকিছুর জন্য সেরা সমাধান নয়, কারণ এর
ডাইনামিক প্রকৃতির কারণে উল্লেখযোগ্য কম্পিউট ওভারহেড খরচ হতে পারে। অনেক সার্ভার-সাইড
রেন্ডারিং সমাধান তাড়াতাড়ি ফ্লাশ করে না, TTFB-তে দেরি করে বা পাঠানো ডেটা দ্বিগুণ করে
(যেমন, ক্লায়েন্টে জাভাস্ক্রিপ্ট দ্বারা ব্যবহৃত ইনলাইনড স্টেট)। React-এ,
renderToString() ধীরগতির হতে পারে কারণ এটি সিঙ্ক্রোনাস এবং সিঙ্গেল-থ্রেডেড।
নতুন React সার্ভার DOM API
স্ট্রিমিং সাপোর্ট করে, যা ব্রাউজারে HTML রেসপন্সের প্রাথমিক অংশ দ্রুত পেতে পারে, যখন বাকি অংশটি এখনও সার্ভারে তৈরি হচ্ছে।
সার্ভার-সাইড রেন্ডারিং "সঠিক" করার জন্য কম্পোনেন্ট ক্যাশিং, মেমরি ব্যবহার ম্যানেজ করা, মেমোইজেশন টেকনিক ব্যবহার করা এবং অন্যান্য সমস্যার জন্য সমাধান খোঁজা বা তৈরি করা প্রয়োজন হতে পারে। আপনি প্রায়ই একই অ্যাপ দুবার প্রসেস বা রিবিল্ড করছেন, একবার ক্লায়েন্টে এবং একবার সার্ভারে। সার্ভার-সাইড রেন্ডারিংয়ের মাধ্যমে কন্টেন্ট দ্রুত দেখানো হলেও, আপনাকে কম কাজ করতে হবে এমন নয়। সার্ভার-জেনারেটেড HTML রেসপন্স ক্লায়েন্টের কাছে পৌঁছানোর পরে ক্লায়েন্টের কাছে অনেক কাজ থাকলে, আপনার ওয়েবসাইটের ক্ষেত্রে TBT ও INP-এর মান বেশি হতে পারে।
সার্ভার-সাইড রেন্ডারিং প্রতিটি URL-এর জন্য চাহিদা অনুযায়ী HTML তৈরি করে, তবে এটি স্ট্যাটিক রেন্ডার করা কন্টেন্ট পরিবেশন করার চেয়ে ধীর হতে পারে। আপনি যদি অতিরিক্ত পরিশ্রম করতে পারেন, তাহলে সার্ভার-সাইড রেন্ডারিং এবং HTML ক্যাশিং সার্ভার রেন্ডার করার মোট সময় উল্লেখযোগ্যভাবে কমাতে পারে। সার্ভার-সাইড রেন্ডারিংয়ের সুবিধা হল এটি আরও বেশি "লাইভ" ডেটা সংগ্রহ করতে পারে এবং স্ট্যাটিক রেন্ডারিংয়ের তুলনায় আরও সম্পূর্ণ সেট অনুরোধের উত্তর দিতে পারে। যেসব পৃষ্ঠায় পছন্দমতো সাজানোর প্রয়োজন হয় সেগুলি হল এমন ধরনের অনুরোধের একটি বাস্তব উদাহরণ যা স্ট্যাটিক রেন্ডারিংয়ের সাথে ভালভাবে কাজ করে না।
PWA তৈরি করার সময় সার্ভার-সাইড রেন্ডারিংয়ের মাধ্যমেও আকর্ষণীয় সিদ্ধান্ত নেওয়া যেতে পারে। সম্পূর্ণ পৃষ্ঠার সার্ভিস ওয়ার্কার ক্যাশিং ব্যবহার করা কি ভালো, নাকি কন্টেন্টের প্রতিটি অংশ সার্ভার-রেন্ডার করা?
ক্লায়েন্ট-সাইড রেন্ডারিং
ক্লায়েন্ট-সাইড রেন্ডারিং বলতে জাভাস্ক্রিপ্টের মাধ্যমে সরাসরি ব্রাউজারে পৃষ্ঠা রেন্ডার করাকে বোঝায়। সার্ভারের পরিবর্তে ক্লায়েন্টে সব লজিক, ডেটা ফেচিং, টেমপ্লেটিং ও রাউটিং ম্যানেজ করা হয়। এর ফলে, সার্ভার থেকে ব্যবহারকারীর ডিভাইসে আরও বেশি ডেটা পাঠানো হয় এবং এর সাথে কিছু সুবিধা ও অসুবিধা থাকে।
মোবাইল ডিভাইসের জন্য ক্লায়েন্ট-সাইড রেন্ডারিং তৈরি করা এবং দ্রুত রাখা কঠিন হতে পারে।
জাভাস্ক্রিপ্ট বাজেট কঠোরভাবে নিয়ন্ত্রণ
করার জন্য সামান্য কাজ করে এবং যত কম সম্ভব রাউন্ড-ট্রিপ
করে ভ্যালু ডেলিভার করে, আপনি ক্লায়েন্ট-সাইড রেন্ডারিংয়ের মাধ্যমে
প্রায় নিখুঁত সার্ভার-সাইড রেন্ডারিংয়ের পারফর্ম্যান্স রেপ্লিকেট করতে পারবেন। আপনি <link rel=preload> ব্যবহার করে গুরুত্বপূর্ণ স্ক্রিপ্ট ও ডেটা ডেলিভার করার মাধ্যমে
পার্সারকে আপনার জন্য আরও দ্রুত কাজ করাতে পারেন।
এছাড়াও, আমরা সাজেস্ট করি যে প্রাথমিক ও পরবর্তী নেভিগেশন যাতে ঝটপট হয় তা নিশ্চিত করতে
PRPL-এর মতো প্যাটার্ন ব্যবহার করার কথা বিবেচনা করুন।
ক্লায়েন্ট-সাইড রেন্ডারিংয়ের প্রধান অসুবিধা হল, অ্যাপ্লিকেশন যত বড় হয়, তত বেশি জাভাস্ক্রিপ্ট প্রয়োজন হয়, যা পৃষ্ঠার INP-কে প্রভাবিত করতে পারে। নতুন জাভাস্ক্রিপ্ট লাইব্রেরি, পলিফিল ও থার্ড-পার্টি কোড যোগ করার ফলে এটি আরও কঠিন হয়ে যায়, কারণ এগুলি প্রসেসিং পাওয়ারের জন্য প্রতিযোগিতা করে এবং পৃষ্ঠার কন্টেন্ট রেন্ডার করার আগে এগুলি প্রসেস করতে হয়।
যেসব অভিজ্ঞতা ক্লায়েন্ট-সাইড রেন্ডারিং ব্যবহার করে এবং বড় জাভাস্ক্রিপ্ট বান্ডেলের উপর নির্ভর করে, সেগুলির ক্ষেত্রে পৃষ্ঠা লোড হওয়ার সময় TBT ও INP কমানোর জন্য অ্যাগ্রেসিভ কোড-স্প্লিটিং ব্যবহার করার কথা বিবেচনা করা উচিত। এর পাশাপাশি, ব্যবহারকারীর যখন যা প্রয়োজন, শুধু তাই পরিবেশন করার জন্য জাভাস্ক্রিপ্ট ধীরে ধীরে লোড করার কথাও বিবেচনা করা উচিত। ইন্টার্যাক্টিভিটি কম বা একেবারেই নেই এমন অভিজ্ঞতার জন্য, সার্ভার-সাইড রেন্ডারিং এই সমস্যাগুলির জন্য আরও স্কেলেবল সমাধান প্রদান করতে পারে।
সিঙ্গেল পেজ অ্যাপ্লিকেশন তৈরি করার সময়, বেশিরভাগ পৃষ্ঠার সাথে শেয়ার করা ইউজার ইন্টারফেসের মূল অংশ শনাক্ত করলে, আপনি
অ্যাপ্লিকেশন শেল ক্যাশিং
টেকনিক প্রয়োগ করতে পারবেন। সার্ভিস ওয়ার্কারের সাথে এটি ব্যবহার করলে, বার বার ভিজিট করার ক্ষেত্রে
পারফর্ম্যান্স অনেক উন্নত হয়, কারণ পৃষ্ঠাটি CacheStorage থেকে খুব দ্রুত
অ্যাপ্লিকেশন শেল HTML ও ডিপেন্ডেন্সি লোড করতে পারে।
রিহাইড্রেশন সার্ভার-সাইড ও ক্লায়েন্ট-সাইড রেন্ডারিং একত্রিত করে
হাইড্রেশন হল এমন একটি পদ্ধতি যা ক্লায়েন্ট-সাইড ও সার্ভার-সাইড রেন্ডারিংয়ের মধ্যে ট্রেড-অফ কম করে। নেভিগেশন সংক্রান্ত অনুরোধ, যেমন সম্পূর্ণ পৃষ্ঠা লোড বা রিলোড করা, এমন একটি সার্ভার দ্বারা ম্যানেজ করা হয় যা অ্যাপ্লিকেশনটিকে HTML-এ রেন্ডার করে। তারপর, রেন্ডার করার জন্য ব্যবহৃত JavaScript এবং ডেটা, ফলাফল হিসেবে পাওয়া ডকুমেন্টে এম্বেড করা হয়। সতর্কতার সাথে এটি করা হলে, সার্ভার-সাইড রেন্ডারিংয়ের মতো দ্রুত FCP অর্জন করা যায়, তারপর ক্লায়েন্টে আবার রেন্ডার করার মাধ্যমে "পিক-আপ" করা হয়।
এটি একটি কার্যকর সমাধান, তবে এর ফলে পারফর্ম্যান্সের ক্ষেত্রে উল্লেখযোগ্য ত্রুটি দেখা দিতে পারে।
রিহাইড্রেশন সহ সার্ভার-সাইড রেন্ডারিংয়ের প্রধান অসুবিধা হল, এটি FCP উন্নত করলেও, TBT এবং INP-এর উপর উল্লেখযোগ্য নেতিবাচক প্রভাব ফেলতে পারে। সার্ভার-সাইড রেন্ডার করা পৃষ্ঠাগুলি লোড করা এবং ইন্টার্যাক্টিভ বলে মনে হতে পারে, কিন্তু কম্পোনেন্টের জন্য ক্লায়েন্ট-সাইড স্ক্রিপ্টগুলি কার্যকর না হওয়া পর্যন্ত এবং ইভেন্ট হ্যান্ডলারগুলি সংযুক্ত না হওয়া পর্যন্ত আসলে ইনপুটে সাড়া দিতে পারে না। মোবাইলে এটি করতে মিনিট সময় লাগতে পারে, যা ব্যবহারকারীকে বিভ্রান্ত ও হতাশ করতে পারে।
রিহাইড্রেশন সংক্রান্ত সমস্যা: দুটির দামে একটি অ্যাপ
সার্ভার যেখানে শেষ করেছে সেখান থেকে ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্ট যাতে সঠিকভাবে শুরু করতে পারে, তার জন্য সার্ভার যে ডেটা ব্যবহার করে HTML রেন্ডার করেছে সেই ডেটার জন্য আবার অনুরোধ না করে, বেশিরভাগ সার্ভার-সাইড রেন্ডারিং সমাধান UI-এর ডেটা ডিপেন্ডেন্সি থেকে পাওয়া উত্তরকে ডকুমেন্টে স্ক্রিপ্ট ট্যাগ হিসেবে সিরিয়ালাইজ করে। কারণ এটি অনেক HTML ডুপ্লিকেট করে, রিহাইড্রেশন শুধু ইন্টার্যাক্টিভিটিতে দেরি হওয়ার চেয়েও বেশি সমস্যা তৈরি করতে পারে।
সার্ভার নেভিগেশন অনুরোধের উত্তরে অ্যাপ্লিকেশনের UI-এর বিবরণ রিটার্ন করছে, তবে এটি সেই UI কম্পোজ করার জন্য ব্যবহৃত সোর্স ডেটা এবং UI-এর ইমপ্লিমেন্টেশনের একটি সম্পূর্ণ কপিও রিটার্ন করছে যা পরে ক্লায়েন্টে বুট আপ হয়। bundle.js লোড ও এক্সিকিউট করা শেষ না হওয়া পর্যন্ত UI ইন্টার্যাক্টিভ হয় না।
সার্ভার-সাইড রেন্ডারিং এবং রিহাইড্রেশন ব্যবহার করে আসল ওয়েবসাইট থেকে সংগ্রহ করা পারফর্ম্যান্স মেট্রিক ইঙ্গিত করে যে এটি খুব কমই সেরা বিকল্প। সবচেয়ে গুরুত্বপূর্ণ কারণ হল ব্যবহারকারীর অভিজ্ঞতার উপর এর প্রভাব, যখন কোনও পৃষ্ঠা রেডি দেখায় কিন্তু এর কোনও ইন্টার্যাক্টিভ ফিচার কাজ করে না।
রিহাইড্রেশন সহ সার্ভার-সাইড রেন্ডারিংয়ের আশা আছে। অল্প সময়ের জন্য, খুব বেশি ক্যাশে করা যায় এমন কন্টেন্টের জন্য শুধুমাত্র সার্ভার-সাইড রেন্ডারিং ব্যবহার করলে TTFB কমে যেতে পারে, যা প্রিরেন্ডারিংয়ের মতো একই ফলাফল দেয়। ধাপে ধাপে, ক্রমশ বা আংশিকভাবে রিহাইড্রেশন করা হলে, ভবিষ্যতে এই টেকনিক আরও কার্যকরী হতে পারে।
সার্ভার-সাইড রেন্ডারিং স্ট্রিম করুন এবং প্রগ্রেসিভভাবে রিহাইড্রেট করুন
গত কয়েক বছরে সার্ভার-সাইড রেন্ডারিংয়ের ক্ষেত্রে অনেক উন্নতি হয়েছে।
স্ট্রিমিং সার্ভার-সাইড রেন্ডারিং
আপনাকে চাঙ্কে HTML পাঠাতে দেয় যা ব্রাউজার পাওয়ার সাথে সাথে প্রগ্রেসিভলি রেন্ডার করতে পারে। এটি আপনার ব্যবহারকারীদের কাছে দ্রুত মার্কআপ পেতে পারে, আপনার FCP-এর গতি বাড়াতে পারে। React-এ,
সিঙ্ক্রোনাস renderToString()-এর তুলনায় renderToPipeableStream()-এ অ্যাসিঙ্ক্রোনাস স্ট্রিম হওয়ার অর্থ হল ব্যাকপ্রেশার ভালোভাবে ম্যানেজ করা হয়।
প্রোগ্রেসিভ রিহাইড্রেশন ব্যবহার করার কথাও বিবেচনা করা যেতে পারে (React এটি প্রয়োগ করেছে)। এই পদ্ধতির মাধ্যমে, সার্ভার-রেন্ডার করা অ্যাপ্লিকেশনের স্বতন্ত্র অংশগুলি সময়ের সাথে সাথে "বুট আপ" হয়, যা একবারে সম্পূর্ণ অ্যাপ্লিকেশন শুরু করার বর্তমান সাধারণ পদ্ধতির পরিবর্তে ব্যবহৃত হয়। এটি পৃষ্ঠা ইন্টার্যাক্টিভ করার জন্য প্রয়োজনীয় জাভাস্ক্রিপ্টের পরিমাণ কমাতে সাহায্য করতে পারে, কারণ এটি আপনাকে পৃষ্ঠার কম-অগ্রাধিকারের অংশগুলির ক্লায়েন্ট-সাইড আপগ্রেড করা স্থগিত করতে দেয় যাতে এটি মূল থ্রেডকে ব্লক করতে না পারে, যার ফলে ব্যবহারকারী ইন্টার্যাকশন শুরু করার পরে ব্যবহারকারীর ইন্টার্যাকশন আরও দ্রুত ঘটতে দেয়।
প্রোগ্রেসিভ রিহাইড্রেশন আপনাকে সার্ভার-সাইড রেন্ডারিং রিহাইড্রেশনের সবচেয়ে সাধারণ
সমস্যা এড়াতে সাহায্য করে: সার্ভার-রেন্ডার করা DOM ট্রি
নষ্ট হয়ে যায় এবং সাথে সাথে আবার তৈরি হয়, বেশিরভাগ ক্ষেত্রে কারণ হল প্রাথমিক
সিঙ্ক্রোনাস ক্লায়েন্ট-সাইড রেন্ডারের জন্য এমন ডেটা প্রয়োজন যা সম্পূর্ণ তৈরি নয়, প্রায়শই এমন একটি
Promise যা এখনও সমাধান করা হয়নি।
আংশিক রিহাইড্রেশন
আংশিক রিহাইড্রেশন প্রয়োগ করা কঠিন বলে প্রমাণিত হয়েছে। এই পদ্ধতিটি হল প্রোগ্রেসিভ রিহাইড্রেশনের এক্সটেনশন যা পৃষ্ঠার পৃথক অংশগুলি বিশ্লেষণ করে (কম্পোনেন্ট, ভিউ বা ট্রি) এবং সামান্য ইন্টার্যাক্টিভিটি বা কোনও রিয়্যাক্টিভিটি নেই এমন অংশগুলি শনাক্ত করে। এইসব বেশিরভাগ-স্ট্যাটিক অংশের প্রতিটির জন্য, সংশ্লিষ্ট JavaScript কোডকে তারপর ইনার্ট রেফারেন্স ও ডেকোরেটিভ ফিচারে রূপান্তরিত করা হয়, যার ফলে ক্লায়েন্ট-সাইড ফুটপ্রিন্ট প্রায় শূন্য হয়ে যায়।
আংশিক রিহাইড্রেশন অ্যাপ্রোচের নিজস্ব সমস্যা ও আপস রয়েছে। এটি ক্যাশিংয়ের জন্য কিছু আকর্ষণীয় চ্যালেঞ্জ তৈরি করে এবং ক্লায়েন্ট-সাইড নেভিগেশনের অর্থ হল আমরা ধরে নিতে পারি না যে অ্যাপ্লিকেশনের ইনার্ট অংশের জন্য সার্ভার-রেন্ডার করা HTML সম্পূর্ণ পৃষ্ঠা লোড না করেই উপলভ্য।
ট্রাইসোমরফিক রেন্ডারিং
সার্ভিস ওয়ার্কার আপনার জন্য একটি বিকল্প হলে, ট্রাইসোমরফিক রেন্ডারিং বিবেচনা করুন। এই টেকনিকের সাহায্যে আপনি প্রাথমিক বা জাভাস্ক্রিপ্ট ছাড়া নেভিগেশনের জন্য স্ট্রিমিং সার্ভার-সাইড রেন্ডারিং ব্যবহার করতে পারবেন এবং তারপরে আপনার সার্ভিস ওয়ার্কার ইনস্টল হয়ে গেলে নেভিগেশনের জন্য HTML রেন্ডারিংয়ের দায়িত্ব নিতে পারবে। এটি ক্যাশে করা কম্পোনেন্ট ও টেমপ্লেট আপ-টু-ডেট রাখতে পারে এবং একই সেশনে নতুন ভিউ রেন্ডার করার জন্য SPA-স্টাইল নেভিগেশন চালু করতে পারে। সার্ভার, ক্লায়েন্ট পৃষ্ঠা ও সার্ভিস ওয়ার্কারের মধ্যে একই টেমপ্লেট ও রাউটিং কোড শেয়ার করতে পারলে, এই পদ্ধতি সবচেয়ে ভাল কাজ করে।
SEO সংক্রান্ত বিবেচ্য বিষয়
ওয়েব রেন্ডারিং স্ট্র্যাটেজি বেছে নেওয়ার সময়, টিম প্রায়শই SEO-এর প্রভাব বিবেচনা করে। সার্ভার-সাইড রেন্ডারিং হল "সম্পূর্ণ দেখতে" অভিজ্ঞতা প্রদান করার জন্য একটি জনপ্রিয় পছন্দ যা ক্রলার ব্যাখ্যা করতে পারে। ক্রলার জাভাস্ক্রিপ্ট বুঝতে পারে, তবে সেগুলি কীভাবে রেন্ডার করে তার উপর প্রায়ই সীমাবদ্ধতা থাকে। ক্লায়েন্ট-সাইড রেন্ডারিং কাজ করতে পারে, তবে প্রায়শই অতিরিক্ত পরীক্ষা এবং ওভারহেডের প্রয়োজন হয়। আরও সম্প্রতি, ডায়নামিক রেন্ডারিং বিকল্পটিও বিবেচনা করা যেতে পারে, যদি আপনার আর্কিটেকচার ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্টের উপর অত্যন্ত নির্ভরশীল হয়।
উপসংহার
রেন্ডারিংয়ের জন্য কোনও পদ্ধতি বেছে নেওয়ার সময়, আপনার বাধাগুলি কী তা পরিমাপ করুন এবং বুঝুন। স্ট্যাটিক রেন্ডারিং বা সার্ভার-সাইড রেন্ডারিংয়ের মাধ্যমে আপনার কাজ কতটা হতে পারে তা বিবেচনা করুন। ইন্টার্যাক্টিভ অভিজ্ঞতা পেতে, ন্যূনতম JavaScript সহ HTML শিপ করা ঠিক আছে। সার্ভার-ক্লায়েন্ট স্পেকট্রাম দেখানোর জন্য এখানে একটি সহজ ইনফোগ্রাফিক দেওয়া হল:
ক্রেডিট
রিভিউ ও অনুপ্রেরণার জন্য সবাইকে ধন্যবাদ:
জেফ্রি পসনিক, হুসেইন জিরদেহ, শুভী পানিকর, ক্রিস হ্যারেলসন এবং সেবাস্তিয়ান মার্কবেজ।