Time to First Byte মেট্রিকের জন্য কীভাবে অপ্টিমাইজ করতে হয় তা জানুন।
প্রকাশিত: ১৯ জানুয়ারি, ২০২৩, শেষবার আপডেট করা হয়েছে: ২৮ নভেম্বর, ২০২৫
Time to First Byte (TTFB) হল একটি মৌলিক ওয়েব পারফর্ম্যান্স মেট্রিক যা First Contentful Paint (FCP) এবং Largest Contentful Paint (LCP)-এর মতো অন্যান্য প্রতিটি অর্থপূর্ণ ব্যবহারকারীর অভিজ্ঞতা মেট্রিকের আগে আসে। এর অর্থ হল, বেশি TTFB ভ্যালু থাকলে, এর পরে যে মেট্রিক আসে তাতে সময় যোগ হয়।
এটি সাজেস্ট করা হয় যে আপনার সার্ভার নেভিগেশন অনুরোধের উত্তর যথেষ্ট দ্রুত দেয় যাতে ৭৫তম পার্সেন্টাইল ব্যবহারকারী "ভাল" থ্রেশহোল্ডের মধ্যে FCP অভিজ্ঞতা পান। মোটামুটিভাবে, বেশিরভাগ সাইটের TTFB ০.৮ সেকেন্ড বা তার কম হওয়া উচিত।
TTFB কীভাবে পরিমাপ করা হয়
TTFB অপ্টিমাইজ করার আগে, এটি আপনার ওয়েবসাইটের ব্যবহারকারীদের উপর কীভাবে প্রভাব ফেলে তা আপনাকে লক্ষ্য করতে হবে। TTFB পর্যবেক্ষণ করার জন্য প্রাথমিক সোর্স হিসেবে আপনার ফিল্ড ডেটা-এর উপর নির্ভর করা উচিত, কারণ এটি রিডাইরেক্টের মাধ্যমে প্রভাবিত হয়, যেখানে ল্যাব-ভিত্তিক টুলগুলি প্রায়শই চূড়ান্ত URL ব্যবহার করে পরিমাপ করা হয়, তাই এই অতিরিক্ত বিলম্ব মিস হয়ে যায়।
Chrome ব্যবহারকারীর অভিজ্ঞতা সংক্রান্ত রিপোর্টে উপলভ্য সর্বজনীন ওয়েবসাইটের জন্য ফিল্ড ও ল্যাব সংক্রান্ত তথ্য পাওয়ার একটি উপায় হল PageSpeed Insights।
আসল ব্যবহারকারীদের জন্য 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 রেসপন্স হেডার সেট করা আছে এমন যেকোনও পৃষ্ঠা নেভিগেশন টাইমিং 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 রেসপন্স হেডার থেকে পাওয়া ডেটা Chrome DevTools-এর নেটওয়ার্ক ট্যাবের
টাইমিং প্যানেলে ভিজ্যুয়ালাইজ করা হয়:
এখানে, Server-Timing ব্যবহার করা হয় কোনও রিসোর্সের জন্য করা অনুরোধ CDN ক্যাশে হিট করেছে কিনা এবং অনুরোধটি CDN-এর এজ সার্ভার এবং তারপর অরিজিনে হিট করতে কত সময় নেয় তা পরিমাপ করতে।
Chrome DevTools-এর পারফর্ম্যান্স প্যানেলের নেটওয়ার্ক ট্র্যাকেও সার্ভার টাইমিং দেখানো হয়:
উপলভ্য ডেটা বিশ্লেষণ করে আপনি যদি দেখেন যে TTFB-তে সমস্যা আছে, তাহলে আপনি সমস্যাটি সমাধান করার জন্য পদক্ষেপ নিতে পারেন।
TTFB অপ্টিমাইজ করার উপায়
TTFB অপ্টিমাইজ করার সবচেয়ে চ্যালেঞ্জিং দিক হল, ওয়েবের ফ্রন্টএন্ড স্ট্যাক সবসময় HTML, CSS এবং JavaScript হলেও, ব্যাকএন্ড স্ট্যাক উল্লেখযোগ্যভাবে পরিবর্তিত হতে পারে। অনেক ব্যাকএন্ড স্ট্যাক এবং ডেটাবেস প্রোডাক্ট আছে, যার প্রত্যেকটির নিজস্ব অপ্টিমাইজেশন টেকনিক আছে। তাই, এই নির্দেশিকাটি স্ট্যাক-নির্দিষ্ট নির্দেশিকার উপর ফোকাস করার পরিবর্তে বেশিরভাগ আর্কিটেকচারের ক্ষেত্রে কী প্রযোজ্য তার উপর ফোকাস করে।
প্ল্যাটফর্ম-নির্দিষ্ট নির্দেশিকা
আপনার ওয়েবসাইটের জন্য যে প্ল্যাটফর্ম ব্যবহার করেন তা TTFB-এর উপর গভীর প্রভাব ফেলতে পারে। যেমন, প্লাগ-ইনের সংখ্যা ও কোয়ালিটি অথবা কোন থিম ব্যবহার করা হচ্ছে তার উপর WordPress-এর পারফর্ম্যান্স নির্ভর করে। প্ল্যাটফর্ম কাস্টমাইজ করা হলে, অন্যান্য প্ল্যাটফর্মও একইভাবে প্রভাবিত হয়। এই পোস্টে পারফর্ম্যান্স সংক্রান্ত সাধারণ পরামর্শের পাশাপাশি আপনার প্ল্যাটফর্মের ডকুমেন্টেশন থেকে ভেন্ডর-নির্দিষ্ট পরামর্শও দেখে নেওয়া উচিত। Lighthouse ইনসাইটে কিছু সীমিত স্ট্যাক-নির্দিষ্ট নির্দেশিকাও অন্তর্ভুক্ত থাকে।
হোস্টিং, হোস্টিং, হোস্টিং
অন্যান্য অপ্টিমাইজেশন পদ্ধতি বিবেচনা করার আগে, হোস্টিং আপনার প্রথম বিবেচনা করা উচিত। এই বিষয়ে নির্দিষ্ট কোনও নির্দেশিকা নেই, তবে সাধারণভাবে আপনার ওয়েবসাইটের হোস্ট যাতে আপনার পাঠানো ট্রাফিক ম্যানেজ করতে পারে তা নিশ্চিত করতে হবে।
শেয়ার্ড হোস্টিং সাধারণত স্লো হয়। আপনি যদি ছোট ব্যক্তিগত ওয়েবসাইট চালান যা মূলত স্ট্যাটিক ফাইল দেখায়, তাহলে এটি ঠিক আছে। আপনার TTFB যতটা সম্ভব কমাতে সাহায্য করার জন্য নিচে দেওয়া কিছু অপ্টিমাইজেশন কৌশল ব্যবহার করুন।
তবে, আপনি যদি অনেক ব্যবহারকারী সহ একটি বড় অ্যাপ্লিকেশন চালান যাতে পছন্দমতো সেট করা, ডেটাবেস কোয়েরি করা এবং অন্যান্য নিবিড় সার্ভার-সাইড অপারেশন অন্তর্ভুক্ত থাকে, তাহলে ফিল্ডে TTFB কমানোর জন্য আপনার হোস্টিংয়ের পছন্দ গুরুত্বপূর্ণ হয়ে ওঠে।
হোস্টিং প্রদানকারী বেছে নেওয়ার সময়, এইসব বিষয় মাথায় রাখবেন:
- আপনার অ্যাপ্লিকেশন ইনস্ট্যান্সের জন্য কতটা মেমরি বরাদ্দ করা হয়েছে? আপনার অ্যাপ্লিকেশনে পর্যাপ্ত মেমরি না থাকলে, এটি থ্র্যাশ করবে এবং যত দ্রুত সম্ভব পৃষ্ঠাগুলি পরিবেশন করার জন্য লড়াই করবে।
- আপনার হোস্টিং প্রদানকারী কি আপনার ব্যাকএন্ড স্ট্যাক আপ-টু-ডেট রাখে? অ্যাপ্লিকেশন ব্যাকএন্ড ভাষা, HTTP ইমপ্লিমেন্টেশন এবং ডেটাবেস সফ্টওয়্যারের নতুন ভার্সন রিলিজ হওয়ার সাথে সাথে, সময়ের সাথে সাথে সেই সফ্টওয়্যারের পারফর্ম্যান্স উন্নত হয়। এই ধরনের গুরুত্বপূর্ণ রক্ষণাবেক্ষণকে অগ্রাধিকার দেয় এমন হোস্টিং প্রদানকারীর সাথে পার্টনারশিপ করা অত্যন্ত গুরুত্বপূর্ণ।
- আপনার যদি খুব নির্দিষ্ট অ্যাপ্লিকেশন সংক্রান্ত প্রয়োজনীয়তা থাকে এবং সার্ভার কনফিগারেশন ফাইলে সর্বনিম্ন লেভেলের অ্যাক্সেস চান, তাহলে আপনার নিজের অ্যাপ্লিকেশন ইনস্ট্যান্সের ব্যাকএন্ড কাস্টমাইজ করা যুক্তিযুক্ত কিনা তা জিজ্ঞাসা করুন।
অনেক হোস্টিং প্রদানকারী আছে যারা আপনার জন্য এইসব বিষয় ম্যানেজ করে, তবে আপনি যদি ডেডিকেটেড হোস্টিং প্রদানকারীর ক্ষেত্রেও দীর্ঘ TTFB ভ্যালু লক্ষ্য করতে শুরু করেন, তাহলে এটি একটি চিহ্ন হতে পারে যে আপনাকে বর্তমান হোস্টিং প্রদানকারীর ক্ষমতা পুনরায় মূল্যায়ন করতে হতে পারে যাতে আপনি সেরা ব্যবহারকারীর অভিজ্ঞতা প্রদান করতে পারেন।
কন্টেন্ট ডেলিভারি নেটওয়ার্ক (CDN) ব্যবহার করা
CDN ব্যবহার সংক্রান্ত বিষয়টি খুবই পরিচিত, তবে এর পিছনে ভালো কারণ রয়েছে: আপনার কাছে খুব ভালোভাবে অপ্টিমাইজ করা অ্যাপ্লিকেশন ব্যাকএন্ড থাকতে পারে, তবে আপনার অরিজিন সার্ভার থেকে দূরে অবস্থিত ব্যবহারকারীরা এখনও ফিল্ডে বেশি TTFB-এর অভিজ্ঞতা পেতে পারেন।
CDN আপনার অরিজিন সার্ভার থেকে ব্যবহারকারীর নৈকট্যের সমস্যা সমাধান করে। এটি সার্ভারের একটি ডিস্ট্রিবিউটেড নেটওয়ার্ক ব্যবহার করে যা ব্যবহারকারীদের কাছাকাছি থাকা সার্ভারে রিসোর্স ক্যাশে করে। এইসব সার্ভারকে এজ সার্ভার বলা হয়।
CDN প্রদানকারীরা এজ সার্ভারের বাইরেও সুবিধা দিতে পারে:
- CDN পরিষেবা প্রদানকারীরা সাধারণত অত্যন্ত দ্রুত DNS রেজোলিউশন টাইম অফার করে।
- HTTP/2 বা HTTP/3-এর মতো আধুনিক প্রোটোকল ব্যবহার করে, একটি CDN সম্ভবত এজ সার্ভার থেকে আপনার কন্টেন্ট পরিবেশন করে।
- বিশেষ করে HTTP/3, UDP প্রোটোকল ব্যবহার করে TCP-তে (যার উপর HTTP/2 নির্ভর করে) হেড-অফ-লাইন ব্লকিং সমস্যার সমাধান করে।
- একটি CDN সম্ভবত TLS-এর আধুনিক ভার্সন প্রদান করে, যা TLS নেগোসিয়েশন টাইমে লেটেন্সি কম করে। বিশেষ করে TLS 1.3 এমনভাবে ডিজাইন করা হয়েছে যাতে TLS নেগোসিয়েশন যতটা সম্ভব সংক্ষিপ্ত হয়।
- কিছু CDN প্রদানকারী এমন একটি ফিচার প্রদান করে যা প্রায়ই "এজ ওয়ার্কার" নামে পরিচিত, এটি অনুরোধ ইন্টারসেপ্ট করতে, এজ ক্যাশেতে প্রোগ্রাম্যাটিকভাবে উত্তর ম্যানেজ করতে বা উত্তর সম্পূর্ণভাবে আবার লিখতে Service Worker API-এর মতো API ব্যবহার করে।
- CDN পরিষেবা প্রদানকারীরা কম্প্রেশনের জন্য অপ্টিমাইজ করার ক্ষেত্রে খুব ভালো। কম্প্রেশন নিজে থেকে ঠিক করা কঠিন এবং কিছু ক্ষেত্রে ডাইনামিকভাবে জেনারেট করা মার্কআপের সাথে রেসপন্স টাইম ধীর হতে পারে, যা ফ্লাইতে কম্প্রেস করতে হবে।
- এছাড়াও, CDN প্রদানকারীরা স্ট্যাটিক রিসোর্সের জন্য কম্প্রেস করা রেসপন্স অটোমেটিক ক্যাশে করে, যার ফলে কম্প্রেস করার অনুপাত এবং রেসপন্স টাইমের সেরা মিশ্রণ পাওয়া যায়।
CDN গ্রহণ করার জন্য সামান্য থেকে উল্লেখযোগ্য পরিমাণ প্রচেষ্টা প্রয়োজন হলেও, আপনার ওয়েবসাইট যদি আগে থেকে এটি ব্যবহার না করে, তাহলে TTFB অপ্টিমাইজ করার জন্য এটি গ্রহণ করাকে উচ্চ অগ্রাধিকার দেওয়া উচিত।
সম্ভব হলে ক্যাশেড কন্টেন্ট ব্যবহার করুন
CDNs-এর মাধ্যমে কন্টেন্ট এজ সার্ভারে ক্যাশে করা যায় যা ফিজিক্যালি ভিজিটরের কাছাকাছি থাকে, তবে কন্টেন্ট উপযুক্ত Cache-Control HTTP হেডারের সাথে কনফিগার করা থাকতে হবে। যদিও এটি পছন্দমতো কন্টেন্টের জন্য উপযুক্ত নয়, তবে উৎস পর্যন্ত ফিরে যাওয়ার জন্য ট্রিপের প্রয়োজন হলে CDN-এর অনেক মূল্য নষ্ট হতে পারে।
যেসব সাইট ঘনঘন তাদের কন্টেন্ট আপডেট করে, এমনকি অল্প ক্যাশিং টাইমও ব্যস্ত সাইটের জন্য লক্ষণীয় পারফর্ম্যান্সের উন্নতি ঘটাতে পারে, কারণ সেই সময়ের মধ্যে শুধুমাত্র প্রথম ভিজিটর অরিজিন সার্ভারে সম্পূর্ণ লেটেন্সি অনুভব করেন, যখন অন্য সব ভিজিটর এজ সার্ভার থেকে ক্যাশে করা রিসোর্স আবার ব্যবহার করতে পারেন। কিছু CDN সাইট রিলিজের সময় ক্যাশে বাতিল করার অনুমতি দেয়, যার ফলে দুটি সুবিধাই পাওয়া যায়—দীর্ঘ ক্যাশে সময়, কিন্তু প্রয়োজন হলে তাৎক্ষণিক আপডেট।
এমনকি যেখানে ক্যাশিং সঠিকভাবে কনফিগার করা হয়েছে, সেখানেও অ্যানালিটিক্স পরিমাপের জন্য অনন্য কোয়েরি স্ট্রিং প্যারামিটার ব্যবহার করে এটি উপেক্ষা করা যেতে পারে। এগুলি একই হওয়া সত্ত্বেও CDN-এর কাছে আলাদা কন্টেন্ট বলে মনে হতে পারে এবং তাই ক্যাশে করা ভার্সন ব্যবহার করা হবে না।
পুরনো বা কম ভিজিট করা কন্টেন্টও ক্যাশে করা নাও হতে পারে, যার ফলে কিছু পৃষ্ঠায় অন্যদের তুলনায় বেশি TTFB মান হতে পারে। ক্যাশিংয়ের সময় বাড়ালে এর প্রভাব কমানো যেতে পারে, তবে মনে রাখবেন যে ক্যাশিংয়ের সময় বাড়ালে সম্ভাব্য বাসি কন্টেন্ট দেখানোর সম্ভাবনা বেশি থাকে।
ক্যাশে করা কন্টেন্টের প্রভাব শুধু CDN ব্যবহারকারীদের উপর পড়ে না। ক্যাশে করা কন্টেন্ট আবার ব্যবহার করা না গেলে, সার্ভার ইনফ্রাস্ট্রাকচারকে হয়ত ব্যয়বহুল ডেটাবেস লুকআপ থেকে কন্টেন্ট তৈরি করতে হবে। আরও ঘন ঘন অ্যাক্সেস করা ডেটা বা প্রিক্যাশে করা পৃষ্ঠাগুলি প্রায়শই আরও ভাল পারফর্ম করতে পারে।
একাধিক পৃষ্ঠা রিডাইরেক্ট করা এড়িয়ে চলুন
TTFB বেশি হওয়ার একটি সাধারণ কারণ হল রিডাইরেক্ট। কোনও ডকুমেন্টের জন্য নেভিগেশন অনুরোধ এমন একটি উত্তর পেলে রিডাইরেক্ট হয় যা ব্রাউজারকে জানায় যে রিসোর্সটি অন্য লোকেশনে আছে। একটি রিডাইরেক্ট অবশ্যই নেভিগেশন অনুরোধে অবাঞ্ছিত লেটেন্সি যোগ করতে পারে, তবে সেই রিডাইরেক্ট যদি অন্য কোনও রিসোর্সকে নির্দেশ করে যার ফলে অন্য রিডাইরেক্ট হয়—এবং আরও অনেক কিছু হয়, তাহলে এটি অবশ্যই আরও খারাপ হতে পারে। এটি বিশেষ করে সেইসব সাইটকে প্রভাবিত করতে পারে যেগুলি বিজ্ঞাপন বা নিউজলেটার থেকে প্রচুর পরিমাণে ভিজিটর পায়, কারণ তারা প্রায়ই পরিমাপের উদ্দেশ্যে অ্যানালিটিক্স পরিষেবার মাধ্যমে রিডাইরেক্ট করে। আপনার সরাসরি নিয়ন্ত্রণে থাকা রিডাইরেক্ট বাদ দিলে, তা ভাল TTFB পেতে সাহায্য করতে পারে।
দুই ধরনের রিডাইরেক্ট হয়:
- একই-অরিজিন রিডাইরেক্ট, যেখানে রিডাইরেক্ট সম্পূর্ণভাবে আপনার ওয়েবসাইটে হয়।
- ক্রস-অরিজিন রিডাইরেক্ট, যেখানে রিডাইরেক্ট প্রাথমিকভাবে অন্য অরিজিনে ঘটে—যেমন, আপনার ওয়েবসাইটে পৌঁছানোর আগে সোশ্যাল মিডিয়া URL ছোট করার পরিষেবা থেকে।
একই-অরিজিন রিডাইরেক্ট বাদ দেওয়ার উপরে ফোকাস করুন, কারণ এটি আপনি সরাসরি নিয়ন্ত্রণ করতে পারবেন। এর মধ্যে আপনার ওয়েবসাইটের লিঙ্কগুলি চেক করা অন্তর্ভুক্ত থাকবে যাতে দেখা যায় যে সেগুলির মধ্যে কোনওটির ফলে 302 বা 301 রেসপন্স কোড আসে কিনা। প্রায়ই এটি https:// স্কিম অন্তর্ভুক্ত না করার কারণে হতে পারে (তাই ব্রাউজার ডিফল্ট হিসেবে http://-এ সেট করে যা পরে রিডাইরেক্ট করে) অথবা URL-এ ট্রেলিং স্ল্যাশ সঠিকভাবে অন্তর্ভুক্ত বা বাদ না দেওয়ার কারণে হতে পারে।
ক্রস-অরিজিন রিডাইরেক্ট করা আরও কঠিন কারণ এগুলি প্রায়ই আপনার নিয়ন্ত্রণের বাইরে থাকে, তবে যেখানে সম্ভব একাধিক রিডাইরেক্ট এড়িয়ে চলার চেষ্টা করুন—যেমন, লিঙ্ক শেয়ার করার সময় একাধিক লিঙ্ক শর্টনার ব্যবহার করে। বিজ্ঞাপনদাতা বা নিউজলেটারকে যে URL দেওয়া হয়েছে সেটি সঠিক ফাইনাল URL কিনা তা নিশ্চিত করুন, যাতে সেইসব পরিষেবার মাধ্যমে ব্যবহৃত URL-এ অন্য কোনও রিডাইরেক্ট যোগ না হয়।
HTTP-থেকে-HTTPS রিডাইরেক্টের কারণেও রিডাইরেক্টের সময় বেড়ে যেতে পারে। এই সমস্যা এড়ানোর একটি উপায় হল Strict-Transport-Security হেডার (HSTS) ব্যবহার করা, যা কোনও অরিজিনে প্রথমবার ভিজিট করার সময় HTTPS এনফোর্স করে এবং তারপর ব্রাউজারকে বলে যাতে ভবিষ্যতে ভিজিট করার সময় HTTPS স্কিমের মাধ্যমে অরিজিনকে অবিলম্বে অ্যাক্সেস করা হয়।
আপনার কাছে একটি ভাল HSTS নীতি থাকলে, HSTS প্রিলোড তালিকায় আপনার সাইট যোগ করে কোনও অরিজিনে প্রথমবার ভিজিট করার সময় আপনি কাজ দ্রুত করতে পারবেন।
ব্রাউজারে স্ট্রিম মার্কআপ করুন
ব্রাউজারগুলি স্ট্রিম করার সময় দক্ষতার সাথে মার্কআপ প্রসেস করার জন্য অপ্টিমাইজ করা হয়, যার অর্থ হল সার্ভার থেকে আসার সাথে সাথে মার্কআপ চাঙ্কগুলিতে হ্যান্ডেল করা হয়। এটি গুরুত্বপূর্ণ যেখানে বড় মার্কআপ পেলোডগুলি সংশ্লিষ্ট, কারণ এর অর্থ হল ব্রাউজারটি ক্রমবর্ধমানভাবে মার্কআপের অংশগুলিকে পার্স করতে পারে, পার্সিং শুরু হওয়ার আগে সম্পূর্ণ প্রতিক্রিয়া আসার জন্য অপেক্ষা করার বিপরীতে।
যদিও ব্রাউজার স্ট্রিমিং মার্কআপ ম্যানেজ করার ক্ষেত্রে দারুণ, তবে সেই স্ট্রিম যাতে চলতে থাকে তার জন্য আপনার পক্ষে যা করা সম্ভব তা করা অত্যন্ত গুরুত্বপূর্ণ, যাতে মার্কআপের প্রাথমিক বিটগুলি যত তাড়াতাড়ি সম্ভব তাদের পথে থাকে। ব্যাকএন্ড যদি কোনও কিছু আটকে রাখে, তাহলে সেটি একটি সমস্যা। ব্যাকএন্ড স্ট্যাকের সংখ্যা অনেক বেশি হওয়ার কারণে, প্রতিটি স্ট্যাক এবং সেগুলির প্রতিটিতে কী কী সমস্যা হতে পারে তা এই গাইডে কভার করা সম্ভব নয়।
React, উদাহরণস্বরূপ—এবং অন্যান্য ফ্রেমওয়ার্ক যা সার্ভারে চাহিদা অনুযায়ী মার্কআপ রেন্ডার করতে পারে—সার্ভার-সাইড রেন্ডারিংয়ের জন্য একটি সিঙ্ক্রোনাস পদ্ধতি ব্যবহার করেছে। তবে, React-এর নতুন ভার্সনে স্ট্রিমিং মার্ক-আপের জন্য সার্ভার মেথড প্রয়োগ করা হয়েছে, কারণ এটি রেন্ডার করা হচ্ছে। এর অর্থ হল, সম্পূর্ণ উত্তর পাঠানোর আগে সেটি রেন্ডার করার জন্য আপনাকে React সার্ভার API পদ্ধতির জন্য অপেক্ষা করতে হবে না।
ব্রাউজারে দ্রুত মার্কআপ স্ট্রিম করার আরেকটি উপায় হল স্ট্যাটিক রেন্ডারিং-এর উপর নির্ভর করা যা বিল্ড টাইমে HTML ফাইল তৈরি করে। সম্পূর্ণ ফাইল অবিলম্বে উপলভ্য হলে, ওয়েব সার্ভার অবিলম্বে ফাইল পাঠানো শুরু করতে পারে এবং HTTP-এর অন্তর্নিহিত প্রকৃতির ফলে স্ট্রিমিং মার্কআপ হয়। যদিও এই পদ্ধতি প্রতিটি ওয়েবসাইটের প্রতিটি পৃষ্ঠার জন্য উপযুক্ত নয়—যেমন ব্যবহারকারীর অভিজ্ঞতার অংশ হিসেবে ডাইনামিক রেসপন্সের প্রয়োজন হয়—এটি সেইসব পৃষ্ঠার জন্য উপকারী হতে পারে যেগুলির জন্য নির্দিষ্ট ব্যবহারকারীর জন্য ব্যক্তিগতকৃত মার্কআপের প্রয়োজন হয় না।
সার্ভিস ওয়ার্কার ব্যবহার করা
Service Worker API ডকুমেন্ট এবং তার লোড করা রিসোর্স, উভয়েরই TTFB-এর উপর বড় প্রভাব ফেলতে পারে। এর কারণ হল, সার্ভিস ওয়ার্কার ব্রাউজার ও সার্ভারের মধ্যে প্রক্সি হিসেবে কাজ করে—তবে আপনার ওয়েবসাইটের TTFB-এর উপর কোনও প্রভাব পড়বে কিনা তা নির্ভর করে আপনি কীভাবে সার্ভিস ওয়ার্কার সেট-আপ করেছেন এবং সেই সেট-আপ আপনার অ্যাপ্লিকেশনের প্রয়োজনীয়তার সাথে সামঞ্জস্যপূর্ণ কিনা তার উপর।
- অ্যাসেটের জন্য stale-while-revalidate স্ট্র্যাটেজি ব্যবহার করুন। কোনও অ্যাসেট সার্ভিস ওয়ার্কার ক্যাশেতে থাকলে, সেটি কোনও ডকুমেন্ট বা ডকুমেন্টের জন্য প্রয়োজনীয় রিসোর্স যাই হোক না কেন, stale-while-revalidate স্ট্র্যাটেজি ক্যাশে থেকে প্রথমে সেই রিসোর্স প্রদান করে, তারপর ব্যাকগ্রাউন্ডে সেই অ্যাসেট ডাউনলোড করে এবং ভবিষ্যতের ইন্টার্যাকশনের জন্য ক্যাশে থেকে সেটি প্রদান করে।
- আপনার কাছে যদি এমন ডকুমেন্ট রিসোর্স থাকে যা খুব ঘন ঘন পরিবর্তন হয় না, তাহলে stale-while-revalidate স্ট্র্যাটেজি ব্যবহার করলে কোনও পৃষ্ঠার TTFB প্রায় তাৎক্ষণিক হতে পারে। তবে, আপনার ওয়েবসাইট ডাইনামিক পদ্ধতিতে তৈরি করা মার্কআপ পাঠালে, এটি খুব একটা ভালভাবে কাজ করে না—যেমন, ব্যবহারকারী যাচাই করা হয়েছে কিনা তার উপর ভিত্তি করে পরিবর্তন হওয়া মার্কআপ। এই ধরনের ক্ষেত্রে, আপনি সবসময় প্রথমে নেটওয়ার্ক হিট করতে চাইবেন, যাতে ডকুমেন্ট যতটা সম্ভব নতুন হয়।
- আপনার ডকুমেন্ট যদি এমন কোনও অপ্রয়োজনীয় রিসোর্স লোড করে যা ঘন ঘন পরিবর্তিত হয়, কিন্তু পুরনো রিসোর্স ফেচ করলে ব্যবহারকারীর অভিজ্ঞতা খুব একটা প্রভাবিত হয় না—যেমন, বেছে নেওয়া ছবি বা অন্যান্য রিসোর্স যা গুরুত্বপূর্ণ নয়—তাহলে stale-while-revalidate স্ট্র্যাটেজি ব্যবহার করে সেইসব রিসোর্সের TTFB অনেকখানি কমানো যেতে পারে।
- ক্লায়েন্ট-রেন্ডার করা অ্যাপ্লিকেশনের জন্য অ্যাপ শেল মডেল ব্যবহার করুন। এই মডেলটি SPA-এর জন্য সবচেয়ে উপযুক্ত যেখানে পৃষ্ঠার "শেল" সার্ভিস ওয়ার্কার ক্যাশে থেকে সাথে সাথে ডেলিভার করা যায় এবং পৃষ্ঠার ডায়নামিক কন্টেন্ট পৃষ্ঠার লাইফসাইকেলে পরে পপুলেট ও রেন্ডার করা হয়।
রেন্ডার-ক্রিটিক্যাল রিসোর্সের জন্য 103 Early Hints ব্যবহার করুন
আপনার অ্যাপ্লিকেশন ব্যাকএন্ড যতই ভালোভাবে অপ্টিমাইজ করা হোক না কেন, সার্ভারকে এখনও একটি প্রতিক্রিয়া প্রস্তুত করার জন্য উল্লেখযোগ্য পরিমাণ কাজ করতে হতে পারে, যার মধ্যে রয়েছে ব্যয়বহুল (তবুও প্রয়োজনীয়) ডেটাবেস কাজ যা নেভিগেশন প্রতিক্রিয়া যত দ্রুত সম্ভব আসতে বিলম্ব করে। এর সম্ভাব্য প্রভাব হল যে কিছু পরবর্তী রেন্ডার-ক্রিটিক্যাল রিসোর্স বিলম্বিত হতে পারে, যেমন CSS বা—কিছু ক্ষেত্রে—জাভাস্ক্রিপ্ট যা ক্লায়েন্টে মার্কআপ রেন্ডার করে।
103 Early Hints হেডার হল একটি প্রাথমিক রেসপন্স কোড যা ব্যাকএন্ড মার্কআপ প্রস্তুত করতে ব্যস্ত থাকাকালীন সার্ভার ব্রাউজারে পাঠাতে পারে। এই হেডারটি ব্রাউজারকে ইঙ্গিত দিতে ব্যবহার করা যেতে পারে যে রেন্ডার-ক্রিটিক্যাল রিসোর্স আছে যা মার্কআপ প্রস্তুত করার সময় পৃষ্ঠার ডাউনলোড শুরু করা উচিত। কাজ করে এমন ব্রাউজারের ক্ষেত্রে, এর ফলে ডকুমেন্ট দ্রুত রেন্ডার (CSS) ও পৃষ্ঠা দ্রুত লোড হতে পারে।
103 Early Hints-এর একটি নেতিবাচক দিক হল, ক্যাশিংয়ের মতো এটিও সাইটের "আসল" TTFB লুকিয়ে রাখতে পারে। সার্ভার ইনফ্রাস্ট্রাকচার স্লো হলে (কারণ এটি কম শক্তিশালী বা কোড অপ্টিমাইজ করা প্রয়োজন), তাহলে ১০৩ আর্লি হিন্টস ব্যবহার করা হলে সেটি কম স্পষ্ট হতে পারে কারণ TTFB দ্রুত দেখায়। যেসব সাইট 103 Early Hints ব্যবহার করে, তাদের সার্ভারের আসল সময় পরিমাপ করার কথা বিবেচনা করা উচিত (PerformanceNavigationTiming API-এর Server-Timing বা finalResponseHeadersStart-এর মাধ্যমে)।
উপসংহার
ব্যাকএন্ড অ্যাপ্লিকেশন স্ট্যাকের অনেক কম্বিনেশন থাকার কারণে, এমন কোনও নিবন্ধ নেই যা আপনার ওয়েবসাইটের TTFB কমানোর জন্য আপনি যা করতে পারেন তার সবকিছু এনক্যাপসুলেট করতে পারে। তবে, সার্ভার সাইডে কাজ একটু দ্রুত করার জন্য আপনি এইসব বিকল্প এক্সপ্লোর করতে পারেন।
প্রতিটি মেট্রিক অপ্টিমাইজ করার মতো, এই পদ্ধতিও অনেকটাই একই রকম: ফিল্ডে আপনার TTFB পরিমাপ করুন, কারণগুলি আরও ভালভাবে বুঝতে ল্যাব টুল ব্যবহার করুন এবং তারপরে যেখানে সম্ভব অপ্টিমাইজেশন প্রয়োগ করুন। কিছু টেকনিক আপনার পরিস্থিতির জন্য উপযুক্ত নাও হতে পারে, তবে কিছু টেকনিক উপযুক্ত হতে পারে। সবসময়ের মতোই, আপনাকে ফিল্ড ডেটার উপর নজর রাখতে হবে এবং ব্যবহারকারীকে সবচেয়ে দ্রুত অভিজ্ঞতা প্রদান করার জন্য প্রয়োজন মতো অ্যাডজাস্ট করতে হবে।