2023 সালে Core Web Vitals পারফরম্যান্স উন্নত করার জন্য Chrome DevRel টিম সবচেয়ে কার্যকরী উপায় বলে বিশ্বাস করে সেরা অনুশীলনের একটি সংগ্রহ।
বছরের পর বছর ধরে, কীভাবে কার্যক্ষমতা উন্নত করা যায় সে বিষয়ে আমরা Google-এ ওয়েব ডেভেলপারদের অনেক সুপারিশ করেছি।
যদিও এই সুপারিশগুলির প্রত্যেকটি, স্বতন্ত্রভাবে, অনেক সাইটের কর্মক্ষমতা উন্নত করতে পারে, সুপারিশের সম্পূর্ণ সেটটি স্বীকৃতভাবে অপ্রতিরোধ্য এবং বাস্তবসম্মতভাবে, কোনও ব্যক্তি বা সাইট সেগুলি অনুসরণ করতে পারে এমন কোনও উপায় নেই৷
ওয়েব পারফরম্যান্স আপনার দিনের কাজ না হলে, কোন সুপারিশগুলি আপনার সাইটে সবচেয়ে বেশি ইতিবাচক প্রভাব ফেলবে তা সম্ভবত স্পষ্ট নয়। উদাহরণ স্বরূপ, আপনি হয়তো পড়েছেন যে সমালোচনামূলক CSS প্রয়োগ করা লোড কর্মক্ষমতা উন্নত করতে পারে এবং আপনি হয়ত শুনেছেন যে আপনার ছবি অপ্টিমাইজ করা গুরুত্বপূর্ণ। কিন্তু, যদি আপনার উভয় বিষয়ে কাজ করার সময় না থাকে, তাহলে আপনি কীভাবে সিদ্ধান্ত নেবেন কোনটি বেছে নেবেন?
ক্রোম টিমে, আমরা এই প্রশ্নের উত্তর দেওয়ার চেষ্টা করে গত বছর কাটিয়েছি: ডেভেলপারদের তাদের ব্যবহারকারীদের পারফরম্যান্স উন্নত করতে সাহায্য করার জন্য আমরা সবচেয়ে গুরুত্বপূর্ণ সুপারিশগুলি কী দিতে পারি?
এই প্রশ্নের পর্যাপ্ত উত্তর দেওয়ার জন্য আমাদেরকে শুধুমাত্র প্রদত্ত সুপারিশের প্রযুক্তিগত যোগ্যতাই বিবেচনা করতে হবে না, বরং মানবিক ও সাংগঠনিক কারণগুলিও বিবেচনা করতে হবে যা বিকাশকারীরা এই সুপারিশগুলি গ্রহণ করতে সক্ষম হওয়ার সম্ভাবনাকে প্রভাবিত করে। অন্য কথায়, কিছু সুপারিশ তাত্ত্বিকভাবে অত্যন্ত প্রভাবশালী হতে পারে, কিন্তু বাস্তবে খুব কম সাইটেই সেগুলি বাস্তবায়নের জন্য সময় বা সংস্থান থাকবে। একইভাবে, কিছু সুপারিশ সমালোচনামূলক, কিন্তু বেশিরভাগ ওয়েবসাইট ইতিমধ্যেই এই অনুশীলনগুলি অনুসরণ করছে৷
সংক্ষেপে, আমরা আমাদের শীর্ষ ওয়েব পারফরম্যান্স সুপারিশগুলির তালিকাতে ফোকাস করতে চেয়েছিলাম:
- আমরা বিশ্বাস করি যে সুপারিশগুলি বাস্তব-বিশ্বের সবচেয়ে বড় প্রভাব ফেলবে
- বেশিরভাগ সাইটের জন্য প্রাসঙ্গিক এবং প্রযোজ্য সুপারিশ
- বেশিরভাগ ডেভেলপারদের বাস্তবায়নের জন্য বাস্তবসম্মত সুপারিশ
গত এক বছরে আমরা আমাদের তৈরি কার্যসম্পাদন সুপারিশগুলির সম্পূর্ণ সেটের অডিট করার জন্য এবং উপরের তিনটি মানদণ্ডের বিপরীতে তাদের প্রতিটিকে (গুণগত এবং পরিমাণগতভাবে) মূল্যায়ন করার জন্য অনেক সময় ব্যয় করেছি।
এই পোস্টে প্রতিটি কোর ওয়েব ভাইটাল মেট্রিক্সের কর্মক্ষমতা উন্নত করার জন্য আমাদের শীর্ষ সুপারিশগুলির রূপরেখা দেওয়া হয়েছে। আপনি যদি ওয়েব পারফরম্যান্সে নতুন হন, বা আপনি যদি সিদ্ধান্ত নেওয়ার চেষ্টা করেন যে আপনার অর্থের জন্য আপনাকে সবচেয়ে বড় ধাক্কা দেবে, আমরা মনে করি এই সুপারিশগুলি শুরু করার সেরা জায়গা।
সবচেয়ে বড় কন্টেন্টফুল পেইন্ট (LCP)
আমাদের সুপারিশের প্রথম সেট হল Largest Contentful Paint (LCP) এর জন্য, যা লোড পারফরম্যান্সের একটি পরিমাপ। তিনটি কোর ওয়েব ভাইটাল মেট্রিক্সের মধ্যে, এলসিপি হল সবচেয়ে বেশি সংখ্যক সাইট যার সাথে লড়াই করে—আজকে ওয়েবে থাকা সমস্ত সাইটের প্রায় অর্ধেকই প্রস্তাবিত থ্রেশহোল্ড পূরণ করে —তাই চলুন শুরু করা যাক।
নিশ্চিত করুন যে LCP সংস্থানটি HTML উৎস থেকে আবিষ্কারযোগ্য
এইচটিটিপি আর্কাইভের 2022 ওয়েব অ্যালম্যানাক অনুসারে, 72% মোবাইল পৃষ্ঠাগুলিতে তাদের LCP উপাদান হিসাবে একটি চিত্র রয়েছে, যার অর্থ হল যে বেশিরভাগ সাইটে তাদের LCP অপ্টিমাইজ করার জন্য, তাদের সেই ছবিগুলি দ্রুত লোড হতে পারে তা নিশ্চিত করতে হবে।
যা অনেক ডেভেলপারদের কাছে স্পষ্ট নাও হতে পারে তা হল একটি ছবি লোড করতে যে সময় লাগে তা চ্যালেঞ্জের মাত্র একটি অংশ। আরেকটি গুরুত্বপূর্ণ অংশ হল একটি ছবি লোড হতে শুরু করার আগে সময়, এবং HTTP আর্কাইভ ডেটা প্রস্তাব করে যে প্রকৃতপক্ষে অনেক সাইট ট্রিপ হয়ে যায়।
প্রকৃতপক্ষে, যে পৃষ্ঠাগুলিতে LCP উপাদানটি একটি চিত্র ছিল, সেগুলির মধ্যে 39% ছবির উত্স URL ছিল যা HTML নথির উত্স থেকে আবিষ্কার করা যায় নি৷ অন্য কথায়, সেই ইউআরএলগুলি স্ট্যান্ডার্ড HTML অ্যাট্রিবিউটে পাওয়া যায়নি (যেমন <img src="..."> বা <link rel="preload" href="..."> ), যা ব্রাউজারকে অনুমতি দেবে দ্রুত সেগুলি আবিষ্কার করুন এবং এখুনি লোড করা শুরু করুন৷
চিত্রটি লোড হওয়া শুরু করার আগে যদি একটি পৃষ্ঠার CSS বা JavaScript ফাইলগুলি সম্পূর্ণরূপে ডাউনলোড, পার্স এবং প্রক্রিয়াকরণের জন্য অপেক্ষা করতে হয়, তবে এটি ইতিমধ্যেই অনেক দেরি হয়ে যেতে পারে।
একটি সাধারণ নিয়ম হিসাবে, যদি আপনার 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 ছবিতে আবিষ্কারের সমস্যা আছে কিনা তা বোঝার জন্য, Lighthouse 10.0 সংস্করণে একটি নতুন অডিট প্রকাশ করবে (প্রত্যাশিত জানুয়ারী 2023)।
এইচটিএমএল উৎস থেকে এলসিপি রিসোর্স আবিষ্কারযোগ্য তা নিশ্চিত করলে পরিমাপযোগ্য উন্নতি হতে পারে এবং এটি রিসোর্সকে অগ্রাধিকার দেওয়ার অতিরিক্ত সুযোগও আনলক করে, যা আমাদের পরবর্তী সুপারিশ।
LCP সংস্থানকে অগ্রাধিকার দেওয়া হয়েছে তা নিশ্চিত করুন
এইচটিএমএল উৎস থেকে এলসিপি রিসোর্স খুঁজে পাওয়া যায় কিনা তা নিশ্চিত করা হল এলসিপি রিসোর্সটি তাড়াতাড়ি লোড হওয়া নিশ্চিত করার জন্য একটি গুরুত্বপূর্ণ প্রথম ধাপ, কিন্তু আরেকটি গুরুত্বপূর্ণ ধাপ হল সেই রিসোর্সটির লোডিংকে অগ্রাধিকার দেওয়া হয় এবং এটি একটি গুচ্ছের পিছনে সারিবদ্ধ না হয় তা নিশ্চিত করা। অন্যান্য, কম গুরুত্বপূর্ণ সম্পদ।
উদাহরণ স্বরূপ, এমনকি যদি আপনার LCP ইমেজটি HTML উৎসে একটি স্ট্যান্ডার্ড <img> ট্যাগ ব্যবহার করে উপস্থিত থাকে, যদি আপনার পৃষ্ঠায় আপনার ডকুমেন্টের <head> এ <img> ট্যাগের আগে এক ডজন <script> ট্যাগ থাকে, তাহলে তা হতে পারে আপনার ইমেজ রিসোর্স লোড হতে শুরু করার কিছুক্ষণ আগে।
এই সমস্যাটি সমাধান করার সবচেয়ে সহজ উপায় হল আপনার LCP ইমেজ লোড করে এমন <img> বা <link> ট্যাগে নতুন fetchpriority="high" অ্যাট্রিবিউট সেট করে কোন রিসোর্সগুলিকে সর্বোচ্চ অগ্রাধিকার দেওয়া হয় সে সম্পর্কে ব্রাউজারকে একটি ইঙ্গিত দেওয়া। এটি ব্রাউজারকে সেই স্ক্রিপ্টগুলি সম্পূর্ণ হওয়ার জন্য অপেক্ষা না করে আগে লোড করার নির্দেশ দেয়।
ওয়েব অ্যালম্যানাক অনুসারে, শুধুমাত্র 0.03% যোগ্য পৃষ্ঠা এই নতুন API-এর সুবিধা নিচ্ছে, যার অর্থ হল ওয়েবে বেশিরভাগ সাইটের জন্য খুব কম কাজ করে LCP উন্নত করার প্রচুর সুযোগ রয়েছে। যদিও fetchpriority বৈশিষ্ট্যটি বর্তমানে শুধুমাত্র Chromium-ভিত্তিক ব্রাউজারগুলিতে সমর্থিত, এই APIটি একটি প্রগতিশীল বর্ধন যা অন্যান্য ব্রাউজারগুলি কেবল উপেক্ষা করে, তাই আমরা দৃঢ়ভাবে ডেভেলপারদের এখনই এটি ব্যবহার করার পরামর্শ দিই৷
নন-ক্রোমিয়াম ব্রাউজারগুলির জন্য, LCP সংস্থানটিকে অন্যান্য সংস্থানগুলির উপরে অগ্রাধিকার দেওয়া হয়েছে তা নিশ্চিত করার একমাত্র উপায় হল নথিতে এটির আগে উল্লেখ করা। নথির <head> এ প্রচুর <script> ট্যাগ সহ একটি সাইটের উদাহরণ আবার ব্যবহার করে, আপনি যদি নিশ্চিত করতে চান যে আপনার LCP সংস্থানগুলি সেই স্ক্রিপ্ট সংস্থানগুলির আগে অগ্রাধিকার দেওয়া হয়েছে, আপনি একটি <link rel="preload"> যোগ করতে পারেন <link rel="preload"> এই স্ক্রিপ্টগুলির যেকোনো একটির আগে ট্যাগ করুন, অথবা আপনি সেই স্ক্রিপ্টগুলিকে <img> পরে <body> এর নীচে নিয়ে যেতে পারেন। যদিও এটি কাজ করে, এটি fetchpriority ব্যবহার করার চেয়ে কম ergonomic, তাই আমরা আশা করি অন্যান্য ব্রাউজারগুলি শীঘ্রই সমর্থন যোগ করবে৷
LCP রিসোর্সকে অগ্রাধিকার দেওয়ার আরেকটি গুরুত্বপূর্ণ দিক হল আপনি এমন কিছু করবেন না যাতে এটিকে বঞ্চিত করা হয়, যেমন loading="lazy" অ্যাট্রিবিউট যোগ করা। আজ, 10% পৃষ্ঠা আসলে তাদের LCP ছবিতে loading="lazy" সেট করে। ইমেজ অপ্টিমাইজেশান সলিউশন থেকে সতর্ক থাকুন যা নির্বিচারে সমস্ত ছবিতে অলস-লোডিং আচরণ প্রয়োগ করে। যদি তারা সেই আচরণকে ওভাররাইড করার একটি উপায় প্রদান করে, তাহলে LCP চিত্রের জন্য এটি ব্যবহার করতে ভুলবেন না। আপনি যদি নিশ্চিত না হন যে কোন ছবিটি LCP হবে, তাহলে যুক্তিসঙ্গত প্রার্থী বাছাই করার জন্য হিউরিস্টিক ব্যবহার করার চেষ্টা করুন।
অ-সমালোচনামূলক সংস্থানগুলিকে পিছিয়ে দেওয়া হল এলসিপি সংস্থানগুলির আপেক্ষিক অগ্রাধিকারকে কার্যকরভাবে বৃদ্ধি করার আরেকটি উপায়। উদাহরণস্বরূপ, যে স্ক্রিপ্টগুলি ব্যবহারকারীর ইন্টারফেসকে শক্তি দিচ্ছে না (যেমন বিশ্লেষণ স্ক্রিপ্ট বা সামাজিক উইজেট) load ইভেন্ট ফায়ার না হওয়া পর্যন্ত নিরাপদে স্থগিত করা যেতে পারে, যা নিশ্চিত করে যে তারা নেটওয়ার্কের জন্য অন্যান্য গুরুত্বপূর্ণ সংস্থানগুলির (যেমন LCP সংস্থান) সাথে প্রতিযোগিতা করবে না ব্যান্ডউইথ
সংক্ষেপে বলতে গেলে, এলসিপি রিসোর্স তাড়াতাড়ি লোড হয়েছে কিনা তা নিশ্চিত করতে এবং উচ্চ অগ্রাধিকারে আপনাকে এই সেরা অনুশীলনগুলি অনুসরণ করতে হবে:
- আপনার LCP ছবির
<img>ট্যাগেfetchpriority="high"যোগ করুন। যদি LCP রিসোর্সটি<link rel="preload">ট্যাগের মাধ্যমে লোড করা হয়, ভয় পাবেন না কারণ আপনি এটিতেfetchpriority="high"সেট করতে পারেন! - আপনার LCP ছবির
<img>ট্যাগে কখনইloading="lazy"সেট করবেন না। এটি করা আপনার ছবিকে অগ্রাহ্য করবে এবং এটি লোড হতে দেরি করবে। - সম্ভব হলে অ-সমালোচনা সংস্থান বিলম্বিত করুন। হয় সেগুলিকে আপনার নথির শেষে সরানোর মাধ্যমে, ছবি বা আইফ্রেমগুলির জন্য নেটিভ অলস-লোডিং ব্যবহার করে, অথবা জাভাস্ক্রিপ্টের মাধ্যমে অ্যাসিঙ্ক্রোনাসভাবে লোড করে৷
ডকুমেন্ট এবং রিসোর্স TTFB অপ্টিমাইজ করতে একটি CDN ব্যবহার করুন
পূর্ববর্তী দুটি সুপারিশ আপনার এলসিপি রিসোর্সকে তাড়াতাড়ি আবিষ্কৃত হয়েছে এবং অগ্রাধিকার দেওয়া হয়েছে তা নিশ্চিত করার উপর দৃষ্টি নিবদ্ধ করে যাতে এটি এখনই লোড হওয়া শুরু করতে পারে। এই ধাঁধার চূড়ান্ত অংশটি নিশ্চিত করছে যে প্রাথমিক নথির প্রতিক্রিয়া যত তাড়াতাড়ি সম্ভব পৌঁছেছে।
প্রারম্ভিক HTML নথির প্রতিক্রিয়ার প্রথম বাইট না পাওয়া পর্যন্ত ব্রাউজার কোনো সাবরিসোর্স লোড করা শুরু করতে পারে না, এবং যত তাড়াতাড়ি এটি ঘটবে, তত তাড়াতাড়ি অন্য সবকিছুও ঘটতে শুরু করবে।
এই সময়টিকে টাইম টু ফার্স্ট বাইট (TTFB) বলা হয় এবং TTFB কমানোর সর্বোত্তম উপায় হল:
- ভৌগলিকভাবে যতটা সম্ভব আপনার ব্যবহারকারীদের কাছে আপনার সামগ্রী পরিবেশন করুন
- সেই কন্টেন্ট ক্যাশে করুন যাতে সম্প্রতি অনুরোধ করা কন্টেন্ট দ্রুত আবার পরিবেশন করা যায়।
এই দুটি জিনিস করার সর্বোত্তম উপায় হল একটি CDN ব্যবহার করা । CDNs আপনার সংস্থানগুলি প্রান্তের সার্ভারগুলিতে বিতরণ করে, যা বিশ্বজুড়ে ছড়িয়ে রয়েছে, এইভাবে সেই সংস্থানগুলিকে আপনার ব্যবহারকারীদের কাছে তারের উপর দিয়ে ভ্রমণ করতে হবে এমন দূরত্ব সীমিত করে৷ CDN-এ সাধারণত সূক্ষ্ম-দানাযুক্ত ক্যাশিং নিয়ন্ত্রণ থাকে যা আপনার সাইটের প্রয়োজনের জন্য কাস্টমাইজ এবং অপ্টিমাইজ করা যেতে পারে।
অনেক ডেভেলপার স্ট্যাটিক সম্পদ হোস্ট করার জন্য একটি CDN ব্যবহার করার সাথে পরিচিত, কিন্তু CDN এইচটিএমএল ডকুমেন্টগুলিকে পরিবেশন এবং ক্যাশে করতে পারে, এমনকি যেগুলি গতিশীলভাবে তৈরি হয়।
ওয়েব অ্যালম্যানাকের মতে, এইচটিএমএল ডকুমেন্টের অনুরোধের মাত্র 29% একটি CDN থেকে দেওয়া হয়েছিল, যার অর্থ সাইটগুলির জন্য অতিরিক্ত সঞ্চয় দাবি করার উল্লেখযোগ্য সুযোগ রয়েছে।
আপনার CDN কনফিগার করার জন্য কিছু টিপস হল:
- কতক্ষণ কন্টেন্ট ক্যাশ করা হয় তা বাড়ানোর কথা বিবেচনা করুন (উদাহরণস্বরূপ, বিষয়বস্তু সবসময় তাজা থাকাটা কি সত্যিই গুরুত্বপূর্ণ? নাকি কয়েক মিনিটের বাসি হতে পারে?)।
- এমনকি অনির্দিষ্টকালের জন্য বিষয়বস্তু ক্যাশে করার কথা বিবেচনা করুন এবং তারপরে আপনি যদি/যখন আপডেট করেন তখন ক্যাশে পরিষ্কার করুন।
- আপনি আপনার অরিজিন সার্ভারে চলমান গতিশীল যুক্তিকে প্রান্তে (অধিকাংশ আধুনিক CDN-এর বৈশিষ্ট্য) নিয়ে যেতে পারবেন কিনা তা অন্বেষণ করুন।
সাধারণভাবে, যে কোনো সময় আপনি প্রান্ত থেকে সরাসরি বিষয়বস্তু পরিবেশন করতে পারেন (আপনার মূল সার্ভারে ভ্রমণ এড়িয়ে) এটি একটি পারফরম্যান্স জয়। এমনকি এমন ক্ষেত্রেও যেখানে আপনাকে আপনার আসল সার্ভারে ফিরে যেতে হবে , CDNগুলি সাধারণত এটি আরও দ্রুত করার জন্য অপ্টিমাইজ করা হয়, তাই এটি যে কোনও উপায়ে একটি জয়।
ক্রমবর্ধমান লেআউট শিফট (CLS)
সুপারিশের পরবর্তী সেট হল Cumulative Layout Shift (CLS) এর জন্য, যা ওয়েব পৃষ্ঠাগুলিতে চাক্ষুষ স্থিতিশীলতার একটি পরিমাপ। যদিও 2020 সাল থেকে CLS ওয়েবে অনেক উন্নতি করেছে, প্রায় এক চতুর্থাংশ ওয়েবসাইট এখনও প্রস্তাবিত থ্রেশহোল্ড পূরণ করে না, তাই অনেক সাইটের জন্য তাদের ব্যবহারকারীর অভিজ্ঞতা উন্নত করার একটি বড় সুযোগ রয়েছে।
পৃষ্ঠা থেকে লোড করা যেকোনো বিষয়বস্তুতে স্পষ্ট আকার সেট করুন
অন্যান্য বিষয়বস্তু লোড হওয়া শেষ হওয়ার পরে বিদ্যমান সামগ্রী সরে গেলে সাধারণত লেআউট পরিবর্তন ঘটে। অতএব, এটি প্রশমিত করার প্রাথমিক উপায় হল যতটা সম্ভব আগে থেকে প্রয়োজনীয় স্থান সংরক্ষণ করা।
আকারবিহীন চিত্রগুলির কারণে সৃষ্ট লেআউট পরিবর্তনগুলি ঠিক করার সবচেয়ে সহজ উপায় হল স্পষ্টভাবে width এবং height বৈশিষ্ট্যগুলি (বা সমতুল্য CSS বৈশিষ্ট্য) সেট করা ৷ যাইহোক, এইচটিটিপি আর্কাইভ অনুসারে, 72% পৃষ্ঠাগুলিতে কমপক্ষে একটি আকারবিহীন চিত্র রয়েছে। একটি সুস্পষ্ট আকার ছাড়া, ব্রাউজারগুলি প্রাথমিকভাবে 0px এর একটি ডিফল্ট উচ্চতা সেট করবে এবং চিত্রটি অবশেষে লোড হয়ে গেলে এবং মাত্রাগুলি আবিষ্কৃত হলে এটি একটি লক্ষণীয় লেআউট পরিবর্তন ঘটাতে পারে৷ এটি যৌথ ওয়েবের জন্য একটি বিশাল সুযোগ উভয়ের প্রতিনিধিত্ব করে—এবং সেই সুযোগের জন্য এই নিবন্ধে প্রস্তাবিত অন্যান্য সুপারিশগুলির তুলনায় অনেক কম প্রচেষ্টার প্রয়োজন।
এটি মনে রাখাও গুরুত্বপূর্ণ যে চিত্রগুলিই CLS-এর একমাত্র অবদানকারী নয়৷ তৃতীয় পক্ষের বিজ্ঞাপন বা এমবেড করা ভিডিও সহ পৃষ্ঠাটি প্রাথমিকভাবে রেন্ডার হওয়ার পরে সাধারণত লোড হওয়া অন্যান্য সামগ্রীর কারণে লেআউট পরিবর্তন হতে পারে। aspect-ratio সম্পত্তি এটি মোকাবেলা করতে সাহায্য করতে পারে। এটি একটি তুলনামূলকভাবে নতুন সিএসএস বৈশিষ্ট্য যা বিকাশকারীদের স্পষ্টভাবে চিত্রগুলির পাশাপাশি অ-ইমেজ উপাদানগুলির একটি অনুপাত প্রদান করতে দেয়৷ এটি আপনাকে একটি গতিশীল width (উদাহরণস্বরূপ স্ক্রীনের আকারের উপর ভিত্তি করে) সেট করতে এবং ব্রাউজারকে স্বয়ংক্রিয়ভাবে উপযুক্ত উচ্চতা গণনা করতে দেয়, যেমন তারা মাত্রা সহ চিত্রগুলির জন্য করে।
কখনও কখনও গতিশীল বিষয়বস্তুর সঠিক আকার জানা সম্ভব হয় না কারণ এটি তার প্রকৃতির দ্বারা গতিশীল। যাইহোক, আপনি সঠিক আকার না জানলেও, আপনি এখনও লেআউট পরিবর্তনের তীব্রতা কমাতে পদক্ষেপ নিতে পারেন। একটি খালি উপাদানের জন্য ব্রাউজারকে 0px এর ডিফল্ট উচ্চতা ব্যবহার করার অনুমতি দেওয়ার চেয়ে একটি সংবেদনশীল min-height সেট করা প্রায় সবসময়ই ভাল। একটি min-height ব্যবহার করাও সাধারণত একটি সহজ সমাধান কারণ এটি এখনও প্রয়োজনে কন্টেইনারটিকে চূড়ান্ত বিষয়বস্তুর উচ্চতায় বাড়তে দেয়—এটি কেবলমাত্র সেই পরিমাণ বৃদ্ধির পরিমাণকে সম্পূর্ণ পরিমাণ থেকে একটি আশা করা যায় আরও সহনীয় স্তরে হ্রাস করেছে৷
নিশ্চিত করুন যে পৃষ্ঠাগুলি bfcache এর জন্য যোগ্য
ব্রাউজারগুলি মেমরি স্ন্যাপশট থেকে সরাসরি ব্রাউজারের ইতিহাসে আগের বা পরে একটি পৃষ্ঠা লোড করতে ব্যাক/ফরোয়ার্ড ক্যাশে —বা সংক্ষেপে bfcache নামে একটি নেভিগেশন প্রক্রিয়া ব্যবহার করে।
bfcache হল একটি উল্লেখযোগ্য ব্রাউজার-স্তরের পারফরম্যান্স অপ্টিমাইজেশান, এবং এটি পৃষ্ঠা লোডের সময় লেআউট পরিবর্তনগুলিকে সম্পূর্ণরূপে সরিয়ে দেয়, যা অনেক সাইটের জন্য যেখানে তাদের বেশিরভাগ CLS ঘটে। bfcache প্রবর্তনের ফলে CLS-তে সবচেয়ে বড় উন্নতি হয়েছে যা আমরা 2022 সালে দেখেছি।
তা সত্ত্বেও, উল্লেখযোগ্য সংখ্যক ওয়েবসাইট bfcache-এর জন্য অযোগ্য এবং তাই উল্লেখযোগ্য সংখ্যক নেভিগেশনের জন্য এই বিনামূল্যের ওয়েব পারফরম্যান্স জয় থেকে বাদ পড়ছে। যতক্ষণ না আপনার পৃষ্ঠাটি সংবেদনশীল তথ্য লোড করছে যা আপনি মেমরি থেকে পুনরুদ্ধার করতে চান না, আপনি নিশ্চিত করতে চাইবেন যে আপনার পৃষ্ঠাগুলি যোগ্য।
সাইটের মালিকদের তাদের পৃষ্ঠাগুলি bfcache এর জন্য যোগ্য কিনা তা পরীক্ষা করা উচিত এবং তারা কেন নয় তা নিয়ে কাজ করা উচিত। Chrome-এর ইতিমধ্যেই DevTools-এ একটি bfcache পরীক্ষক রয়েছে এবং এই বছর আমরা একটি নতুন Lighthouse অডিটের মাধ্যমে এখানে টুলিং বাড়ানোর পরিকল্পনা করছি যাতে একই ধরনের পরীক্ষা করা হয় এবং ক্ষেত্রে এটি পরিমাপ করার জন্য একটি API ।
যদিও আমরা CLS বিভাগে bfcache অন্তর্ভুক্ত করেছি, যেহেতু আমরা এখন পর্যন্ত সেখানে সবচেয়ে বড় লাভ দেখেছি, bfcache সাধারণত অন্যান্য কোর ওয়েব ভাইটালগুলিকেও উন্নত করবে। এটি পৃষ্ঠা নেভিগেশনগুলিকে ব্যাপকভাবে উন্নত করার জন্য উপলব্ধ তাত্ক্ষণিক নেভিগেশনগুলির একটি।
অ্যানিমেশন/ট্রানজিশন এড়িয়ে চলুন যেগুলি লেআউট-প্ররোচিত CSS বৈশিষ্ট্যগুলি ব্যবহার করে
লেআউট পরিবর্তনের আরেকটি সাধারণ উৎস হল যখন উপাদানগুলি অ্যানিমেটেড করা হয়। উদাহরণস্বরূপ, কুকি ব্যানার বা অন্যান্য নোটিফিকেশন ব্যানার যা উপরে বা নীচে স্লাইড করে প্রায়ই CLS-এর অবদানকারী। এটি বিশেষত সমস্যাযুক্ত যখন এই ব্যানারগুলি অন্যান্য বিষয়বস্তুকে পথের বাইরে ঠেলে দেয়, কিন্তু এমনকি যখন তারা না করে, তখনও তাদের অ্যানিমেট করা CLSকে প্রভাবিত করতে পারে।
যদিও HTTP আর্কাইভ ডেটা চূড়ান্তভাবে অ্যানিমেশনগুলিকে লেআউট শিফটের সাথে সংযুক্ত করতে পারে না, ডেটা দেখায় যে লেআউটকে প্রভাবিত করতে পারে এমন কোনও CSS প্রপার্টি অ্যানিমেট করে এমন পৃষ্ঠাগুলি সামগ্রিক পৃষ্ঠাগুলির তুলনায় "ভাল" CLS হওয়ার সম্ভাবনা 15% কম। কিছু বৈশিষ্ট্য অন্যদের তুলনায় খারাপ CLS এর সাথে যুক্ত। উদাহরণ স্বরূপ, যে পৃষ্ঠাগুলি margin বা border প্রস্থকে অ্যানিমেট করে সেগুলির প্রায় দ্বিগুণ হারে "দরিদ্র" CLS আছে যে পৃষ্ঠাগুলিকে সামগ্রিকভাবে দরিদ্র হিসাবে মূল্যায়ন করা হয়।
এটি সম্ভবত আশ্চর্যজনক নয়, কারণ যেকোন সময় আপনি যেকোন লেআউট-ইনডিউকিং CSS প্রপার্টি ট্রানজিশন বা অ্যানিমেট করেন, এর ফলে লেআউট শিফট হবে এবং যদি সেই লেআউট শিফটগুলি ব্যবহারকারীর ইন্টারঅ্যাকশনের 500 মিলিসেকেন্ডের মধ্যে না হয়, তাহলে তারা CLS-কে প্রভাবিত করবে।
কিছু ডেভেলপারদের কাছে আশ্চর্যজনক হতে পারে যে এটি এমন ক্ষেত্রেও সত্য যেখানে উপাদানটি স্বাভাবিক নথি প্রবাহের বাইরে নেওয়া হয়। উদাহরণস্বরূপ, একেবারে পজিশনে থাকা উপাদানগুলি যেগুলি top বা left অ্যানিমেট করে সেগুলি লেআউটের পরিবর্তন ঘটাবে, এমনকি যদি তারা অন্য সামগ্রীগুলিকে আশেপাশে ঠেলে না দেয়। যাইহোক, যদি top অ্যানিমেট করার পরিবর্তে আপনি transform:translateX() বা transform:translateY() অ্যানিমেট left , তাহলে এটি ব্রাউজারকে পৃষ্ঠার লেআউট আপডেট করতে দেবে না এবং এইভাবে কোনো লেআউট পরিবর্তন তৈরি করবে না।
ব্রাউজারের কম্পোজিটর থ্রেডে আপডেট করা যেতে পারে এমন CSS বৈশিষ্ট্যগুলির অ্যানিমেশন পছন্দ করা দীর্ঘকাল ধরে একটি কর্মক্ষমতার সর্বোত্তম অভ্যাস ছিল কারণ এটি এই কাজটিকে GPU-এ এবং মূল থ্রেডের বাইরে নিয়ে যায়। এবং এটি একটি সাধারণ পারফরম্যান্সের সর্বোত্তম অনুশীলন হওয়ার পাশাপাশি, এটি CLS উন্নত করতেও সাহায্য করতে পারে।
একটি সাধারণ নিয়ম হিসাবে, কখনই এমন কোনো CSS প্রপার্টি অ্যানিমেট বা ট্রানজিশন করবেন না যার জন্য ব্রাউজারকে পেজ লেআউট আপডেট করার প্রয়োজন হয়, যদি না আপনি এটি ব্যবহারকারীর ট্যাপ বা কী প্রেসের প্রতিক্রিয়া হিসাবে করছেন (যদিও hover করবেন না )। এবং যখনই সম্ভব, CSS transform প্রপার্টি ব্যবহার করে ট্রানজিশন এবং অ্যানিমেশন পছন্দ করুন।
লাইটহাউস অডিট এড়িয়ে চলুন অ-সংরক্ষিত অ্যানিমেশন সতর্ক করবে যখন একটি পৃষ্ঠা সম্ভাব্যভাবে ধীরগতির CSS বৈশিষ্ট্য অ্যানিমেট করে।
প্রথম ইনপুট বিলম্ব (FID)
আমাদের সুপারিশের শেষ সেটটি ফার্স্ট ইনপুট বিলম্ব (FID) এর জন্য, যা ব্যবহারকারীর ইন্টারঅ্যাকশনের প্রতি পৃষ্ঠার প্রতিক্রিয়াশীলতার একটি পরিমাপ। যদিও ওয়েবে বেশিরভাগ সাইটগুলি বর্তমানে FID-তে খুব ভাল স্কোর করে , আমরা অতীতে FID মেট্রিকের ত্রুটিগুলি নথিভুক্ত করেছি এবং আমরা বিশ্বাস করি যে ব্যবহারকারীর ইন্টারঅ্যাকশনগুলিতে তাদের সামগ্রিক প্রতিক্রিয়াশীলতা উন্নত করার জন্য সাইটগুলির জন্য এখনও অনেক সুযোগ রয়েছে৷
আমাদের নতুন ইন্টারঅ্যাকশন টু নেক্সট পেইন্ট (INP) মেট্রিক হল FID-এর সম্ভাব্য উত্তরসূরি, এবং নীচের সমস্ত সুপারিশ FID এবং INP উভয় ক্ষেত্রেই সমানভাবে প্রযোজ্য৷ সাইটগুলি FID-এর থেকে INP-এ খারাপ পারফরম্যান্স করে , বিশেষ করে মোবাইলে, আমরা "ভাল" FID থাকা সত্ত্বেও, এই প্রতিক্রিয়াশীলতার সুপারিশগুলিকে গুরুত্ব সহকারে বিবেচনা করতে বিকাশকারীদের উত্সাহিত করি৷
দীর্ঘ কাজ এড়িয়ে চলুন বা বিরতি দিন
টাস্ক হল বিচ্ছিন্ন কাজের যে কোনো অংশ যা ব্রাউজার করে। টাস্কগুলির মধ্যে রেন্ডারিং, লেআউট, পার্সিং এবং কম্পাইল করা এবং স্ক্রিপ্ট চালানো অন্তর্ভুক্ত। যখন কাজগুলি দীর্ঘ কাজ হয়ে যায়—অর্থাৎ, 50 মিলিসেকেন্ড বা তার বেশি—তারা ব্যবহারকারীর ইনপুটগুলিতে দ্রুত প্রতিক্রিয়া জানাতে সক্ষম হওয়া থেকে মূল থ্রেডটিকে ব্লক করে।
ওয়েব অ্যালম্যানাক অনুসারে, প্রচুর প্রমাণ রয়েছে যে পরামর্শ দেওয়ার জন্য যে বিকাশকারীরা দীর্ঘ কাজগুলি এড়াতে বা ভাঙতে আরও কিছু করতে পারে। যদিও এই নিবন্ধে দেওয়া অন্যান্য সুপারিশগুলির মতো দীর্ঘ কাজগুলিকে ভেঙে ফেলার প্রচেষ্টা কম নাও হতে পারে, তবে এই নিবন্ধে দেওয়া অন্যান্য কৌশলগুলির তুলনায় এটি কম প্রচেষ্টা।
যদিও আপনার সবসময় জাভাস্ক্রিপ্টে যতটা সম্ভব কম কাজ করার চেষ্টা করা উচিত, আপনি দীর্ঘ কাজগুলিকে ছোট করে বিভক্ত করে মূল থ্রেডটিকে কিছুটা সাহায্য করতে পারেন। আপনি প্রায়শই প্রধান থ্রেডের সাথে যোগ দিয়ে এটি সম্পন্ন করতে পারেন যাতে রেন্ডারিং আপডেট এবং অন্যান্য ব্যবহারকারীর মিথস্ক্রিয়া আরও দ্রুত ঘটতে পারে।
আরেকটি বিকল্প হল APIs যেমন isInputPending এবং Scheduler API ব্যবহার করার কথা বিবেচনা করা। isInputPending একটি ফাংশন যা একটি বুলিয়ান মান প্রদান করে যা নির্দেশ করে যে একটি ব্যবহারকারীর ইনপুট মুলতুবি আছে কিনা। যদি এটি true হয়, তাহলে আপনি মূল থ্রেডে যোগ দিতে পারেন যাতে এটি মুলতুবি ব্যবহারকারী ইনপুট পরিচালনা করতে পারে।
Scheduler API হল একটি আরও উন্নত পদ্ধতি, যা আপনাকে অগ্রাধিকারের একটি সিস্টেমের উপর ভিত্তি করে কাজের সময়সূচী করতে দেয় যা কাজটি ব্যবহারকারী-দৃশ্যমান বা ব্যাকগ্রাউন্ডেড কিনা তা বিবেচনা করে।
দীর্ঘ কাজগুলি ভেঙে, আপনি ব্রাউজারকে ব্যবহারকারীর-দৃশ্যমান গুরুত্বপূর্ণ কাজের সাথে ফিট করার আরও সুযোগ দিচ্ছেন, যেমন ইন্টারঅ্যাকশনের সাথে ডিল করা এবং যেকোন ফলাফল রেন্ডারিং আপডেট।
অপ্রয়োজনীয় জাভাস্ক্রিপ্ট এড়িয়ে চলুন
এতে কোন সন্দেহ নেই: ওয়েবসাইটগুলি আগের চেয়ে বেশি জাভাস্ক্রিপ্ট শিপিং করছে , এবং প্রবণতাটি শীঘ্রই পরিবর্তন হবে বলে মনে হচ্ছে না। আপনি যখন খুব বেশি জাভাস্ক্রিপ্ট পাঠান, আপনি এমন একটি পরিবেশ তৈরি করছেন যেখানে কাজগুলি মূল থ্রেডের মনোযোগের জন্য প্রতিযোগিতা করছে। এটি অবশ্যই আপনার ওয়েবসাইটের প্রতিক্রিয়াশীলতাকে প্রভাবিত করতে পারে, বিশেষ করে সেই গুরুত্বপূর্ণ স্টার্টআপ সময়ের মধ্যে।
তবে এটি একটি অমীমাংসিত সমস্যা নয়। আপনার কিছু বিকল্প আছে:
- আপনার ওয়েবসাইটের সংস্থানগুলিতে অব্যবহৃত কোড খুঁজে পেতে Chrome DevTools-এ কভারেজ টুল ব্যবহার করুন। স্টার্টআপের সময় আপনার প্রয়োজনীয় সংস্থানগুলির আকার হ্রাস করে, আপনি নিশ্চিত করতে পারেন যে আপনার ওয়েবসাইট কোড পার্সিং এবং কম্পাইল করতে কম সময় ব্যয় করে, যা একটি মসৃণ প্রাথমিক ব্যবহারকারীর অভিজ্ঞতার দিকে নিয়ে যায়।
- কখনও কখনও কভারেজ টুল ব্যবহার করে আপনি যে অব্যবহৃত কোডটি খুঁজে পান তা "অব্যবহৃত" হিসাবে চিহ্নিত করা হয় কারণ এটি স্টার্টআপের সময় কার্যকর করা হয়নি, তবে ভবিষ্যতে কিছু কার্যকারিতার জন্য এখনও প্রয়োজনীয়। এটি এমন কোড যা আপনি কোড বিভাজনের মাধ্যমে একটি পৃথক বান্ডিলে যেতে পারেন।
- আপনি যদি একটি ট্যাগ ম্যানেজার ব্যবহার করেন, তাহলে আপনার ট্যাগগুলি অপ্টিমাইজ করা হয়েছে কিনা তা নিশ্চিত করতে পর্যায়ক্রমে পরীক্ষা করতে ভুলবেন না, এমনকি যদি সেগুলি এখনও ব্যবহার করা হচ্ছে। অব্যবহৃত কোড সহ পুরানো ট্যাগগুলি আপনার ট্যাগ ম্যানেজারের জাভাস্ক্রিপ্টকে আরও ছোট এবং আরও দক্ষ করতে সাফ করা যেতে পারে।
বড় রেন্ডারিং আপডেট এড়িয়ে চলুন
জাভাস্ক্রিপ্টই একমাত্র জিনিস নয় যা আপনার ওয়েবসাইটের প্রতিক্রিয়াশীলতাকে প্রভাবিত করতে পারে। রেন্ডারিং তার নিজের অধিকারে এক ধরনের ব্যয়বহুল কাজ হতে পারে—এবং যখন বড় রেন্ডারিং আপডেট হয়, তখন সেগুলি ব্যবহারকারীর ইনপুটগুলিতে প্রতিক্রিয়া জানাতে আপনার ওয়েবসাইটের ক্ষমতাতে হস্তক্ষেপ করতে পারে৷
রেন্ডারিং কাজ অপ্টিমাইজ করা একটি সহজবোধ্য প্রক্রিয়া নয়, এবং এটি প্রায়শই আপনি কী অর্জন করার চেষ্টা করছেন তার উপর নির্ভর করে। তবুও, আপনার রেন্ডারিং আপডেটগুলি যুক্তিসঙ্গত এবং দীর্ঘ কাজগুলিতে ছড়িয়ে না পড়ে তা নিশ্চিত করতে আপনি কিছু করতে পারেন:
- যেকোনো নন-ভিজ্যুয়াল কাজ করার জন্য
requestAnimationFrame()ব্যবহার করা এড়িয়ে চলুন।requestAnimationFrame()কলগুলি ইভেন্ট লুপের রেন্ডারিং পর্বের সময় পরিচালনা করা হয় এবং যখন এই ধাপে খুব বেশি কাজ করা হয়, রেন্ডারিং আপডেটগুলি বিলম্বিত হতে পারে। এটা অত্যাবশ্যক যে আপনিrequestAnimationFrame()এর সাথে যেকোন কাজ করছেন তা কঠোরভাবে সেই কাজের জন্য সংরক্ষিত থাকে যাতে আপডেটগুলি রেন্ডার করা থাকে। - আপনার DOM সাইজ ছোট রাখুন । DOM আকার এবং লেআউট কাজের তীব্রতা পারস্পরিক সম্পর্কযুক্ত। যখন রেন্ডারারকে একটি খুব বড় DOM-এর জন্য লেআউট আপডেট করতে হয়, তখন এর লেআউট পুনঃগণনা করার জন্য প্রয়োজনীয় কাজ উল্লেখযোগ্যভাবে বৃদ্ধি পেতে পারে।
- CSS কন্টেনমেন্ট ব্যবহার করুন । সিএসএস কন্টেনমেন্ট সিএসএস
containপ্রপার্টির উপর নির্ভর করে, যা ব্রাউজারকে নির্দেশনা দেয় যে কনটেইনারের জন্য লেআউটের কাজ কিভাবে করতে হবে সেই কনটেইনারে প্রোপার্টি সেট করা আছে, এমনকিcontainসুযোগকে আলাদা করা এবং DOM-এ একটি নির্দিষ্ট রুটে রেন্ডার করা সহ। এটি সর্বদা একটি সহজ প্রক্রিয়া নয়, তবে জটিল লেআউট সমন্বিত এলাকাগুলিকে বিচ্ছিন্ন করে আপনি লেআউট করা এবং তাদের জন্য প্রয়োজনীয় কাজগুলি রেন্ডার করা এড়াতে পারেন।
উপসংহার
পৃষ্ঠার কর্মক্ষমতা উন্নত করা একটি কঠিন কাজ বলে মনে হতে পারে, বিশেষ করে বিবেচনা করার জন্য ওয়েব জুড়ে দিকনির্দেশনার পাহাড় রয়েছে। যাইহোক, এই সুপারিশগুলিতে ফোকাস করে, আপনি ফোকাস এবং উদ্দেশ্য সহ সমস্যাটির কাছে যেতে পারেন এবং আশা করি আপনার ওয়েবসাইটের মূল ওয়েব ভাইটালগুলির জন্য সুইটি সরাতে পারেন।
যদিও এখানে তালিকাভুক্ত সুপারিশগুলি কোনওভাবেই সম্পূর্ণ নয়, আমরা বিশ্বাস করি—ওয়েবের অবস্থার যত্নশীল বিশ্লেষণের উপর ভিত্তি করে—যে এই সুপারিশগুলি হল সবচেয়ে কার্যকর উপায় যা সাইটগুলি 2023 সালে তাদের কোর ওয়েব ভাইটাল কর্মক্ষমতা উন্নত করতে পারে৷
আপনি যদি এখানে তালিকাভুক্ত সুপারিশের বাইরে যেতে চান তবে আরও তথ্যের জন্য এই অপ্টিমাইজেশান গাইডগুলি দেখুন:
এখানে একটি নতুন বছর, এবং সবার জন্য একটি দ্রুততর ওয়েব! আপনার সাইটগুলি আপনার ব্যবহারকারীদের জন্য সবচেয়ে গুরুত্বপূর্ণ সব উপায়ে দ্রুত হোক।
ছবি ডেভিন অ্যাভেরি