কোর ওয়েব ভাইটাল উন্নত করার সবচেয়ে কার্যকর উপায়,কোর ওয়েব ভাইটাল উন্নত করার সবচেয়ে কার্যকর উপায়

বছরের পর বছর ধরে, ওয়েব সম্প্রদায় ওয়েব পারফরম্যান্স অপ্টিমাইজেশান জ্ঞানের ভাণ্ডার তৈরি করেছে। যদিও যেকোন একটি অপ্টিমাইজেশন অনেক সাইটের জন্য কর্মক্ষমতা উন্নত করতে পারে, সেগুলি একসাথে অপ্রতিরোধ্য বোধ করতে পারে এবং বাস্তবে, শুধুমাত্র তাদের মধ্যে কিছু যেকোন সাইটে প্রযোজ্য।

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

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

  • সবচেয়ে বড় বাস্তব বিশ্বের প্রভাব আছে
  • প্রাসঙ্গিক এবং অধিকাংশ সাইটে প্রযোজ্য
  • বেশিরভাগ বিকাশকারীদের বাস্তবায়নের জন্য বাস্তবসম্মত

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

নেক্সট পেইন্টের সাথে মিথস্ক্রিয়া (INP)

নতুন কোর ওয়েব ভাইটাল মেট্রিক হিসাবে, ইন্টারঅ্যাকশন টু নেক্সট পেইন্ট (INP) এর উন্নতির জন্য সবচেয়ে বড় সুযোগ রয়েছে। যাইহোক, যেহেতু অনেক কম সাইট তার অবচয়িত পূর্বসূরির তুলনায় "ভাল" অভিজ্ঞতার জন্য থ্রেশহোল্ড অতিক্রম করছে, আপনি অনেক ডেভেলপারদের মধ্যে হতে পারেন যারা প্রথমবারের মতো ইন্টারঅ্যাকশন প্রতিক্রিয়াশীলতাকে অপ্টিমাইজ করতে শিখছেন। INP উন্নত করার সবচেয়ে কার্যকর উপায়গুলির জন্য এই অবশ্যই জানা কৌশলগুলি দিয়ে শুরু করুন৷

1. দীর্ঘ টাস্ক আপ বিরতি প্রায়ই ফলন

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

ব্রাউজার সমর্থন

  • ক্রোম: 129।
  • প্রান্ত: 129।
  • ফায়ারফক্স: সমর্থিত নয়।
  • সাফারি: সমর্থিত নয়।

উৎস

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

Scheduler API আপনাকে অগ্রাধিকারের একটি সিস্টেম ব্যবহার করে সারিবদ্ধভাবে কাজ করতে দেয়। বিশেষত, scheduler.yield() API দীর্ঘ টাস্কগুলিকে বিচ্ছিন্ন করে এবং নিশ্চিত করে যে মিথস্ক্রিয়াগুলি টাস্ক সারিতে তাদের জায়গা না ছেড়ে দিয়ে পরিচালনা করা যেতে পারে।

দীর্ঘ কাজগুলি ভেঙে, আপনি ব্রাউজারটিকে সমালোচনামূলক, ব্যবহারকারী-অবরুদ্ধ কাজগুলিতে ফিট করার জন্য আরও সুযোগ দিচ্ছেন৷

2. অপ্রয়োজনীয় জাভাস্ক্রিপ্ট এড়িয়ে চলুন

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

যাইহোক, এটি একটি অমীমাংসিত সমস্যা নয়, এবং আপনার কাছে বিকল্প রয়েছে:

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

3. বড় রেন্ডারিং আপডেট এড়িয়ে চলুন

জাভাস্ক্রিপ্ট এক্সিকিউশন হল একটি জিনিস যা আপনার ওয়েবসাইটের প্রতিক্রিয়াশীলতাকে প্রভাবিত করে। রেন্ডারিং হল এক ধরনের ব্যয়বহুল কাজ-এবং বড় রেন্ডারিং আপডেটের সময়, আপনার ওয়েবসাইট ব্যবহারকারীর ইন্টারঅ্যাকশনে আরও ধীরে ধীরে সাড়া দিতে পারে।

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

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

সবচেয়ে বড় কন্টেন্টফুল পেইন্ট (LCP)

সবচেয়ে বড় কন্টেন্টফুল পেইন্ট (LCP) হল কোর ওয়েব অত্যাবশ্যক যেটির সাথে ডেভেলপারদের সবচেয়ে বেশি লড়াই করার প্রবণতা রয়েছে— Chrome UX রিপোর্টের 40% সাইট ভাল ব্যবহারকারীর অভিজ্ঞতার জন্য প্রস্তাবিত LCP থ্রেশহোল্ড পূরণ করে না। LCP উন্নত করার সবচেয়ে কার্যকর উপায় হিসেবে Chrome টিম নিম্নলিখিত কৌশলগুলি সুপারিশ করে৷

1. নিশ্চিত করুন যে এলসিপি সংস্থানটি HTML উত্স থেকে আবিষ্কারযোগ্য এবং অগ্রাধিকার দেওয়া হয়েছে৷

ক্রোম টিম ওয়েবে এলসিপি সংক্রান্ত নিম্নলিখিতগুলি লক্ষ্য করেছে:

  • এইচটিটিপি আর্কাইভের 2022 ওয়েব অ্যালম্যানাক অনুসারে, 72% মোবাইল পৃষ্ঠাগুলির LCP উপাদান হিসাবে একটি চিত্র রয়েছে৷
  • ক্রোম থেকে প্রকৃত-ব্যবহারকারীর ডেটার বিশ্লেষণ দেখায় যে দুর্বল LCP সহ বেশিরভাগ উত্স তাদের p75 LCP সময়ের 10% এরও কম সময় ব্যয় করে LCP ছবি ডাউনলোড করতে
  • দুর্বল LCP সহ পৃষ্ঠাগুলির মধ্যে, তাদের LCP চিত্রগুলি লোড করতে ক্লায়েন্টের 75তম শতাংশে 1,290 মিলিসেকেন্ড বিলম্বিত হয় - এটি একটি দ্রুত অভিজ্ঞতার জন্য বাজেটের অর্ধেকেরও বেশি৷
  • যে পৃষ্ঠাগুলিতে LCP উপাদানটি একটি চিত্র ছিল, সেই সমস্ত চিত্রগুলির 39% এর উত্স URL ছিল যা প্রাথমিক HTML প্রতিক্রিয়াতে আবিষ্কার করা যায় নি (যেমন <img src="..."> বা <link rel="preload" href="..."> ), যা ব্রাউজারের প্রিলোড স্ক্যানারকে যত তাড়াতাড়ি সম্ভব সেগুলি আবিষ্কার করার অনুমতি দেবে৷
  • ওয়েব অ্যালম্যানাক অনুসারে, শুধুমাত্র 0.03% যোগ্য পৃষ্ঠাগুলি সম্পদকে উচ্চ অগ্রাধিকার দেওয়ার জন্য fetchpriority অ্যাট্রিবিউটের সুবিধা গ্রহণ করছে—যেগুলি তুলনামূলকভাবে অল্প প্রচেষ্টায় একটি পৃষ্ঠার LCP উন্নত করতে পারে।

এই পরিসংখ্যানগুলি বলছে যে ডেভেলপারদের টেবিলে এলসিপি চিত্রগুলির জন্য রিসোর্স লোড বিলম্ব এবং রিসোর্স লোডের সময়কাল উভয়ই কমানোর একটি বড় সুযোগ রয়েছে৷

ব্রাউজার সমর্থন

  • ক্রোম: 102।
  • প্রান্ত: 102।
  • ফায়ারফক্স: 132।
  • সাফারি: 17.2।

উৎস

যেখানে রিসোর্স লোড বিলম্ব সমস্যা, এটি মনে রাখা গুরুত্বপূর্ণ যে ভাল LCP অর্জন করতে ইতিমধ্যেই অনেক দেরি হয়ে যেতে পারে যদি ছবিগুলি লোড করা শুরু করার আগে একটি পৃষ্ঠার সম্পূর্ণরূপে CSS বা JavaScript লোড হওয়ার জন্য অপেক্ষা করতে হয় ৷ আরও, একটি LCP ইমেজের রিসোর্স লোডের সময়কালকে পুনরায় প্রাধান্য দিয়ে কমানো যেতে পারে যাতে এটি আরও ব্যান্ডউইথ পায় এবং এইভাবে fetchpriority HTML অ্যাট্রিবিউট ব্যবহার করে আরও দ্রুত লোড হয়।

যদি আপনার LCP উপাদানটি একটি ছবি হয়, তাহলে রিসোর্স লোডের বিলম্ব কমাতে ছবির URLটি HTML প্রতিক্রিয়ায় আবিষ্কারযোগ্য হওয়া উচিত। এটি সম্ভব করার জন্য কিছু টিপস হল:

  • src বা srcset বৈশিষ্ট্য সহ একটি <img> উপাদান ব্যবহার করে চিত্রটি লোড করুন। data-src মতো নন-স্ট্যান্ডার্ড অ্যাট্রিবিউট ব্যবহার করবেন না যাতে রেন্ডার করার জন্য জাভাস্ক্রিপ্টের প্রয়োজন হয়, কারণ এটি সবসময় ধীর হবে। 9% পৃষ্ঠা data-src পিছনে তাদের LCP ছবিকে অস্পষ্ট করে।
  • ক্লায়েন্ট-সাইড রেন্ডারিং (CSR) এর চেয়ে সার্ভার-সাইড রেন্ডারিং (SSR) পছন্দ করুন, কারণ SSR বোঝায় যে সম্পূর্ণ পৃষ্ঠা মার্কআপ (ছবি সহ) HTML উত্সে উপস্থিত রয়েছে৷ CSR সমাধানের জন্য ইমেজ আবিষ্কার করার আগে JavaScript চালানোর প্রয়োজন হয়।
  • যদি আপনার ছবিকে একটি বাহ্যিক CSS বা JS ফাইল থেকে উল্লেখ করার প্রয়োজন হয়, তাহলেও আপনি একটি <link rel="preload"> ট্যাগ ব্যবহার করে এটিকে HTML উৎসে অন্তর্ভুক্ত করতে পারেন। নোট করুন যে ইনলাইন শৈলী দ্বারা উল্লেখ করা ছবিগুলি ব্রাউজারের প্রিলোড স্ক্যানার দ্বারা আবিষ্কৃত হয় না, তাই যদিও সেগুলি HTML উত্সে পাওয়া যায়, তবুও সেগুলির আবিষ্কার অন্যান্য সংস্থানগুলি লোড করার সময় অবরুদ্ধ হতে পারে, তাই প্রিলোডিং এই ক্ষেত্রে সাহায্য করতে পারে৷

আরও, আপনি LCP রিসোর্স তাড়াতাড়ি লোড হয়েছে তা নিশ্চিত করে এবং উচ্চ অগ্রাধিকারে একটি সংস্থানের লোডের সময়কাল সংক্ষিপ্ত করতে পারেন:

  • আপনার LCP ছবির <img> বা <link rel="preload"> ট্যাগে fetchpriority="high" অ্যাট্রিবিউট যোগ করুন। এটি ইমেজ রিসোর্সের অগ্রাধিকার বাড়ায় তাই এটি শীঘ্রই লোড করা শুরু করতে পারে।
  • আপনার LCP চিত্রের <img> ট্যাগ থেকে loading="lazy" বৈশিষ্ট্যটি সরান। এটি ভিউপোর্টে বা তার কাছাকাছি চিত্রটি উপস্থিত হয়েছে তা নিশ্চিত করার কারণে লোড বিলম্ব এড়ায়।
  • সম্ভব হলে অ-সমালোচনা সংস্থান বিলম্বিত করুন। এই সম্পদগুলিকে আপনার নথির শেষে সরানো, অলস-লোড করা ছবি বা iframes , অথবা JavaScript ব্যবহার করে এগুলিকে অ্যাসিঙ্ক্রোনাসভাবে লোড করা LCP ছবির মতো আরও গুরুত্বপূর্ণ সংস্থানগুলিকে আরও দ্রুত লোড করার পথ পরিষ্কার করতে সাহায্য করবে৷

2. তাত্ক্ষণিক নেভিগেশনের জন্য লক্ষ্য করুন

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

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

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

সম্পূর্ণরূপে রেন্ডার করা পৃষ্ঠাগুলি পুনরুদ্ধার করা শুধুমাত্র লোডিং কর্মক্ষমতাই নয়, লেআউটের স্থায়িত্বও উন্নত করে৷ আপনি bfcache সম্পর্কে আরও জানতে পারেন এবং CLS এর উন্নতির জন্য এটি কতটা কার্যকর তা নিশ্চিত করুন পৃষ্ঠাগুলি bfcache বিভাগে যোগ্য

ব্রাউজার সমর্থন

  • ক্রোম: 109।
  • প্রান্ত: 109।
  • ফায়ারফক্স: সমর্থিত নয়।
  • সাফারি: সমর্থিত নয়।

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

3. TTFB অপ্টিমাইজ করতে একটি CDN ব্যবহার করুন৷

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

এই সময়টিকে টাইম টু ফার্স্ট বাইট (TTFB) বলা হয়। TTFB কমানোর সর্বোত্তম উপায় হল:

  • ভৌগলিকভাবে যতটা সম্ভব আপনার ব্যবহারকারীদের কাছে আপনার সামগ্রী পরিবেশন করুন।
  • সেই বিষয়বস্তুটি ক্যাশে করুন যাতে অদূর ভবিষ্যতে আবার অনুরোধ করা হলে এটি দ্রুত পরিবেশন করা যায়।

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

সিডিএনগুলি এইচটিএমএল ডকুমেন্টগুলিকে পরিবেশন ও ক্যাশেও করতে পারে, তবে ওয়েব অ্যালমানাক অনুসারে, এইচটিএমএল ডকুমেন্টের অনুরোধের মাত্র 29% একটি CDN থেকে দেওয়া হয়েছিল ৷ এর মানে হল অতিরিক্ত সঞ্চয় উপলব্ধি করার জন্য সাইটগুলির জন্য একটি উল্লেখযোগ্য সুযোগ রয়েছে৷

CDN কনফিগার করার জন্য কিছু টিপস অন্তর্ভুক্ত:

  • ক্যাশে স্ট্যাটিক এইচটিএমএল ডকুমেন্ট এমনকি অল্প সময়ের জন্য। উদাহরণস্বরূপ, বিষয়বস্তু সবসময় তাজা হওয়া কি গুরুত্বপূর্ণ? নাকি কয়েক মিনিট বাসি হতে পারে?
  • আপনি আপনার অরিজিন সার্ভারে চলমান গতিশীল লজিককে প্রান্তে নিয়ে যেতে পারেন কিনা তা অন্বেষণ করুন, যা বেশিরভাগ আধুনিক CDN-এর বৈশিষ্ট্য।

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

ক্রমবর্ধমান লেআউট শিফট (CLS)

Cumulative Layout Shift (CLS) হল একটি ওয়েব পেজের ভিজ্যুয়াল স্থায়িত্বের পরিমাপ। যদিও CLS হল মেট্রিক বেশিরভাগ সাইটেই ভাল করার প্রবণতা রয়েছে, তাদের প্রায় এক চতুর্থাংশ এখনও প্রস্তাবিত থ্রেশহোল্ড পূরণ করে না, তাই অনেক সাইটের জন্য তাদের ব্যবহারকারীর অভিজ্ঞতা উন্নত করার একটি বড় সুযোগ রয়েছে।

1. পৃষ্ঠা থেকে লোড করা যেকোনো বিষয়বস্তুর উপর সুস্পষ্ট আকার সেট করুন

অন্যান্য বিষয়বস্তু লোড হওয়া শেষ হওয়ার পরে বিদ্যমান সামগ্রী সরে গেলে সাধারণত লেআউট পরিবর্তন ঘটে। CLS উন্নত করার প্রাথমিক উপায় হল প্রয়োজনীয় স্থান যতটা সম্ভব আগে থেকে সংরক্ষণ করা।

আকারবিহীন চিত্রগুলির কারণে সৃষ্ট লেআউট পরিবর্তনগুলি ঠিক করার সর্বোত্তম উপায় হল স্পষ্টভাবে width এবং height বৈশিষ্ট্যগুলি বা তাদের সমতুল্য CSS বৈশিষ্ট্যগুলি সেট করা72% পৃষ্ঠাগুলিতে কমপক্ষে একটি আকারবিহীন চিত্র রয়েছে। একটি সুস্পষ্ট আকার ছাড়া, এই চিত্রগুলির একটি প্রাথমিক উচ্চতা 0px , যা এই চিত্রগুলি লোড হলে এবং ব্রাউজার তাদের মাত্রাগুলি আবিষ্কার করার সময় লেআউট পরিবর্তনের কারণ হতে পারে৷ এটি যৌথ ওয়েবের জন্য একটি বিশাল সুযোগের প্রতিনিধিত্ব করে—এবং সেই সুযোগের জন্য এই নির্দেশিকায় প্রস্তাবিত অন্যান্য সুপারিশগুলির তুলনায় কম প্রচেষ্টার প্রয়োজন।

ব্রাউজার সমর্থন

  • ক্রোম: 88।
  • প্রান্ত: 88।
  • ফায়ারফক্স: 89।
  • সাফারি: 15।

উৎস

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

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

2. নিশ্চিত করুন যে পৃষ্ঠাগুলি bfcache এর জন্য যোগ্য

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

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

সাইটের মালিকদের অবশ্যই পৃষ্ঠাগুলি bfcache-এর জন্য যোগ্য কিনা তা পরীক্ষা করা উচিত এবং সেগুলি কেন নয় তা ঠিক করা উচিত৷ DevTools-এ Chrome-এর একটি bfcache পরীক্ষক রয়েছে এবং আপনি ক্ষেত্রের অযোগ্যতার কারণগুলি সনাক্ত করতে নট রিস্টোরড রিজনস API ব্যবহার করতে পারেন৷

3. অ্যানিমেশন এবং রূপান্তরগুলি এড়িয়ে চলুন যা লেআউট-প্ররোচিত CSS বৈশিষ্ট্যগুলি ব্যবহার করে

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

যদিও HTTP আর্কাইভ ডেটা চূড়ান্তভাবে অ্যানিমেশনগুলিকে লেআউট শিফটের সাথে সংযুক্ত করতে পারে না, ডেটা দেখায় যে লেআউটকে প্রভাবিত করতে পারে এমন কোনও CSS প্রপার্টি অ্যানিমেট করে এমন পৃষ্ঠাগুলি সামগ্রিক পৃষ্ঠাগুলির তুলনায় "ভাল" CLS হওয়ার সম্ভাবনা 15% কম। কিছু বৈশিষ্ট্য অন্যদের তুলনায় খারাপ CLS এর সাথে যুক্ত। উদাহরণ স্বরূপ, যে পৃষ্ঠাগুলি অ্যানিমেট margin বা border প্রস্থে "খারাপ" CLS আছে তার প্রায় দ্বিগুণ হারে পৃষ্ঠাগুলিকে দরিদ্র হিসাবে মূল্যায়ন করা হয়।

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

কিছু ডেভেলপারদের কাছে আশ্চর্যজনক হতে পারে যে এটি এমন ক্ষেত্রেও সত্য যেখানে উপাদানটি স্বাভাবিক নথি প্রবাহের বাইরে নেওয়া হয়। উদাহরণ স্বরূপ, একেবারে পজিশন করা উপাদান যা top বা left অ্যানিমেট করে লেআউট শিফট করে, এমনকি যদি তারা অন্য কন্টেন্টকে আশেপাশে ঠেলে না দেয়। যাইহোক, যদি top বা left অ্যানিমেট করার পরিবর্তে, আপনি transform:translateX() বা transform:translateY() অ্যানিমেট করেন, তাহলে এটি ব্রাউজারকে পৃষ্ঠার বিন্যাস আপডেট করতে দেবে না, এইভাবে লেআউট পরিবর্তনগুলি এড়িয়ে যাবে।

ব্রাউজারের কম্পোজিটর থ্রেডে আপডেট করা যেতে পারে এমন CSS বৈশিষ্ট্যগুলির অ্যানিমেশন পছন্দ করা দীর্ঘকাল ধরে একটি কর্মক্ষমতার সর্বোত্তম অভ্যাস ছিল কারণ এটি মূল থ্রেড থেকে GPU-তে কাজ করে। এটি একটি সাধারণ পারফরম্যান্সের সর্বোত্তম অনুশীলন হওয়ার পাশাপাশি, এটি CLS উন্নত করতেও সাহায্য করতে পারে।

একটি সাধারণ নিয়ম হিসাবে, কখনই CSS বৈশিষ্ট্যগুলিকে অ্যানিমেট বা ট্রানজিশন করবেন না যেগুলির জন্য ব্রাউজারকে পৃষ্ঠার লেআউট আপডেট করতে হবে, যদি না আপনি এটি ব্যবহারকারীর ট্যাপ বা কী প্রেসের প্রতিক্রিয়া হিসাবে করছেন (যদিও hover না করেন )। যখনই সম্ভব, CSS transform প্রপার্টি ব্যবহার করে ট্রানজিশন এবং অ্যানিমেশন পছন্দ করুন।

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

উপসংহার

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

আপনি যদি এখানে তালিকাভুক্ত অপ্টিমাইজেশনের বাইরে যেতে চান তবে আরও তথ্যের জন্য এই নির্দেশিকাগুলি পড়ুন:

পরিশিষ্ট: লগ পরিবর্তন করুন

কখন এবং কেন শীর্ষ সুপারিশগুলি পরিবর্তিত হয়েছে তা ব্যাখ্যা করতে এই নথিতে প্রধান পরিবর্তনগুলি এখানে ট্র্যাক করা হবে৷

অক্টোবর 2024

2024 আপডেট:

  • আইএনপি
    • কোর ওয়েব ভাইটাল মেট্রিক হিসাবে INP চালু করার সাথে সাথে আমরা এই মেট্রিকটিকে FID থেকে INP তে স্যুইচ করেছি এবং এটিকে তালিকার শীর্ষ মেট্রিক বানিয়েছি।
    • আমরা দীর্ঘ টাস্কগুলি ভাঙার অংশ হিসাবে isInputPending API ব্যবহার করার জন্য আমাদের সুপারিশকে উল্টে দিয়েছি। অপ্টিমাইজ লং টাস্ক নিবন্ধে আপনি আমাদের যুক্তি সম্পর্কে আরও জানতে পারেন।
  • এলসিপি
    • আমরা আবিষ্কারযোগ্যতা এবং অগ্রাধিকারের সুপারিশগুলিকে একটিতে একত্রিত করেছি৷
    • তাত্ক্ষণিক নেভিগেশনের লক্ষ্যে আমরা একটি নতুন সুপারিশ যুক্ত করেছি।

জানুয়ারী 2023

এটি সুপারিশের প্রাথমিক তালিকা:

  • এলসিপি
    • নিশ্চিত করুন যে LCP সংস্থানটি HTML উৎস থেকে আবিষ্কারযোগ্য
    • LCP সংস্থানকে অগ্রাধিকার দেওয়া হয়েছে তা নিশ্চিত করুন
    • ডকুমেন্ট এবং রিসোর্স TTFB অপ্টিমাইজ করতে একটি CDN ব্যবহার করুন
  • সিএলএস
    • পৃষ্ঠা থেকে লোড করা যেকোনো বিষয়বস্তুতে স্পষ্ট আকার সেট করুন
    • নিশ্চিত করুন যে পৃষ্ঠাগুলি bfcache এর জন্য যোগ্য
    • অ্যানিমেশন এবং রূপান্তরগুলি এড়িয়ে চলুন যেগুলি লেআউট-প্ররোচিত CSS বৈশিষ্ট্যগুলি ব্যবহার করে
  • এফআইডি
    • দীর্ঘ কাজ এড়িয়ে চলুন বা বিরতি দিন
    • অপ্রয়োজনীয় জাভাস্ক্রিপ্ট এড়িয়ে চলুন
    • বড় রেন্ডারিং আপডেট এড়িয়ে চলুন

আপনি একটি ভিডিও সারাংশের জন্য এই 2023 Google I/O উপস্থাপনাটিও দেখতে পারেন।