সাধারণ এইচটিএমএল কর্মক্ষমতা বিবেচনা

দ্রুত লোড হয় এমন একটি ওয়েবসাইট তৈরির প্রথম ধাপ হল একটি পৃষ্ঠার HTML এর জন্য সার্ভার থেকে একটি সময়মত প্রতিক্রিয়া পাওয়া। আপনি যখন ব্রাউজারের ঠিকানা বারে একটি URL প্রবেশ করেন, ব্রাউজার এটি পুনরুদ্ধার করার জন্য সার্ভারে একটি GET অনুরোধ পাঠায়। একটি ওয়েব পৃষ্ঠার জন্য প্রথম অনুরোধ হল একটি HTML সম্পদের জন্য—এবং নিশ্চিত করা যে এইচটিএমএল ন্যূনতম বিলম্বের সাথে দ্রুত পৌঁছানো একটি মূল কর্মক্ষমতা লক্ষ্য।

HTML এর জন্য সেই প্রাথমিক অনুরোধটি বেশ কয়েকটি ধাপের মধ্য দিয়ে যায়, যার প্রতিটিতে কিছু সময় লাগে। প্রতিটি ধাপে ব্যয় করা সময় কমানো আপনাকে ফার্স্ট বাইট (TTFB) এর জন্য দ্রুত সময় দেয়। যদিও TTFB একমাত্র মেট্রিক নয়, যখন পৃষ্ঠাগুলি কত দ্রুত লোড হয় তার উপর আপনার ফোকাস করা উচিত, একটি উচ্চ TTFB মেট্রিকগুলির জন্য মনোনীত "ভাল" থ্রেশহোল্ডে পৌঁছানো কঠিন করে তোলে যেমন Largest Contentful Paint (LCP) এবং ফার্স্ট কনটেন্টফুল পেইন্ট ( এফসিপি)

পুনঃনির্দেশ ছোট করুন

যখন একটি সংস্থান অনুরোধ করা হয়, সার্ভার একটি পুনঃনির্দেশের সাথে সাড়া দিতে পারে, হয় একটি স্থায়ী পুনঃনির্দেশ (একটি 301 Moved Permanently প্রতিক্রিয়া) অথবা একটি অস্থায়ী একটি (একটি 302 Found প্রতিক্রিয়া)।

রিডাইরেক্ট পৃষ্ঠা লোডের গতি কমিয়ে দেয় কারণ এর জন্য ব্রাউজারকে রিসোর্স পুনরুদ্ধার করার জন্য নতুন অবস্থানে একটি অতিরিক্ত HTTP অনুরোধ করতে হবে। দুই ধরনের পুনঃনির্দেশ আছে:

  1. একই-অরিজিন পুনঃনির্দেশ যা সম্পূর্ণরূপে আপনার মূলের মধ্যে ঘটে। এই ধরনের পুনঃনির্দেশগুলি সম্পূর্ণরূপে আপনার নিয়ন্ত্রণের মধ্যে, কারণ সেগুলি পরিচালনা করার যুক্তি সম্পূর্ণরূপে আপনার ওয়েব সার্ভারে থাকে৷
  2. ক্রস-অরিজিন রিডাইরেক্ট যেগুলি অন্য একটি উত্স দ্বারা শুরু হয়৷ এই ধরনের রিডাইরেক্ট সাধারণত আপনার নিয়ন্ত্রণের বাইরে থাকে।

ক্রস-অরিজিন রিডাইরেক্ট প্রায়ই বিজ্ঞাপন, URL-সংক্ষিপ্তকরণ পরিষেবা এবং অন্যান্য তৃতীয় পক্ষের পরিষেবাগুলির দ্বারা ব্যবহৃত হয়৷ যদিও ক্রস-অরিজিন পুনঃনির্দেশগুলি আপনার নিয়ন্ত্রণের বাইরে, তবুও আপনি একাধিক পুনঃনির্দেশ এড়াতে পারেন কিনা তা পরীক্ষা করতে চাইতে পারেন—উদাহরণস্বরূপ, একটি বিজ্ঞাপন থাকা যা একটি HTTP পৃষ্ঠার সাথে লিঙ্ক করে যা তার HTTPS সমতুল্য বা ক্রস-অরিজিন পুনঃনির্দেশে পুনঃনির্দেশ করে। যেটি আপনার উৎপত্তিস্থলে পৌঁছায়, কিন্তু তারপর একই-অরিজিন রিডাইরেক্ট ট্রিগার করে।

ক্যাশে HTML প্রতিক্রিয়া

এইচটিএমএল প্রতিক্রিয়া ক্যাশ করা কঠিন, কারণ প্রতিক্রিয়াতে অন্যান্য গুরুত্বপূর্ণ সংস্থান যেমন CSS, জাভাস্ক্রিপ্ট, চিত্র এবং অন্যান্য সংস্থান প্রকারের লিঙ্ক অন্তর্ভুক্ত থাকতে পারে। এই সম্পদগুলি তাদের নিজ নিজ ফাইলের নামগুলিতে একটি অনন্য আঙ্গুলের ছাপ অন্তর্ভুক্ত করতে পারে, যা ফাইলের বিষয়বস্তুর উপর ভিত্তি করে পরিবর্তিত হয়। এর মানে হল যে আপনার ক্যাশে করা HTML নথি একটি স্থাপনার পরে বাসি হয়ে যেতে পারে, কারণ এতে পুরানো সাবরিসোর্সের উল্লেখ থাকবে।

তবুও, একটি সংক্ষিপ্ত ক্যাশে জীবনকাল-কোনও ক্যাশিং না করে-এর সুবিধা থাকতে পারে যেমন একটি সংস্থানকে CDN-এ ক্যাশে করার অনুমতি দেওয়া-অরিজিন সার্ভার থেকে দেওয়া অনুরোধের সংখ্যা হ্রাস করা-এবং ব্রাউজারে, সংস্থানগুলিকে পুনরায় যাচাই করার অনুমতি দেওয়া। আবার ডাউনলোড করার চেয়ে। এই পদ্ধতিটি স্ট্যাটিক কন্টেন্টের জন্য সর্বোত্তম কাজ করে যা কোনো প্রেক্ষাপটে পরিবর্তিত হয় না এবং রিসোর্স ক্যাশে করার জন্য একটি উপযুক্ত সময় সেট করা যেতে পারে যা আপনি উপযুক্ত মনে করেন। স্ট্যাটিক এইচটিএমএল রিসোর্সের জন্য পাঁচ মিনিট একটি নিরাপদ বাজি, এবং নিশ্চিত করে যে পর্যায়ক্রমিক আপডেটগুলি অলক্ষিত না হয়৷

যদি একটি পৃষ্ঠার HTML বিষয়বস্তু কোনোভাবে ব্যক্তিগতকৃত হয়-যেমন একজন প্রমাণীকৃত ব্যবহারকারীর জন্য-আপনি সম্ভবত নিরাপত্তা এবং সতেজতা সহ বিভিন্ন উদ্বেগের জন্য সামগ্রী ক্যাশে করতে চান না। যদি একটি HTML প্রতিক্রিয়া ব্যবহারকারীর ব্রাউজার দ্বারা ক্যাশ করা হয়, আপনি ক্যাশে অবৈধ করতে অক্ষম। তাই এই ধরনের ক্ষেত্রে এইচটিএমএল ক্যাশ করা এড়িয়ে চলাই ভালো।

এইচটিএমএল ক্যাশ করার জন্য একটি সতর্ক দৃষ্টিভঙ্গি হতে পারে ETag বা Last-Modified প্রতিক্রিয়া শিরোনাম ব্যবহার করা। একটি ETag অন্যথায় একটি সত্তা ট্যাগ নামে পরিচিত—শিরোনাম হল একটি শনাক্তকারী যা অনুরোধ করা সংস্থানকে অনন্যভাবে উপস্থাপন করে, প্রায়ই রিসোর্সের বিষয়বস্তুর হ্যাশ ব্যবহার করে:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

যখনই সম্পদ পরিবর্তিত হয়, একটি নতুন ETag মান অবশ্যই তৈরি করতে হবে। পরবর্তী অনুরোধে, ব্রাউজার If-None-Match অনুরোধ শিরোনামের মাধ্যমে ETag মান পাঠায়। সার্ভারের ETag ব্রাউজার দ্বারা প্রেরিত একটির সাথে মিলে গেলে, সার্ভারটি 304 Not Modified রেসপন্স দিয়ে সাড়া দেয় এবং ব্রাউজার ক্যাশে থেকে রিসোর্স ব্যবহার করে। যদিও এটি এখনও নেটওয়ার্ক লেটেন্সি বহন করে, একটি 304 Not Modified প্রতিক্রিয়া সম্পূর্ণ HTML সম্পদের তুলনায় অনেক ছোট।

যাইহোক, একটি সম্পদের সতেজতা পুনঃপ্রমাণ করার সাথে জড়িত নেটওয়ার্ক লেটেন্সি এখনও তার নিজস্ব ধরণের খারাপ দিক। ওয়েব ডেভেলপমেন্টের অন্যান্য অনেক দিকগুলির মতো, ট্রেড-অফ এবং আপস অনিবার্য। এইভাবে এইচটিএমএল ক্যাশে করার অতিরিক্ত প্রচেষ্টা সার্থক কিনা, বা নিরাপদে থাকা এবং এইচটিএমএল সামগ্রী ক্যাশিংয়ে মোটেও বিরক্ত না করাই ভাল কিনা তা নির্ধারণ করা আপনার উপর নির্ভর করে।

সার্ভার প্রতিক্রিয়া সময় পরিমাপ

যদি একটি প্রতিক্রিয়া ক্যাশে করা না হয়, সার্ভারের প্রতিক্রিয়া সময় আপনার হোস্টিং প্রদানকারী এবং ব্যাকএন্ড অ্যাপ্লিকেশন স্ট্যাকের উপর অত্যন্ত নির্ভরশীল। একটি ওয়েব পৃষ্ঠা যা একটি গতিশীলভাবে জেনারেট করা প্রতিক্রিয়া পরিবেশন করে - যেমন একটি ডাটাবেস থেকে ডেটা আনা, উদাহরণস্বরূপ - একটি স্ট্যাটিক ওয়েব পৃষ্ঠার চেয়ে উচ্চতর TTFB থাকতে পারে যা ব্যাকএন্ডে উল্লেখযোগ্য গণনা সময় ছাড়াই অবিলম্বে পরিবেশন করা যেতে পারে। একটি লোডিং স্পিনার প্রদর্শন করা এবং তারপরে ক্লায়েন্ট সাইডে সমস্ত ডেটা আনার প্রচেষ্টাকে আরও অনুমানযোগ্য সার্ভার-সাইড পরিবেশ থেকে সম্ভাব্য অপ্রত্যাশিত ক্লায়েন্ট-সাইডে নিয়ে যায়। ক্লায়েন্ট-সাইড প্রচেষ্টা কমিয়ে আনার ফলে সাধারণত উন্নত ব্যবহারকারী-কেন্দ্রিক মেট্রিক্স হয়।

যদি ব্যবহারকারীরা ক্ষেত্রটিতে একটি ধীর TTFB অনুভব করেন, আপনি Server-Timing প্রতিক্রিয়া শিরোনাম ব্যবহার করে সার্ভারে কোথায় সময় ব্যয় করা হয়েছে সে সম্পর্কে তথ্য প্রকাশ করতে পারেন:

Server-Timing: auth;dur=55.5, db;dur=220

একটি Server-Timing হেডারের মান একাধিক মেট্রিক্স, সেইসাথে প্রতিটির জন্য একটি সময়কাল অন্তর্ভুক্ত করতে পারে। এই ডেটা তারপরে নেভিগেশন টাইমিং API ব্যবহার করে ক্ষেত্রের ব্যবহারকারীদের কাছ থেকে সংগ্রহ করা যেতে পারে এবং ব্যবহারকারীরা বিলম্বের সম্মুখীন হচ্ছে কিনা তা দেখতে বিশ্লেষণ করা যেতে পারে। পূর্ববর্তী কোড স্নিপেটে, প্রতিক্রিয়া শিরোনামে দুটি সময় অন্তর্ভুক্ত রয়েছে:

  • একটি ব্যবহারকারীকে প্রমাণীকরণ করার সময় ( auth ), যা 55.5 মিলিসেকেন্ড নেয়।
  • ডাটাবেস অ্যাক্সেস টাইম ( db ), যা 220 মিলিসেকেন্ড নেয়।

আপনি আপনার হোস্টিং পরিকাঠামো পর্যালোচনা করতে এবং আপনার ওয়েবসাইট যে ট্র্যাফিক পাচ্ছেন তা পরিচালনা করার জন্য আপনার কাছে পর্যাপ্ত সংস্থান রয়েছে তা নিশ্চিত করতে চাইতে পারেন। শেয়ার্ড হোস্টিং প্রদানকারীরা প্রায়শই উচ্চ TTFB-এর জন্য সংবেদনশীল এবং দ্রুত প্রতিক্রিয়ার সময় প্রদান করে এমন উত্সর্গীকৃত সমাধানগুলি আরও ব্যয়বহুল হতে পারে।

সঙ্কোচন

এইচটিএমএল, জাভাস্ক্রিপ্ট, সিএসএস এবং এসভিজি ছবিগুলির মতো পাঠ্য-ভিত্তিক প্রতিক্রিয়াগুলিকে আরও দ্রুত ডাউনলোড করার জন্য নেটওয়ার্কে তাদের স্থানান্তরের আকার কমাতে সংকুচিত করা উচিত। সর্বাধিক ব্যবহৃত কম্প্রেশন অ্যালগরিদম হল gzip এবং Brotli। ব্রটলি জিজিপের তুলনায় প্রায় 15% থেকে 20% উন্নতি করে।

কম্প্রেশন প্রায়ই বেশিরভাগ ওয়েব হোস্টিং প্রদানকারীর দ্বারা স্বয়ংক্রিয়ভাবে সেট আপ করা হয়, কিন্তু আপনি যদি কম্প্রেশন সেটিংস নিজে কনফিগার বা পরিবর্তন করার অবস্থানে থাকেন তবে কিছু গুরুত্বপূর্ণ বিষয় বিবেচনা করতে হবে:

  1. যেখানে সম্ভব ব্রটলি ব্যবহার করুন। আগেই বলা হয়েছে, Brotli gzip-এর তুলনায় মোটামুটি লক্ষণীয় উন্নতি প্রদান করে, এবং Brotli সমস্ত প্রধান ব্রাউজারে সমর্থিত । সম্ভব হলে Brotli ব্যবহার করুন, কিন্তু যদি আপনার ওয়েবসাইটটি লিগ্যাসি ব্রাউজারে বেশি সংখ্যক ব্যবহারকারীর দ্বারা ব্যবহার করা হয়, তাহলে নিশ্চিত হোন যে gzip একটি ফলব্যাক হিসেবে ব্যবহার করা হয়েছে, কারণ যেকোনও কম্প্রেশন কোনো কম্প্রেশনের চেয়ে ভালো।
  2. ফাইলের আকার গুরুত্বপূর্ণ। খুব ছোট রিসোর্স—1 KiB-এর কম—খুব ভালভাবে কম্প্রেস করে না, বা কখনও কখনও একেবারেই কম্প্রেসও করে না। যেকোন ধরনের ডেটা কম্প্রেশনের কার্যকারিতা নির্ভর করে প্রচুর পরিমাণে ডেটা থাকার উপর যা একটি কম্প্রেশন অ্যালগরিদম ডেটার আরও সংকোচনযোগ্য বিট খুঁজে পেতে কাজ করতে পারে। একটি ফাইল যত বড় হবে, তত ভাল কম্প্রেশন কাজ করে-তবে, খুব বড় সম্পদ পাঠাবেন না এই জন্য যে সেগুলি আরও কার্যকরভাবে সংকুচিত করা যেতে পারে। বৃহৎ সংস্থানগুলি—যেমন জাভাস্ক্রিপ্ট এবং CSS-উদাহরণস্বরূপ—ব্রাউজার ডিকম্প্রেস করার পরে পার্স এবং মূল্যায়ন করতে উল্লেখযোগ্যভাবে বেশি সময় নেয় এবং সেগুলি সামান্য পরিবর্তিত হলেও ঘন ঘন পরিবর্তন হতে পারে, কারণ কোনো পরিবর্তনের ফলে একটি ভিন্ন ফাইল হ্যাশ হয়।
  3. গতিশীল বনাম স্ট্যাটিক কম্প্রেশন বুঝুন। গতিশীল এবং স্ট্যাটিক কম্প্রেশন যখন একটি সম্পদ সংকুচিত করা উচিত ভিন্ন পদ্ধতির হয়। ডায়নামিক কম্প্রেশন একটি রিসোর্সকে অনুরোধ করার সময় সংকুচিত করে, এবং কখনও কখনও প্রতিবার অনুরোধ করা হয়। অন্যদিকে, স্ট্যাটিক কম্প্রেশন ফাইলগুলিকে সময়ের আগে কম্প্রেস করে, অনুরোধের সময় কোন কম্প্রেশন করার প্রয়োজন হয় না। স্ট্যাটিক কম্প্রেশন কম্প্রেশনের সাথে জড়িত বিলম্বকে সরিয়ে দেয়, যা গতিশীল কম্প্রেশনের ক্ষেত্রে সার্ভারের প্রতিক্রিয়ার সময় যোগ করতে পারে। স্ট্যাটিক রিসোর্স-যেমন জাভাস্ক্রিপ্ট, সিএসএস, এবং এসভিজি ইমেজগুলিকে স্ট্যাটিকভাবে সংকুচিত করা উচিত, যেখানে এইচটিএমএল রিসোর্সগুলি- বিশেষ করে যদি সেগুলি প্রমাণীকৃত ব্যবহারকারীদের জন্য গতিশীলভাবে তৈরি করা হয়- গতিশীলভাবে সংকুচিত হওয়া উচিত।

আপনার নিজের থেকে সংকোচন করা চ্যালেঞ্জিং, এবং আপনার জন্য এটি পরিচালনা করার জন্য একটি বিষয়বস্তু বিতরণ নেটওয়ার্ক (CDN) - যা পরবর্তী বিভাগে আলোচনা করা হয়েছে - এটি প্রায়ই ভাল। যাইহোক, এই ধারণাগুলি জানা আপনাকে আপনার হোস্টিং প্রদানকারী সঠিকভাবে কম্প্রেশন ব্যবহার করছে কিনা তা বুঝতে সাহায্য করতে পারে। এই জ্ঞান আপনাকে আপনার কম্প্রেশন সেটিংস উন্নত করার সুযোগ খুঁজে পেতে সাহায্য করতে পারে যাতে তারা আপনার ওয়েবসাইটের জন্য সর্বাধিক সুবিধা প্রদান করে।

কন্টেন্ট ডেলিভারি নেটওয়ার্ক (CDN)

একটি বিষয়বস্তু বিতরণ নেটওয়ার্ক (CDN) হল সার্ভারের একটি বিতরণ করা নেটওয়ার্ক যা আপনার মূল সার্ভার থেকে সম্পদ ক্যাশে করে এবং এর পরিবর্তে, এজ সার্ভার থেকে সেগুলি পরিবেশন করে যা আপনার ব্যবহারকারীদের শারীরিকভাবে কাছাকাছি। আপনার ব্যবহারকারীদের সাথে শারীরিক নৈকট্য রাউন্ড-ট্রিপ টাইম (RTT) হ্রাস করে, যখন অপ্টিমাইজেশান যেমন HTTP/2 বা HTTP/3, ক্যাশিং, এবং কম্প্রেশন CDN কে আপনার মূল সার্ভার থেকে আনার চেয়ে আরও দ্রুত সামগ্রী পরিবেশন করার অনুমতি দেয়৷ একটি CDN ব্যবহার করা কিছু ক্ষেত্রে উল্লেখযোগ্যভাবে আপনার ওয়েবসাইটের TTFB উন্নত করতে পারে।

নিজের জ্ঞান যাচাই করুন

কি ধরনের পুনঃনির্দেশ সম্পূর্ণরূপে আপনার নিয়ন্ত্রণের মধ্যে?

একটি ক্রস-অরিজিন রিডাইরেক্ট।
আবার চেষ্টা কর.
একই-অরিজিন রিডাইরেক্ট।
সঠিক!

Server-Timing হেডারে একাধিক মেট্রিক্স থাকতে পারে।

সত্য।
সঠিক!
মিথ্যা।
আবার চেষ্টা কর.

কোন ধরনের সার্ভার আপনার শেষ ব্যবহারকারীদের কাছে শারীরিকভাবে সবচেয়ে কাছের হতে পারে?

আপনার ওয়েবসাইটের মূল সার্ভার।
আবার চেষ্টা কর.
একটি কন্টেন্ট ডেলিভারি নেটওয়ার্কের (CDN) প্রান্ত সার্ভার।
সঠিক!

পরবর্তী: সমালোচনামূলক পথ বোঝা

এখন যেহেতু আপনি আপনার ওয়েবসাইটের HTML এর সাথে জড়িত কিছু পারফরম্যান্স বিবেচনার সাথে পরিচিত, আপনি এটি যত তাড়াতাড়ি সম্ভব লোড হতে পারে তা নিশ্চিত করার জন্য আরও ভাল অবস্থানে আছেন—কিন্তু এটি ওয়েব পারফরম্যান্স শেখার শুরু মাত্র। পরবর্তীতে, সমালোচনামূলক রেন্ডারিং পথের পিছনের তত্ত্বটি কভার করা হয়েছে। এই মডিউলটি মূল ধারণাগুলি বর্ণনা করে যেমন রেন্ডার-ব্লকিং এবং পার্সিং-ব্লকিং রিসোর্স এবং যত তাড়াতাড়ি সম্ভব ব্রাউজারে একটি পৃষ্ঠার প্রাথমিক রেন্ডারিং পেতে তারা যে ভূমিকা পালন করে।