টাইম টু ফার্স্ট বাইট মেট্রিকের জন্য কীভাবে অপ্টিমাইজ করতে হয় তা জানুন।
প্রকাশিত: ১৯ জানুয়ারি, ২০২৩, সর্বশেষ হালনাগাদ: ২৮ নভেম্বর, ২০২৫
টাইম টু ফার্স্ট বাইট (TTFB) হলো একটি মৌলিক ওয়েব পারফরম্যান্স মেট্রিক যা ফার্স্ট কনটেন্টফুল পেইন্ট (FCP) এবং লার্জেস্ট কনটেন্টফুল পেইন্ট (LCP)- এর মতো অন্যান্য সকল অর্থপূর্ণ ইউজার এক্সপেরিয়েন্স মেট্রিকের আগে আসে। এর অর্থ হলো, উচ্চ TTFB মান এর পরবর্তী মেট্রিকগুলোতে সময় যোগ করে।
এটি সুপারিশ করা হয় যে আপনার সার্ভার যেন নেভিগেশন অনুরোধগুলিতে যথেষ্ট দ্রুত সাড়া দেয়, যাতে ৭৫তম পার্সেন্টাইল ব্যবহারকারীরা "ভালো" থ্রেশহোল্ডের মধ্যে একটি FCP অনুভব করেন। একটি মোটামুটি নির্দেশিকা হিসাবে, বেশিরভাগ সাইটের ০.৮ সেকেন্ড বা তার কম TTFB রাখার চেষ্টা করা উচিত।
TTFB কীভাবে পরিমাপ করবেন
TTFB অপ্টিমাইজ করার আগে, এটি আপনার ওয়েবসাইটের ব্যবহারকারীদের কীভাবে প্রভাবিত করে তা আপনাকে পর্যবেক্ষণ করতে হবে। রিডাইরেক্টের কারণে TTFB কীভাবে প্রভাবিত হয়, তা পর্যবেক্ষণের প্রাথমিক উৎস হিসেবে আপনার ফিল্ড ডেটার উপর নির্ভর করা উচিত, যেখানে ল্যাব-ভিত্তিক টুলগুলো প্রায়শই চূড়ান্ত URL ব্যবহার করে পরিমাপ করা হয়, ফলে এই অতিরিক্ত বিলম্বটি বাদ পড়ে যায়।
পেজস্পিড ইনসাইটস হলো পাবলিক ওয়েবসাইটগুলোর ফিল্ড ও ল্যাব উভয় ধরনের তথ্য পাওয়ার একটি উপায়, যা ক্রোম ইউজার এক্সপেরিয়েন্স রিপোর্টে পাওয়া যায়।
প্রকৃত ব্যবহারকারীদের জন্য TTFB উপরের ' আপনার প্রকৃত ব্যবহারকারীরা কী অভিজ্ঞতা লাভ করছেন তা আবিষ্কার করুন' বিভাগে দেখানো হয়:
ল্যাব ডেটার ক্ষেত্রে, TTFB সমস্যাগুলো 'ডকুমেন্ট রিকোয়েস্ট ল্যাটেন্সি ইনসাইট'-এ দেখানো হয়:
মাঠ এবং ল্যাব উভয় ক্ষেত্রেই TTFB পরিমাপ করার আরও উপায় জানতে, TTFB মেট্রিক পৃষ্ঠাটি দেখুন ।
ফিল্ড ও ল্যাবের মধ্যে পার্থক্য বুঝুন TTFB
বিভিন্ন কারণে ল্যাব এবং ফিল্ডের TTFB ভিন্ন হতে পারে এবং যখন এই পার্থক্য দেখা যায়, তখন ব্যবহারকারীর অভিজ্ঞতা উন্নত করার জন্য ল্যাবের ডেটা কার্যকরভাবে ব্যবহার করতে হলে এর কারণ বোঝা জরুরি।
যখন ল্যাবের TTFB ফিল্ডের TTFB-এর চেয়ে অনেক বেশি হয়, তখন এটি নির্দেশ করে যে ল্যাবের পরিবেশ সাধারণ ব্যবহারকারীর অভিজ্ঞতার চেয়ে বেশি সীমাবদ্ধ। এটি অগত্যা কোনো সমস্যা নয়, কারণ ল্যাবের ফলাফল এবং সুপারিশগুলো তখনও বৈধ থাকে, তবে এটি প্রভাব এবং উন্নতির মাত্রা বাড়িয়ে দেখাতে পারে।
যখন ফিল্ড TTFB ল্যাব TTFB-এর চেয়ে অনেক বড় হয়, তখন এটি এমন কিছু সমস্যার ইঙ্গিত দেয় যা ল্যাব রানে স্পষ্ট হয় না, যেমন সার্ভার-সাইড ক্যাশিং, রিডাইরেক্ট বা নেটওয়ার্কের পার্থক্য। এই ক্ষেত্রে, ল্যাবের ফলাফল এবং সুপারিশগুলো তেমন কার্যকর নাও হতে পারে, কারণ সেগুলোতে মূল সমস্যাগুলোর একটি বাদ পড়ে যায়।
সার্ভার-সাইড ক্যাশিং ল্যাবের TTFB-কে প্রভাবিত করছে কিনা তা দেখতে, কম ব্যবহৃত পেজগুলো পরীক্ষা করে দেখুন অথবা আনক্যাশড কন্টেন্ট পাওয়ার জন্য ভিন্ন ভিন্ন URL প্যারামিটার ব্যবহার করুন, যাতে বোঝা যায় যে এর TTFB ফিল্ডের TTFB-এর সাথে বেশি সামঞ্জস্যপূর্ণ হচ্ছে কিনা। কোনো নির্দিষ্ট URL প্যারামিটার দিয়ে সার্ভার-সাইড ক্যাশিং বাইপাস করার ক্ষমতা থাকাও সহায়ক হতে পারে। ক্যাশড কন্টেন্ট সেকশনটি দেখুন।
রিডাইরেক্ট এবং নেটওয়ার্কের পার্থক্যের ক্ষেত্রে, আমাদের সাইটে কীভাবে এবং কোথা থেকে ট্র্যাফিক আসছে তার অ্যানালিটিক্স, এগুলি সম্ভাব্য সমস্যা কিনা তা নির্ণয় করতে সহায়ক হতে পারে।
Server-Timing ব্যবহার করে ফিল্ডে উচ্চ TTFB ডিবাগ করুন।
আপনার অ্যাপ্লিকেশনের ব্যাকএন্ডে উচ্চ লেটেন্সির কারণ হতে পারে এমন স্বতন্ত্র ব্যাকএন্ড প্রসেসগুলো পরিমাপ করার জন্য Server-Timing রেসপন্স হেডারটি ব্যবহার করা যেতে পারে। হেডার ভ্যালুর গঠনটি নমনীয়, যা ন্যূনতমভাবে আপনার সংজ্ঞায়িত একটি হ্যান্ডেল গ্রহণ করে। ঐচ্ছিক ভ্যালুগুলোর মধ্যে রয়েছে একটি ডিউরেশন ভ্যালু ( dur এর মাধ্যমে), এবং একটি ঐচ্ছিক পাঠযোগ্য বিবরণ ( desc এর মাধ্যমে)।
Serving-Timing ব্যবহার করে অনেক অ্যাপ্লিকেশন ব্যাকএন্ড প্রসেস পরিমাপ করা যায়, তবে এমন কিছু প্রসেস আছে যেগুলোর প্রতি আপনার বিশেষ মনোযোগ দেওয়া উচিত:
- ডাটাবেস কোয়েরি
- সার্ভার-সাইড রেন্ডারিং সময়, যদি প্রযোজ্য হয়
- ডিস্ক অনুসন্ধান করে
- এজ সার্ভার ক্যাশে হিট বা মিস (যদি CDN ব্যবহার করা হয়)
একটি Server-Timing এন্ট্রির সমস্ত অংশ কোলন দ্বারা পৃথক করা হয়, এবং একাধিক এন্ট্রি কমা দ্বারা পৃথক করা যেতে পারে:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
আপনার অ্যাপ্লিকেশন ব্যাকএন্ডের পছন্দের ভাষা ব্যবহার করে হেডারটি সেট করা যেতে পারে। উদাহরণস্বরূপ, PHP-তে আপনি হেডারটি এইভাবে সেট করতে পারেন:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
এই হেডারটি সেট করা হলে, এমন তথ্য প্রদর্শিত হয় যা আপনি ল্যাব এবং ফিল্ড উভয় ক্ষেত্রেই ব্যবহার করতে পারবেন।
এই ক্ষেত্রে, Server-Timing রেসপন্স হেডার সেট করা যেকোনো পৃষ্ঠা Navigation Timing API- এর serverTiming প্রপার্টিটি পূরণ করে:
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
ল্যাবে, Server-Timing রেসপন্স হেডার থেকে প্রাপ্ত ডেটা ক্রোম ডেভটুলস-এর নেটওয়ার্ক ট্যাবের টাইমিংস প্যানেলে প্রদর্শন করা হয়:
এখানে, কোনো রিসোর্সের জন্য করা অনুরোধ সিডিএন ক্যাশে পৌঁছেছে কিনা, এবং অনুরোধটি সিডিএন-এর এজ সার্ভার ও তারপর অরিজিনে পৌঁছাতে কতক্ষণ সময় লাগে, তা পরিমাপ করতে Server-Timing ব্যবহার করা হয়।
ক্রোম ডেভটুলস-এর পারফরম্যান্স প্যানেলের নেটওয়ার্ক ট্র্যাকেও সার্ভারের সময়সূচী দেখা যায়:
উপলব্ধ ডেটা বিশ্লেষণ করে একবার আপনি নিশ্চিত হয়ে গেলে যে আপনার TTFB-তে সমস্যা আছে, তখন আপনি সমস্যাটি সমাধানের দিকে এগোতে পারেন।
TTFB অপ্টিমাইজ করার উপায়
TTFB অপ্টিমাইজ করার সবচেয়ে কঠিন দিকটি হলো, ওয়েবের ফ্রন্টএন্ড স্ট্যাক সবসময় HTML, CSS, এবং JavaScript হলেও, ব্যাকএন্ড স্ট্যাকগুলো উল্লেখযোগ্যভাবে ভিন্ন হতে পারে। অসংখ্য ব্যাকএন্ড স্ট্যাক এবং ডেটাবেস প্রোডাক্ট রয়েছে, যেগুলোর প্রত্যেকটির নিজস্ব অপ্টিমাইজেশন কৌশল আছে। তাই, এই গাইডটি শুধুমাত্র স্ট্যাক-নির্দিষ্ট নির্দেশনার উপর মনোযোগ না দিয়ে, বেশিরভাগ আর্কিটেকচারের জন্য যা প্রযোজ্য তার উপর আলোকপাত করে।
প্ল্যাটফর্ম-নির্দিষ্ট নির্দেশিকা
আপনার ওয়েবসাইটের জন্য ব্যবহৃত প্ল্যাটফর্মটি TTFB-কে ব্যাপকভাবে প্রভাবিত করতে পারে। উদাহরণস্বরূপ, ওয়ার্ডপ্রেসের পারফরম্যান্স প্লাগইনের সংখ্যা ও গুণমান, অথবা ব্যবহৃত থিমের উপর নির্ভর করে। অন্যান্য প্ল্যাটফর্মগুলোও একইভাবে প্রভাবিত হয় যখন সেগুলোকে কাস্টমাইজ করা হয়। এই পোস্টে দেওয়া সাধারণ পারফরম্যান্স সংক্রান্ত পরামর্শের পাশাপাশি, ভেন্ডর-নির্দিষ্ট পরামর্শের জন্য আপনার প্ল্যাটফর্মের ডকুমেন্টেশন দেখা উচিত। লাইটহাউস ইনসাইটে কিছু সীমিত স্ট্যাক-নির্দিষ্ট নির্দেশনাও অন্তর্ভুক্ত রয়েছে।
হোস্টিং, হোস্টিং, হোস্টিং
অন্যান্য অপ্টিমাইজেশন পদ্ধতি বিবেচনা করার আগেই, হোস্টিং-ই আপনার প্রথম বিবেচ্য বিষয় হওয়া উচিত। এক্ষেত্রে খুব বেশি নির্দিষ্ট নির্দেশনা দেওয়া সম্ভব নয়, তবে একটি সাধারণ নিয়ম হলো, আপনার ওয়েবসাইটের হোস্ট যেন এতে পাঠানো ট্র্যাফিক সামলাতে সক্ষম হয়, তা নিশ্চিত করা।
শেয়ার্ড হোস্টিং সাধারণত ধীরগতির হয়। যদি আপনি একটি ছোট ব্যক্তিগত ওয়েবসাইট চালান যেখানে বেশিরভাগই স্ট্যাটিক ফাইল থাকে, তবে সম্ভবত এতে কোনো সমস্যা নেই। আপনার TTFB (টাইম টু ফেস) যতটা সম্ভব কমাতে নিচে দেওয়া অপটিমাইজেশন কৌশলগুলো ব্যবহার করুন।
তবে, যদি আপনি অনেক ব্যবহারকারী সহ একটি বড় অ্যাপ্লিকেশন চালান যেখানে পার্সোনালাইজেশন, ডাটাবেস কোয়েরি এবং অন্যান্য নিবিড় সার্ভার-সাইড অপারেশন জড়িত থাকে, তাহলে ফিল্ডে TTFB কমানোর জন্য আপনার হোস্টিংয়ের পছন্দ অত্যন্ত গুরুত্বপূর্ণ হয়ে ওঠে।
হোস্টিং প্রোভাইডার বেছে নেওয়ার সময় এই বিষয়গুলো খেয়াল রাখা উচিত:
- আপনার অ্যাপ্লিকেশন ইনস্ট্যান্সের জন্য কী পরিমাণ মেমরি বরাদ্দ করা হয়েছে? যদি আপনার অ্যাপ্লিকেশনে অপর্যাপ্ত মেমরি থাকে, তবে এটি থ্র্যাশ করবে এবং যত দ্রুত সম্ভব পেজগুলো পরিবেশন করতে হিমশিম খাবে।
- আপনার হোস্টিং প্রোভাইডার কি আপনার ব্যাকএন্ড স্ট্যাক আপ-টু-ডেট রাখে? অ্যাপ্লিকেশন ব্যাকএন্ড ল্যাঙ্গুয়েজ, HTTP ইমপ্লিমেন্টেশন এবং ডাটাবেস সফটওয়্যারের নতুন সংস্করণ প্রকাশিত হওয়ার সাথে সাথে সময়ের সাথে সাথে সেই সফটওয়্যারের পারফরম্যান্স উন্নত হয়। এমন একটি হোস্টিং প্রোভাইডারের সাথে কাজ করা অত্যন্ত গুরুত্বপূর্ণ, যারা এই ধরনের জরুরি রক্ষণাবেক্ষণকে অগ্রাধিকার দেয়।
- আপনার যদি খুব নির্দিষ্ট অ্যাপ্লিকেশন সংক্রান্ত চাহিদা থাকে এবং সার্ভার কনফিগারেশন ফাইলগুলিতে সর্বনিম্ন স্তরের অ্যাক্সেস চান, তাহলে আপনার নিজের অ্যাপ্লিকেশন ইনস্ট্যান্সের ব্যাকএন্ড কাস্টমাইজ করা যুক্তিযুক্ত হবে কিনা তা জিজ্ঞাসা করে দেখুন।
এমন অনেক হোস্টিং প্রোভাইডার আছে যারা আপনার জন্য এই বিষয়গুলোর খেয়াল রাখে, কিন্তু আপনি যদি ডেডিকেটেড হোস্টিং প্রোভাইডারদের ক্ষেত্রেও দীর্ঘ TTFB মান লক্ষ্য করতে শুরু করেন, তবে এটি একটি ইঙ্গিত হতে পারে যে আপনাকে আপনার বর্তমান হোস্টিং প্রোভাইডারের সক্ষমতা পুনর্মূল্যায়ন করতে হবে, যাতে আপনি সর্বোত্তম ব্যবহারকারী অভিজ্ঞতা প্রদান করতে পারেন।
কন্টেন্ট ডেলিভারি নেটওয়ার্ক (CDN) ব্যবহার করুন
CDN ব্যবহারের বিষয়টি বেশ আলোচিত, এবং এর পেছনে যথেষ্ট কারণও রয়েছে: আপনার অ্যাপ্লিকেশনের ব্যাকএন্ড খুব ভালোভাবে অপ্টিমাইজ করা থাকলেও, আপনার অরিজিন সার্ভার থেকে দূরে অবস্থিত ব্যবহারকারীরা কর্মক্ষেত্রে উচ্চ TTFB (টাইম টু ফেস) অনুভব করতে পারেন।
সিডিএন (CDN) আপনার অরিজিন সার্ভার থেকে ব্যবহারকারীর নৈকট্যের সমস্যা সমাধান করে। এটি এমন একটি ডিস্ট্রিবিউটেড সার্ভার নেটওয়ার্ক ব্যবহার করে, যা ব্যবহারকারীদের ভৌতিকভাবে নিকটবর্তী সার্ভারগুলোতে রিসোর্স ক্যাশ করে রাখে। এই সার্ভারগুলোকে এজ সার্ভার (edge servers) বলা হয়।
সিডিএন প্রোভাইডাররা এজ সার্ভার ছাড়াও অন্যান্য সুবিধাও দিতে পারে:
- সিডিএন প্রোভাইডাররা সাধারণত অত্যন্ত দ্রুত ডিএনএস রেজোলিউশন টাইম অফার করে থাকে।
- একটি CDN সম্ভবত HTTP/2 বা HTTP/3-এর মতো আধুনিক প্রোটোকল ব্যবহার করে এজ সার্ভার থেকে আপনার কন্টেন্ট পরিবেশন করে।
- বিশেষ করে HTTP/3, UDP প্রোটোকল ব্যবহারের মাধ্যমে TCP-তে বিদ্যমান হেড-অফ-লাইন ব্লকিং সমস্যার সমাধান করে (যার উপর HTTP/2 নির্ভর করে)।
- একটি CDN সম্ভবত TLS-এর আধুনিক সংস্করণগুলো সরবরাহ করে, যা TLS নেগোসিয়েশনের সাথে জড়িত ল্যাটেন্সি কমিয়ে দেয়। বিশেষ করে TLS 1.3-কে এমনভাবে ডিজাইন করা হয়েছে যাতে TLS নেগোসিয়েশন যতটা সম্ভব সংক্ষিপ্ত রাখা যায়।
- কিছু CDN প্রোভাইডার 'এজ ওয়ার্কার' নামে একটি ফিচার দিয়ে থাকে, যা সার্ভিস ওয়ার্কার API- এর অনুরূপ একটি API ব্যবহার করে রিকোয়েস্ট ইন্টারসেপ্ট করতে, প্রোগ্রাম্যাটিকভাবে এজ ক্যাশে রেসপন্স ম্যানেজ করতে, অথবা রেসপন্স পুরোপুরি রিরাইট করতে পারে।
- সিডিএন প্রোভাইডাররা কম্প্রেশন অপ্টিমাইজ করার ক্ষেত্রে খুবই দক্ষ। নিজে থেকে কম্প্রেশন সঠিকভাবে করা বেশ কঠিন, এবং ডাইনামিকভাবে তৈরি হওয়া মার্কআপের ক্ষেত্রে এটি কিছু কিছু ক্ষেত্রে প্রতিক্রিয়ার সময় কমিয়ে দিতে পারে, কারণ সেগুলোকে চলার পথেই কম্প্রেস করতে হয়।
- এছাড়াও, সিডিএন প্রোভাইডাররা স্ট্যাটিক রিসোর্সগুলোর জন্য কম্প্রেসড রেসপন্স স্বয়ংক্রিয়ভাবে ক্যাশ করে রাখে, যার ফলে কম্প্রেশন রেশিও এবং রেসপন্স টাইমের সেরা সমন্বয় পাওয়া যায়।
যদিও একটি CDN গ্রহণ করার জন্য সামান্য থেকে উল্লেখযোগ্য পর্যন্ত বিভিন্ন পরিমাণ প্রচেষ্টার প্রয়োজন হয়, আপনার ওয়েবসাইটটি যদি ইতিমধ্যেই এটি ব্যবহার না করে থাকে, তবে আপনার TTFB অপ্টিমাইজ করার ক্ষেত্রে এটিকে একটি উচ্চ অগ্রাধিকার দেওয়া উচিত।
যেখানে সম্ভব ক্যাশ করা কন্টেন্ট ব্যবহার করুন।
সিডিএন দর্শকদের ভৌতিকভাবে নিকটবর্তী এজ সার্ভারে কন্টেন্ট ক্যাশ করার সুযোগ দেয়, তবে শর্ত হলো কন্টেন্টটি যথাযথ Cache-Control HTTP হেডার দিয়ে কনফিগার করা থাকতে হবে। যদিও এটি ব্যক্তিগতকৃত কন্টেন্টের জন্য উপযুক্ত নয়, তবে একেবারে অরিজিনে ফিরে যাওয়ার প্রয়োজন একটি সিডিএন-এর অনেক উপযোগিতাকেই নষ্ট করে দিতে পারে।
যেসব সাইট ঘন ঘন তাদের কন্টেন্ট আপডেট করে, তাদের জন্য স্বল্প সময়ের ক্যাশিংও ব্যস্ত সাইটগুলোতে পারফরম্যান্সে লক্ষণীয় উন্নতি ঘটাতে পারে। কারণ, ওই সময়ে শুধুমাত্র প্রথম ভিজিটরকেই অরিজিন সার্ভারে ফিরে যাওয়ার সম্পূর্ণ ল্যাটেন্সি অনুভব করতে হয়, আর বাকি সব ভিজিটর এজ সার্ভার থেকে ক্যাশ করা রিসোর্সটি পুনরায় ব্যবহার করতে পারে। কিছু CDN সাইট রিলিজের সময় ক্যাশ ইনভ্যালিডেশনের সুবিধা দেয়, যা উভয় দিকের সেরা সুবিধাই প্রদান করে—দীর্ঘ ক্যাশ টাইম, কিন্তু প্রয়োজনে তাৎক্ষণিক আপডেট।
যেখানে ক্যাশিং সঠিকভাবে কনফিগার করা থাকে, সেখানেও অ্যানালিটিক্স পরিমাপের জন্য অনন্য কোয়েরি স্ট্রিং প্যারামিটার ব্যবহারের মাধ্যমে এটিকে উপেক্ষা করা যেতে পারে। একই হওয়া সত্ত্বেও এগুলি CDN-এর কাছে ভিন্ন কন্টেন্ট হিসেবে প্রতীয়মান হতে পারে, এবং এর ফলে ক্যাশ করা সংস্করণটি ব্যবহৃত হবে না।
পুরোনো বা কম ভিজিট করা কন্টেন্টও ক্যাশ নাও হতে পারে, যার ফলে কিছু পেজে অন্যগুলোর তুলনায় TTFB ভ্যালু বেশি হতে পারে। ক্যাশিং টাইম বাড়ালে এর প্রভাব কমানো যায়, কিন্তু মনে রাখতে হবে যে ক্যাশিং টাইম বাড়ার সাথে সাথে পুরোনো বা বাসি কন্টেন্ট পরিবেশনের সম্ভাবনাও বেড়ে যায়।
ক্যাশ করা কন্টেন্টের প্রভাব শুধু সিডিএন ব্যবহারকারীদের মধ্যেই সীমাবদ্ধ নয়। যখন ক্যাশ করা কন্টেন্ট পুনরায় ব্যবহার করা যায় না, তখন সার্ভার পরিকাঠামোকে ব্যয়বহুল ডাটাবেস অনুসন্ধানের মাধ্যমে কন্টেন্ট তৈরি করতে হতে পারে। অধিক ব্যবহৃত ডেটা বা প্রি-ক্যাশ করা পেজগুলো প্রায়শই আরও ভালোভাবে কাজ করে।
একাধিক পৃষ্ঠা পুনঃনির্দেশ এড়িয়ে চলুন
উচ্চ TTFB-এর একটি সাধারণ কারণ হলো রিডাইরেক্ট । যখন কোনো ডকুমেন্টের জন্য করা নেভিগেশন অনুরোধ এমন একটি প্রতিক্রিয়া পায় যা ব্রাউজারকে জানায় যে রিসোর্সটি অন্য কোনো স্থানে অবস্থিত, তখন রিডাইরেক্ট ঘটে। একটি রিডাইরেক্ট অবশ্যই একটি নেভিগেশন অনুরোধে অনাকাঙ্ক্ষিত বিলম্ব যোগ করতে পারে, কিন্তু পরিস্থিতি আরও খারাপ হতে পারে যদি সেই রিডাইরেক্টটি এমন অন্য কোনো রিসোর্সের দিকে নির্দেশ করে যার ফলে আরেকটি রিডাইরেক্ট হয়—এবং এই প্রক্রিয়া চলতেই থাকে। এটি বিশেষ করে সেইসব সাইটকে প্রভাবিত করতে পারে যারা বিজ্ঞাপন বা নিউজলেটার থেকে প্রচুর পরিমাণে ভিজিটর পায়, কারণ তারা প্রায়শই পরিমাপের উদ্দেশ্যে অ্যানালিটিক্স পরিষেবার মাধ্যমে রিডাইরেক্ট করে। আপনার সরাসরি নিয়ন্ত্রণে থাকা রিডাইরেক্টগুলো দূর করা একটি ভালো TTFB অর্জনে সহায়তা করতে পারে।
রিডাইরেক্ট দুই প্রকারের হয়:
- সেম-অরিজিন রিডাইরেক্ট , যেখানে রিডাইরেক্টটি সম্পূর্ণরূপে আপনার ওয়েবসাইটে ঘটে।
- ক্রস-অরিজিন রিডাইরেক্ট হলো এমন একটি প্রক্রিয়া, যেখানে আপনার ওয়েবসাইটে আসার আগে রিডাইরেক্টটি প্রাথমিকভাবে অন্য কোনো অরিজিনে ঘটে—যেমন, উদাহরণস্বরূপ, কোনো সোশ্যাল মিডিয়া ইউআরএল শর্টেনিং সার্ভিস থেকে।
সেম-অরিজিন রিডাইরেক্ট দূর করার দিকে মনোযোগ দিন, কারণ এটি এমন একটি বিষয় যার উপর আপনার সরাসরি নিয়ন্ত্রণ রয়েছে। এর জন্য আপনার ওয়েবসাইটের লিঙ্কগুলো পরীক্ষা করে দেখতে হবে যে সেগুলোর কোনোটির ফলে 302 বা 301 রেসপন্স কোড আসছে কিনা। প্রায়শই এর কারণ হতে পারে https:// স্কিমটি অন্তর্ভুক্ত না করা (যার ফলে ব্রাউজারগুলো ডিফল্টভাবে http:// ব্যবহার করে, যা পরে রিডাইরেক্ট করে) অথবা URL-এর শেষে স্ল্যাশ সঠিকভাবে অন্তর্ভুক্ত বা বাদ না দেওয়া।
ক্রস-অরিজিন রিডাইরেক্টগুলো আরও জটিল, কারণ এগুলো প্রায়শই আপনার নিয়ন্ত্রণের বাইরে থাকে, কিন্তু যেখানে সম্ভব একাধিক রিডাইরেক্ট এড়িয়ে চলার চেষ্টা করুন—উদাহরণস্বরূপ, লিঙ্ক শেয়ার করার সময় একাধিক লিঙ্ক শর্টনার ব্যবহার করে। বিজ্ঞাপনদাতা বা নিউজলেটারকে দেওয়া URL-টি যেন সঠিক চূড়ান্ত URL হয়, তা নিশ্চিত করুন, যাতে ঐ পরিষেবাগুলো দ্বারা ব্যবহৃত রিডাইরেক্টগুলোর সাথে আরেকটি রিডাইরেক্ট যুক্ত না হয়।
রিডাইরেক্ট টাইমের আরেকটি গুরুত্বপূর্ণ উৎস হতে পারে HTTP-থেকে-HTTPS রিডাইরেক্ট। এটি এড়ানোর একটি উপায় হলো Strict-Transport-Security হেডার (HSTS) ব্যবহার করা, যা কোনো অরিজিনে প্রথমবার প্রবেশের সময় HTTPS প্রয়োগ করে এবং পরবর্তী সময়ে ব্রাউজারকে অবিলম্বে HTTPS স্কিমের মাধ্যমে অরিজিনটি অ্যাক্সেস করতে নির্দেশ দেয়।
আপনার একটি ভালো HSTS পলিসি চালু হয়ে গেলে, HSTS প্রিলোড লিস্টে আপনার সাইটটি যোগ করার মাধ্যমে আপনি কোনো অরিজিনে প্রথমবার ভিজিটের গতি বাড়াতে পারেন।
ব্রাউজারে মার্কআপ স্ট্রিম করুন
ব্রাউজারগুলো স্ট্রিম করা মার্কআপ দক্ষতার সাথে প্রসেস করার জন্য অপ্টিমাইজ করা থাকে, যার অর্থ হলো সার্ভার থেকে আসার সাথে সাথে মার্কআপকে খণ্ড খণ্ড করে পরিচালনা করা হয়। বড় আকারের মার্কআপ পেলোডের ক্ষেত্রে এটি অত্যন্ত গুরুত্বপূর্ণ, কারণ এর ফলে ব্রাউজার পুরো রেসপন্সটি আসার জন্য অপেক্ষা না করে, মার্কআপের খণ্ডগুলোকে পর্যায়ক্রমে পার্স করতে পারে।
যদিও ব্রাউজারগুলো স্ট্রিমিং মার্কআপ পরিচালনায় বেশ পারদর্শী, তবুও সেই প্রবাহ সচল রাখতে আপনার পক্ষে যা যা করা সম্ভব, তার সবই করা অত্যন্ত জরুরি, যাতে মার্কআপের প্রাথমিক অংশগুলো যত দ্রুত সম্ভব পৌঁছে যায়। যদি ব্যাকএন্ড সবকিছু আটকে রাখে, তবে তা একটি সমস্যা। যেহেতু ব্যাকএন্ড স্ট্যাকের সংখ্যা অনেক, তাই প্রতিটি স্ট্যাক এবং সেগুলোর প্রত্যেকটিতে উদ্ভূত হতে পারে এমন সমস্যাগুলো এই নির্দেশিকায় আলোচনা করা সম্ভব নয়।
উদাহরণস্বরূপ, React—এবং অন্যান্য ফ্রেমওয়ার্ক যা সার্ভারে চাহিদা অনুযায়ী মার্কআপ রেন্ডার করতে পারে—সার্ভার-সাইড রেন্ডারিংয়ের জন্য একটি সিনক্রোনাস পদ্ধতি ব্যবহার করেছে। তবে, React-এর নতুন সংস্করণগুলোতে রেন্ডার হওয়ার সময়েই মার্কআপ স্ট্রিমিং করার জন্য সার্ভার মেথড প্রয়োগ করা হয়েছে। এর মানে হলো, রেসপন্স পাঠানোর আগে সম্পূর্ণ রেসপন্সটি রেন্ডার করার জন্য আপনাকে React সার্ভার API মেথডের অপেক্ষা করতে হবে না।
ব্রাউজারে মার্কআপ দ্রুত স্ট্রিম করা নিশ্চিত করার আরেকটি উপায় হলো স্ট্যাটিক রেন্ডারিংয়ের ওপর নির্ভর করা, যা বিল্ড টাইমে HTML ফাইল তৈরি করে। সম্পূর্ণ ফাইলটি তাৎক্ষণিকভাবে উপলব্ধ থাকায়, ওয়েব সার্ভারগুলো সঙ্গে সঙ্গে ফাইলটি পাঠানো শুরু করতে পারে এবং HTTP-এর অন্তর্নিহিত প্রকৃতির ফলেই মার্কআপ স্ট্রিম হয়। যদিও এই পদ্ধতিটি প্রতিটি ওয়েবসাইটের প্রতিটি পৃষ্ঠার জন্য উপযুক্ত নয়—যেমন ব্যবহারকারীর অভিজ্ঞতার অংশ হিসেবে ডাইনামিক রেসপন্স প্রয়োজন এমন পৃষ্ঠাগুলোর ক্ষেত্রে—তবে এটি সেইসব পৃষ্ঠার জন্য উপকারী হতে পারে, যেগুলোর মার্কআপ কোনো নির্দিষ্ট ব্যবহারকারীর জন্য ব্যক্তিগতকৃত করার প্রয়োজন হয় না।
একজন পরিষেবা কর্মী ব্যবহার করুন
সার্ভিস ওয়ার্কার এপিআই ডকুমেন্ট এবং সেগুলোর দ্বারা লোড হওয়া রিসোর্স উভয়েরই TTFB-এর উপর বড় ধরনের প্রভাব ফেলতে পারে। এর কারণ হলো, একটি সার্ভিস ওয়ার্কার ব্রাউজার এবং সার্ভারের মধ্যে প্রক্সি হিসেবে কাজ করে—কিন্তু আপনার ওয়েবসাইটের TTFB-এর উপর এর কোনো প্রভাব পড়বে কি না, তা নির্ভর করে আপনি আপনার সার্ভিস ওয়ার্কারটি কীভাবে সেট আপ করেছেন এবং সেই সেটআপটি আপনার অ্যাপ্লিকেশনের প্রয়োজনীয়তার সাথে সামঞ্জস্যপূর্ণ কি না, তার উপর।
- অ্যাসেটের জন্য একটি স্টেল-হোয়াইল-রিভ্যালিডেট স্ট্র্যাটেজি ব্যবহার করুন। যদি কোনো অ্যাসেট সার্ভিস ওয়ার্কার ক্যাশে থাকে, তা একটি ডকুমেন্ট হোক বা ডকুমেন্টটির প্রয়োজনীয় কোনো রিসোর্স হোক, স্টেল-হোয়াইল-রিভ্যালিডেট স্ট্র্যাটেজিটি প্রথমে ক্যাশ থেকে সেই রিসোর্সটি সার্ভিস করে, তারপর ব্যাকগ্রাউন্ডে সেই অ্যাসেটটি ডাউনলোড করে এবং ভবিষ্যতের ইন্টারঅ্যাকশনের জন্য ক্যাশ থেকে তা পরিবেশন করে।
- আপনার ডকুমেন্ট রিসোর্সগুলো যদি খুব ঘন ঘন পরিবর্তিত না হয়, তাহলে ‘স্টেল-হোয়াইল-রিভ্যালিডেট’ কৌশল ব্যবহার করে একটি পেজের TTFB (টার্নথ্রু টাইম) প্রায় তাৎক্ষণিক করা সম্ভব। তবে, আপনার ওয়েবসাইট যদি ডাইনামিকভাবে তৈরি মার্কআপ পাঠায়—যেমন এমন মার্কআপ যা ব্যবহারকারী অথেনটিকেটেড কি না তার উপর ভিত্তি করে পরিবর্তিত হয়—তাহলে এই পদ্ধতিটি তেমন কার্যকর হয় না। এই ধরনের ক্ষেত্রে, ডকুমেন্টটি যাতে যথাসম্ভব সতেজ থাকে, সেজন্য আপনি সবসময় প্রথমে নেটওয়ার্ক থেকে ডেটা নিতে চাইবেন।
- যদি আপনার ডকুমেন্ট এমন সব নন-ক্রিটিক্যাল রিসোর্স লোড করে যা মাঝে মাঝে পরিবর্তিত হয়, কিন্তু পুরনো রিসোর্স ফেচ করা ব্যবহারকারীর অভিজ্ঞতায় খুব বেশি প্রভাব ফেলে না—যেমন কিছু নির্দিষ্ট ছবি বা অন্যান্য নন-ক্রিটিক্যাল রিসোর্স—তাহলে 'স্টেল-হোয়াইল-রিভ্যালিডেট' কৌশল ব্যবহার করে সেই রিসোর্সগুলোর TTFB (টাইম টু ফেস) উল্লেখযোগ্যভাবে কমানো যেতে পারে।
- ক্লায়েন্ট-রেন্ডারড অ্যাপ্লিকেশনগুলির জন্য অ্যাপ শেল মডেল ব্যবহার করুন। এই মডেলটি এসপিএ-গুলির (SPA) জন্য সবচেয়ে উপযুক্ত, যেখানে পেজের "শেল" সার্ভিস ওয়ার্কার ক্যাশে থেকে তাৎক্ষণিকভাবে সরবরাহ করা যায় এবং পেজের ডায়নামিক কন্টেন্ট পেজ লাইফসাইকেলের পরবর্তী পর্যায়ে পপুলেট ও রেন্ডার করা হয়।
রেন্ডার-ক্রিটিক্যাল রিসোর্সগুলির জন্য 103 Early Hints ব্যবহার করুন
আপনার অ্যাপ্লিকেশনের ব্যাকএন্ড যতই ভালোভাবে অপ্টিমাইজ করা হোক না কেন, একটি প্রতিক্রিয়া প্রস্তুত করার জন্য সার্ভারকে তখনও উল্লেখযোগ্য পরিমাণ কাজ করতে হতে পারে। এর মধ্যে ব্যয়বহুল (কিন্তু প্রয়োজনীয়) ডাটাবেসের কাজও অন্তর্ভুক্ত, যা নেভিগেশন প্রতিক্রিয়াটিকে যতটা দ্রুত আসা উচিত ছিল, ততটা আসতে বিলম্ব ঘটায়। এর সম্ভাব্য প্রভাব হলো, পরবর্তী কিছু রেন্ডার-গুরুত্বপূর্ণ রিসোর্স, যেমন CSS অথবা—কিছু ক্ষেত্রে—জাভাস্ক্রিপ্ট যা ক্লায়েন্টে মার্কআপ রেন্ডার করে, সেগুলোর লোড হতে দেরি হতে পারে।
103 Early Hints হেডার হলো একটি আর্লি রেসপন্স কোড, যা সার্ভার ব্রাউজারে পাঠাতে পারে যখন ব্যাকএন্ড মার্কআপ প্রস্তুত করতে ব্যস্ত থাকে। এই হেডারটি ব্রাউজারকে ইঙ্গিত দিতে ব্যবহার করা যেতে পারে যে, মার্কআপ প্রস্তুত হওয়ার সময়েই পেজটির জন্য রেন্ডার-ক্রিটিক্যাল রিসোর্স ডাউনলোড করা শুরু করা উচিত। সাপোর্টিং ব্রাউজারগুলোর ক্ষেত্রে এর ফলে ডকুমেন্ট (CSS) দ্রুত রেন্ডার হয় এবং পেজ আরও দ্রুত লোড হয়।
103 আর্লি হিন্টস-এর একটি অসুবিধা হলো, ক্যাশিং-এর মতোই, এটি একটি সাইটের "প্রকৃত" TTFB (টাইম টু সার্ভার টাইম) আড়াল করতে পারে। যদি কোনো সার্ভার পরিকাঠামো ধীরগতির হয় (হয় এটি কম শক্তিশালী হওয়ার কারণে অথবা কোডটি অপ্টিমাইজ করার প্রয়োজন হলে), তাহলে 103 আর্লি হিন্টস ব্যবহার করলে বিষয়টি ততটা স্পষ্ট নাও হতে পারে, কারণ TTFB দ্রুত দেখায়। যেসব সাইট 103 আর্লি হিন্টস ব্যবহার করে, তাদের উচিত প্রকৃত সার্ভার সময় পরিমাপ করার কথা বিবেচনা করা ( Server-Timing অথবা PerformanceNavigationTiming API- এর finalResponseHeadersStart মাধ্যমে)।
উপসংহার
যেহেতু ব্যাকএন্ড অ্যাপ্লিকেশন স্ট্যাকের অনেক রকম সংমিশ্রণ রয়েছে, তাই এমন কোনো একটি আর্টিকেল নেই যা আপনার ওয়েবসাইটের TTFB কমানোর জন্য করণীয় সবকিছুকে অন্তর্ভুক্ত করতে পারে। তবে, সার্ভার সাইডে কাজগুলোকে আরেকটু দ্রুত করার জন্য এখানে কিছু উপায় দেওয়া হলো যা আপনি চেষ্টা করে দেখতে পারেন।
প্রতিটি মেট্রিক অপ্টিমাইজ করার মতোই, এর পদ্ধতিও মূলত একই রকম: মাঠে আপনার TTFB পরিমাপ করুন, কারণগুলো গভীরভাবে খতিয়ে দেখতে ল্যাব টুল ব্যবহার করুন, এবং তারপর যেখানে সম্ভব সেখানে অপ্টিমাইজেশন প্রয়োগ করুন। যদিও কিছু কৌশল আপনার পরিস্থিতির জন্য কার্যকর নাও হতে পারে, তবে কিছু কৌশল সম্ভবত কার্যকর হবে। বরাবরের মতোই, আপনাকে আপনার ফিল্ড ডেটার উপর কড়া নজর রাখতে হবে এবং ব্যবহারকারীর জন্য দ্রুততম অভিজ্ঞতা নিশ্চিত করতে প্রয়োজন অনুযায়ী সমন্বয় করতে হবে।