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