২০২৬-এ Headless নাকি All-in-One স্টোরফ্রন্ট? কখন headless সত্যিই লাভজনক

ধরুন, একটা রিটেইল ব্যবসার ই-কমার্স প্রধান, যার দোকানে একটাই website আর ৩,০০০ পণ্য। বোর্ড মিটিংয়ের পরের সোমবার। এক প্রতিযোগী ঝকঝকে একটা app বের করেছে, বোর্ড জানতে চায় আমাদের দোকান এখনও থিমে চলছে কেন। বিকেলের মধ্যে এজেন্সির প্রস্তাব এসে হাজির: headless-এ যান, ১৪ মাস, আধুনিক ফ্রেমওয়ার্কে নতুন frontend।

এটা একটা কাল্পনিক দৃশ্য, কিন্তু এর পেছনের প্রশ্নটা আসল। প্রস্তাবে ইঞ্জিন, ফ্রেমওয়ার্ক আর সময়সূচির নাম থাকে। তৃতীয় বছরে নতুন ফ্রন্টএন্ডটাকে কারা বাঁচিয়ে রাখবে, তাদের নাম প্রায় থাকে না।

Headless যাওয়া আর্কিটেকচারের সিদ্ধান্ত, কোনো আপগ্রেড নয়। এতে সহজ একটা system-এর বদলে পাওয়া যায় নমনীয় একটা system, আর নমনীয়তার একটা চলতি খরচ আছে। কিছু ব্যবসার জন্য এই বিনিময় দারুণ, অনেকের জন্য একই বিক্রির বিপরীতে কাজ চুপচাপ দ্বিগুণ হয়ে যায়। এই লেখায় শব্দগুলোর সংজ্ঞা ঠিক করব, আসল খরচের তালিকা দেখব, বুঝব headless কখন কাজে দেয়, তারপর পাব একটা ফ্লোচার্ট, একটা সিদ্ধান্ত-ছক আর বিক্রি না থামিয়ে মাইগ্রেট করার পথ।

তিন ধরনের আর্কিটেকচার, সহজ ভাষায়

বিভ্রান্তির বেশিরভাগই আসে পরিভাষা থেকে, তাই শুরুতেই শব্দগুলোর মানে ঠিক করে নেওয়া ভালো।

• All-in-one (coupled)। একটাই অ্যাপ্লিকেশনে থাকে catalog, কার্ট, checkout, admin আর স্টোরফ্রন্টের পেজ। থিম বা template ঠিক করে চেহারা। deploy করতে হয় একটাই জিনিস।
• Headless। কমার্স ইঞ্জিন সবকিছু API দিয়ে খুলে দেয়, frontend নিয়ে তার কোনো মতামত নেই। আলাদা একটা অ্যাপ্লিকেশন, যেটা আপনি বানান ও হোস্ট করেন, পেজ রেন্ডার করে আর API-র সঙ্গে কথা বলে।
• Composable (প্রায়ই বলা হয় MACH: microservices, API-first, cloud-native, headless)। Headless-কে আরও এগিয়ে নেওয়া। সার্চ, কনটেন্ট, payment, রিভিউ আর checkout আসে আলাদা আলাদা বিশেষায়িত সেবা থেকে, আপনি সেগুলো জোড়া লাগান।

চতুর্থ একটা বিকল্প আছে, যার নাম কমই শোনা যায়: hybrid। platform-এ থাকে বিল্ট-ইন স্টোরফ্রন্ট এবং পূর্ণাঙ্গ API। website চলে বিল্ট-ইন স্টোরফ্রন্টে, আর mobile app, কিয়স্ক বা পার্টনার পোর্টাল ব্যবহার করে API। যেখানে দরকার সেখানে headless, বাকি সবখানে coupled-এর সরলতা।

Headless-এর আসল খরচ

কমার্স ইঞ্জিনের লাইসেন্স বা হোস্টিং ফি সবচেয়ে ছোট লাইন। বড় খরচগুলো তার চারপাশে, আর প্রতিটাই এমন কাজ যা coupled platform আগে আপনার হয়ে করে দিত।

• frontend টিম। product পেজ, ক্যাটেগরি পেজ, কার্ট, checkout, account এরিয়া আর সার্চ কাউকে বানাতে হবে, তারপর বছরের পর বছর রক্ষণাবেক্ষণ করতে হবে। এটা স্থায়ী টিম, একবারের প্রজেক্ট নয়।
• frontend-এর হোস্টিং। দ্বিতীয় অ্যাপ্লিকেশনের জন্য লাগে server বা platform, CDN, monitoring আর অন-কলে কারও মনোযোগ।
• দুটো deploy pipeline। API আর screen, দুটোই ছুঁয়ে যায় এমন পরিবর্তন সঠিক ক্রমে release করতে হয়, দুই পক্ষের মাঝখানে রাখতে হয় ভার্সন-করা API চুক্তি।
• প্রিভিউ ও কনটেন্টের কাজের ধারা। Coupled platform-এ "লাইভ হওয়ার আগে পরিবর্তনটা দেখা" তৈরিই থাকে। Headless-এ প্রিভিউ বানাতে হয় নিজেকে।
• SEO ও স্ট্রাকচার্ড data। টাইটেল, canonical ট্যাগ, সাইটম্যাপ, রিডাইরেক্ট, product স্কিমা আর hreflang, সবই হয়ে যায় আপনার কোড। এখানে ভুল হলে সার্চ traffic নিঃশব্দে কমে।
• ভাষা ও অঞ্চলভেদ। অনূদিত URL, মুদ্রা, ডান-থেকে-বামের লেআউট আর স্থানীয় ট্যাক্স প্রদর্শন frontend-এ আবার বানাতে হয়।
• অ্যানালিটিক্স ও কনসেন্ট। পিক্সেল, server-সাইড event আর কনসেন্ট ব্যানার আর প্লাগইন হয়ে আসে না। প্রতিটা আপনাকে জুড়তে হয়।
• যে এক্সটেনশন আর কাজ করে না। রিভিউ, লয়্যালটি উইজেট, আপসেল ব্লক আর পেজ বিল্ডার সাধারণত ধরে নেয় পেজ রেন্ডার করবে platform। Headless-এ প্রতিটার জন্য লাগে একটা API রুট আর নিজের বানানো একটা কম্পোনেন্ট।

এগুলোর কোনোটাই আলাদাভাবে কঠিন নয়। কিন্তু সব মিলিয়ে এটা দ্বিতীয় একটা product। একটা কাজের নিয়ম: তৃতীয় বছরে frontend কোডবেসের দায়িত্ব কে নেবে, নাম বলতে না পারলে আপনি শুরু করার জন্য তৈরি নন।

এক বছরের headless, সংখ্যায়

একটা কাল্পনিক হিসাব, মার্কিন ডলারে: একটা website আর বছরে প্রায় ৪০ লাখ বিক্রির এক রিটেইলার। বেতনের অঙ্কগুলো গোল করা, নিজের বাজারের হার বসিয়ে নিন।

খরচের খাত	Headless frontend	All-in-one থিম
developer (২ ইঞ্জিনিয়ার বনাম এজেন্সির ঘণ্টা)	170,000	12,000
DevOps ও QA-এর ভাগ	45,000	0
frontend-এর হোস্টিং ও CDN	9,000	অন্তর্ভুক্ত
প্রিভিউ ও কনটেন্ট টুল	12,000	বিল্ট-ইন
monitoring ও এরর tracking	6,000	2,000
বছরে মোট	242,000	14,000

ফারাক বছরে 228,000। ২৫ শতাংশ কন্ট্রিবিউশন margin-এ (বিক্রি থেকে বিক্রি হওয়া পণ্যের পরিবর্তনশীল খরচ বাদ দিলে যা থাকে) নতুন frontend-কে নিজের খরচ তুলতে 912,000 বাড়তি বিক্রি আনতে হবে, অর্থাৎ ৪০ লাখের ওপর প্রায় ২৩ শতাংশ বৃদ্ধি। শুধু রিডিজাইনে সেটা আসার সম্ভাবনা কম, তাই যুক্তিটা দাঁড়াতে হবে অন্য কিছুর ওপর: আরও frontend, থিমে বানানো যায় না এমন অভিজ্ঞতা, কিংবা থিম সামলাতে পারে না এমন traffic। একই খরচ একটা API-র ওপর বসা চারটা frontend-এর মধ্যে ভাগ হলে হিসাবটাই বদলে যায়।

পারফরম্যান্স: গতি আসলে কীসে ঠিক হয়

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

Google ব্যবহারকারীর আসল অভিজ্ঞতা মাপে তিনটি Core Web Vitals দিয়ে। Google-এর web.dev ডকুমেন্টেশন অনুযায়ী, ভিজিটের ৭৫তম পার্সেন্টাইলে Largest Contentful Paint (লোডিং) ২.৫ সেকেন্ড বা কম, Interaction to Next Paint (সাড়া দেওয়ার গতি) ২০০ মিলিসেকেন্ড বা কম, এবং Cumulative Layout Shift (ভিজ্যুয়াল স্থিতি) ০.১ বা কম হলে পেজকে "ভালো" ধরা হয়। ২০২৪ সালের ১২ মার্চ Interaction to Next Paint, First Input Delay-এর জায়গায় Core Web Vital হয়, আর এটা বেশি কড়া: শুধু প্রথম ইন্টার‍্যাকশন নয়, ভিজিটের সব ইন্টার‍্যাকশন দেখে।

সিদ্ধান্তের জন্য এর মানে কী:

• আর্কিটেকচারের চেয়ে server রেন্ডারিং বেশি জরুরি। যে product পেজের HTML server থেকে পুরোটা আসে, সেটা দ্রুত লোড হয় আর সার্চ ইঞ্জিনের পড়তেও সহজ। যে headless frontend data এনে browser-এ রেন্ডার করে, সেটা প্রায়ই coupled স্টোরফ্রন্টের চেয়ে ধীর।
• INP আসলে JavaScript-এর সমস্যা। ভারী frontend ফ্রেমওয়ার্ক, অনেকগুলো থার্ড-পার্টি স্ক্রিপ্ট আর বড় hydration বান্ডল একে খারাপ করে। Headless আপনাকে এর নিয়ন্ত্রণ দেয়, আবার খারাপ করার স্বাধীনতাও দেয়।
• ক্যাশিংয়ে headless সত্যিই ভালো করতে পারে। স্ট্যাটিক বা edge-cached frontend কমার্স ইঞ্জিনকে না ছুঁয়েই catalog পেজ দিতে পারে। অনেক বেশি traffic-এ এটা কাজে আসে।
• বাড়তি network হপে দেরি বাড়ে। frontend আর ইঞ্জিনের মধ্যে প্রতিটা API কলে সময় যায়। ভালো ডিজাইনে কলগুলো একসঙ্গে করা হয় আর জোরালোভাবে ক্যাশ করা হয়।

server রেন্ডারিং আর ফুল-পেজ ক্যাশিং সহ ভালোভাবে বানানো coupled স্টোরফ্রন্ট তিনটি সীমাই পার করতে পারে। খারাপভাবে বানানো headless তিনটিতেই ফেল করতে পারে।

কখন headless পুষিয়ে দেয়

নিচের অন্তত একটা সত্যি হলে headless তার খরচ তুলে আনে, একাধিক হলে আরও ভালো।

• একই catalog-এ একাধিক frontend। website, iOS ও Android app, শোরুমের screen, মার্কেটপ্লেস feed আর B2B পোর্টাল। একটা API-র ওপর প্রতিটা বানানো থিম পাঁচবার কাস্টমাইজ করার চেয়ে সাধারণত সস্তা।
• অভিজ্ঞতাই যখন product। ডিজাইননির্ভর ব্র্যান্ড, যাদের লাগে কাস্টম কনফিগারেটর, গল্প বলার মতো এডিটোরিয়াল বা এমন ইন্টার‍্যাকশন, যা কোনো template-এ হয় না।
• অনেক বেশি বা হঠাৎ হঠাৎ বেড়ে যাওয়া traffic। product লঞ্চ আর ফ্ল্যাশ সেল, যেখানে edge-cached frontend পিকের ধাক্কা থেকে কমার্স ইঞ্জিনকে বাঁচায়।
• টিম আগে থেকেই আছে। আপনার frontend ইঞ্জিনিয়ার আছেন, যারা না হলে প্রতি সপ্তাহে থিম system-এর সঙ্গে লড়তেন।
• কনটেন্টনির্ভর কমার্স। একই পেজে এডিটোরিয়াল, ভিডিও আর কেনাকাটা মেশানো, আর কনটেন্ট system আগে থেকেই আছে।

কখন দেয় না

আপনার অবস্থা এমন শোনালে সন্দেহ রাখুন:

• একটা website, একটা বা অল্প কয়েকটা ভাষা, আর সাধারণ কেনাকাটার ধাপ।
• শূন্য থেকে দুইজন developer-এর টিম, কিংবা ঘণ্টা হিসেবে টাকা নেওয়া এজেন্সি।
• আসল সমস্যা ধীর product ছবি, ফুলে যাওয়া থিম বা অনির্ভরযোগ্য stock-এর সংখ্যা। Headless এর কোনোটাই ঠিক করে না। ভালো ইমেজ পাইপলাইন, কম স্ক্রিপ্ট আর একটাই inventory ledger করে।
• মার্কেটিং developer ছাড়াই পেজ ও প্রমোশন চালু করতে চায়। Headless সাধারণত সেই ক্ষমতা ইঞ্জিনিয়ারিংয়ের হাতে ফিরিয়ে দেয়, যদি না আপনি সেজন্য টুল বানান।
• "প্রতিযোগী করেছে" যদি হয় প্রধান কারণ।

একটা কাল্পনিক উদাহরণ: ৩,০০০ পণ্য আর একটা website-এর এক দোকান পুরো এক বছর লাগিয়ে আধুনিক ফ্রেমওয়ার্কে frontend নতুন করে বানাল। সাইট দেখতে তাজা লাগে, কিন্তু কনভার্শন একই থাকে, কারণ পুরনো checkout কখনোই বাধা ছিল না। একই বাজেট ছবির অপ্টিমাইজেশন আর দ্রুততর server-এ খরচ করলে ফল মিলত কয়েক সপ্তাহে।

Hybrid পথ

বেশিরভাগ বাড়তে থাকা ব্যবসার জন্য সেরা বিকল্প কোনো চরম প্রান্তে নয়। website-এর জন্য বিল্ট-ইন স্টোরফ্রন্ট রাখুন, কারণ চালাতে সস্তা, আর SEO, checkout ও প্রমোশন আগে থেকেই কাজ করা অবস্থায় আসে। নিশ্চিত করুন platform-এ আছে সম্পূর্ণ, ডকুমেন্টেড API, আর সত্যিকারের দ্বিতীয় frontend এলে সেটা ব্যবহার করুন: mobile app, পার্টনার পোর্টাল, বা কাস্টম ল্যান্ডিং অভিজ্ঞতা।

software বাছাইয়ের সময় জিজ্ঞেস করুন, স্টোরফ্রন্ট আর API কি একই ইঞ্জিন, নাকি দুটো আলাদা product। কিছু platform, StoreConsole তার একটি, একই data-র ওপর বিল্ট-ইন স্টোরফ্রন্ট আর একটা headless API দুটোই দেয়, ফলে পরে API ধরতে মাইগ্রেশন করতে হয় না। যেটাই বাছুন, পরীক্ষা করে দেখুন: API-তে থাকতে হবে পণ্য, দাম, stock, কার্ট, checkout, order আর customer, শুধু catalog পড়া নয়।

Hybrid আপনাকে এক পেজ করে headless-এ যেতেও দেয়। একটা কাস্টম পেজ, যেমন কনফিগারেটর বা ক্যাম্পেইন পেজ, আলাদা frontend হিসেবে বানানো যায়, বাকি সব সাধারণ স্টোরফ্রন্টেই থাকে।

সিদ্ধান্তের ফ্লোচার্ট আর ছক

চারটা প্রশ্ন, পরপর করলে বেশিরভাগ ক্ষেত্রেই উত্তর মিলে যায়। একটা "না"-ই যথেষ্ট, আপাতত স্টোরফ্রন্ট বিল্ট-ইন রাখার জন্য।

ছকটা দ্বিতীয় ছাঁকনি হিসেবে ব্যবহার করুন। দেখুন আপনার বেশিরভাগ উত্তর কোন কলামে পড়ছে।

আপনার পরিস্থিতি	All-in-one	Hybrid	পুরো headless
একটা website, সাধারণ কেনাকাটার ধাপ	সবচেয়ে মানানসই	চলে	প্রয়োজনের বেশি
website আর একটা mobile app	দুর্বল	সবচেয়ে মানানসই	সম্ভব
তিনটি বা তার বেশি frontend	খারাপ	সম্ভব	সবচেয়ে মানানসই
নিজস্ব frontend টিম নেই	সবচেয়ে মানানসই	ভালো	ঝুঁকিপূর্ণ
মার্কেটিং প্রতিদিন পেজ বদলায়	সবচেয়ে মানানসই	ভালো	বাড়তি টুল লাগে
অনেক কাস্টম ডিজাইন ও ইন্টার‍্যাকশন	সীমিত	মূল পেজগুলোর জন্য ভালো	সবচেয়ে মানানসই
traffic-এর চরম ঢেউ	ভালো ক্যাশিং লাগে	ভালো	সবচেয়ে মানানসই
কম বাজেট, দ্রুত লঞ্চ	সবচেয়ে মানানসই	ভালো	খারাপ

বিক্রি না থামিয়ে মাইগ্রেশনের পথ

Headless যাওয়ার সিদ্ধান্ত নিলে এক সপ্তাহান্তে সব বদলাতে যাবেন না। ধাপে ধাপে এগোন, প্রতিটা ধাপ যেন ফেরানো যায়।

1. কারণটা লিখে রাখুন। যে একটা মাপা যায় এমন ফলাফল আশা করছেন তার নাম দিন, যেমন "app লঞ্চ করা" বা "মোবাইলে INP পাস করা"। না পারলে থামুন।
2. API যাচাই করুন। স্টোরফ্রন্টের যা যা কাজ লাগবে, প্রতিটার এন্ডপয়েন্ট আছে কি না দেখুন, সঙ্গে অথেনটিকেশন, রেট লিমিট আর ভার্সনিং।
3. নতুন frontend পুরনোটার পাশে বানান। বর্তমান স্টোরফ্রন্ট লাইভ রাখুন। checkout-এ এখনই হাত দেবেন না।
4. আগে SEO সঙ্গে নিন। URL অক্ষত রাখুন, যেখানে বদলায় সেখানে 301 রিডাইরেক্ট দিন, টাইটেল, স্কিমা ও সাইটম্যাপ তুলে আনুন, আর লঞ্চের আগে ক্রলের ফল মিলিয়ে দেখুন।
5. কম ঝুঁকির পেজ আগে সরান। আগে কনটেন্ট পেজ, তারপর ক্যাটেগরি, তারপর product পেজ। ছোট একটা অংশ, ধরুন ৫ থেকে ১০ শতাংশ traffic, নতুন পেজে পাঠিয়ে কনভার্শন আর Core Web Vitals তুলনা করুন।
6. কার্ট ও checkout সবার শেষে। আয় আসে এখান দিয়ে। অন্তত একটা পূর্ণ বিক্রয়চক্র পুরনো পথটা তাৎক্ষণিক ফলব্যাক হিসেবে রাখুন।
7. সংখ্যা ঠিক থাকলে তবেই পুরনো স্টোরফ্রন্ট বন্ধ করুন। রিডাইরেক্টগুলো এক বছর বা তার বেশি রেখে দিন।

পুরো সময়ে stock, দাম আর order-এর সত্যের উৎস রাখুন একটাই। frontend নতুন হতে পারে, কিন্তু order ও inventory-র লজিক তাতে কপি করা চলবে না।

সিদ্ধান্তের আগে যে প্রশ্নগুলো করবেন

• ঠিক কোন ব্যবসায়িক ফলের জন্য headless লাগে, আর টাকার অঙ্কে তার মূল্য কত?
• তৃতীয় বছরে frontend কে বানাবে, হোস্ট করবে আর ঠিক করবে?
• স্প্রিন্টের জন্য অপেক্ষা না করে মার্কেটিং কি এখনও ক্যাম্পেইন চালু করতে পারবে?
• API কি শুধু catalog নয়, checkout-ও ধরে?
• প্রথম দিনেই SEO, অনুবাদ আর অ্যানালিটিক্সের কী হবে?
• এক বছরের হিসাবটা নিজের সংখ্যা দিয়ে কষলে পুরো headless কি এখনও hybrid-এর চেয়ে এগিয়ে থাকে?

এবার সেই সোমবারের মিটিংয়ে ফিরি। ই-কমার্স প্রধান এখন এক পাতার উত্তর নিয়ে ঢোকেন: একটাই website, নিজস্ব frontend টিম নেই, থিমের 14,000-এর জায়গায় বছরে 242,000-এর বিল, আর বোর্ড যে app চায় তার জন্য API খুলে দেওয়ার পরিকল্পনা। ১৪ মাসের প্রস্তাব ছোট হয়ে দাঁড়ায় একটা ক্যাম্পেইন পেজ আর বর্তমান API-র ওপর একটা mobile app-এ, আর প্রথম মাসের বাজেট যায় ছবির ওজন কমানো আর checkout দ্রুত করায়।

মূল কথা

• Headless একটা আর্কিটেকচারের সিদ্ধান্ত, যার চলতি খরচ স্থায়ী: frontend টিম, হোস্টিং, দুটো pipeline, আর SEO, অনুবাদ ও অ্যানালিটিক্সের সেই কাজ, যা আগে বিনা খরচে পেতেন। কাল্পনিক হিসাবে সেটা বছরে 242,000, থিমের 14,000-এর বিপরীতে।
• এটা আপনা-আপনি দ্রুত নয়। Core Web Vitals ঠিক করে server রেন্ডারিং, ক্যাশিং আর হালকা JavaScript: ৭৫তম পার্সেন্টাইলে LCP ২.৫ সেকেন্ড বা কম, INP ২০০ ms বা কম, CLS ০.১ বা কম।
• একাধিক frontend, কাস্টম অভিজ্ঞতা, চরম traffic বা আগে থেকে থাকা frontend টিম থাকলে এটা পুষিয়ে দেয়।
• একটা website-এর জন্য all-in-one বা hybrid platform সাধারণত সস্তা, লঞ্চ করা দ্রুত, আর চালু ও ঠিকঠাক রাখা সহজ।
• এমন software বেছে নিন, যেখানে একই data-র ওপর বিল্ট-ইন স্টোরফ্রন্ট আর সম্পূর্ণ API দুটোই আছে, যাতে পরে মাইগ্রেশন ছাড়াই headless যোগ করা যায়।
• মাইগ্রেট করলে পেজ ধরে ধরে করুন, কাজের ফলব্যাক রেখে, আগে SEO বাঁচিয়ে, আর checkout সরান সবার শেষে।

আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।