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