পারফরম্যান্স — দ্রুত লোড, Core Web Vitals আর critical CSS

১ · গতি কেন জরুরি — ধীর পাতা মানে হারানো পাঠক

ধরুন রাজশাহীর এক কলেজছাত্রী বাসে বসে একটি অনলাইন দোকানের লিংকে চাপ দিলেন। ফোনটি পুরোনো, কম দামের; সিগন্যাল কখনো 4G, কখনো নেমে যায়। পর্দা অনেকক্ষণ সাদা থাকে। তারপর লেখা আসে, কিন্তু অক্ষর একবার বদলে যায়। ছবি এলে লেখা নিচে সরে যায়। “অর্ডার করুন” বোতামে চাপ দিলেন, কিছুই হলো না — আবার চাপলেন। এই অভিজ্ঞতার পর তিনি আর সেই দোকানে ফেরেন না।

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

২ · একটি পাতা কীভাবে লোড হয় — critical rendering path

পর্ব ০১-এ দেখেছেন, ব্রাউজার HTML থেকে DOM আর CSS থেকে CSSOM বানায়, দুটো মিলিয়ে render tree, তারপর layout আর paint. প্রথম ছবিটি পর্দায় আসার আগে যে ধাপগুলো পার হতেই হয়, তাদের একসাথে বলে critical rendering path. এই পথে কোন ফাইল কাকে আটকায়, সেটি বোঝাই পারফরম্যান্সের অর্ধেক কাজ। ধাপে ধাপে দেখুন:

GET /shop/index.html
… DNS, TCP, TLS, সার্ভারের হিসাব …
200 OK  Content-Encoding: br
<!doctype html><html lang="bn"><head> …   ← টুকরো টুকরো আসে

<link rel="stylesheet" href="main.css">
<link rel="preload" href="bn.woff2" as="font" …>
<script src="app.js" defer></script>
… body-র ভেতরে …
<img src="hero.avif" …>   ← scanner এটিও আগেভাগে দেখে

body { font-family: "Anek Bangla", sans-serif; }
.hero { … }
@import url("extra.css");   ← এখন আরেকটি ফাইল, আরেক দফা অপেক্ষা

@font-face {
  font-family: "Anek Bangla";
  src: url(bn.woff2) format("woff2");
  font-display: swap;   ← আগে সিস্টেম ফন্টে লেখা দেখাও
}

<img src="hero.avif" alt="ঈদের নতুন কালেকশন"
     width="1200" height="600"
     fetchpriority="high">    ← lazy নয়!

<script src="app.js" defer></script>      ← HTML পড়া শেষে, ক্রম মেনে
<script src="ads.js" async></script>      ← যখনই আসে, ক্রম ছাড়া
<script src="old.js"></script>            ← ✗ parser থামিয়ে দেয়

৩ · Core Web Vitals — তিনটি সংখ্যায় ব্যবহারকারীর অভিজ্ঞতা

“পাতাটা দ্রুত” — কথাটি অস্পষ্ট। কোন মুহূর্তে দ্রুত? কার ফোনে? এই অস্পষ্টতা দূর করতে Google ২০২০ সালে Core Web Vitals নামে তিনটি মাপ ঘোষণা করে। প্রতিটি মাপ ব্যবহারকারীর অভিজ্ঞতার একটি দিক ধরে: লোড হওয়া, সাড়া দেওয়া আর স্থির থাকা।

একটি গুরুত্বপূর্ণ খুঁটিনাটি: সীমাগুলো গড়ের ওপর নয়, ৭৫তম পারসেন্টাইলের ওপর বিচার হয়। অর্থাৎ আপনার সাইটে আসা ১০০টি ভিজিটের মধ্যে অন্তত ৭৫টিতে LCP ২.৫ সেকেন্ড বা তার কম হলে তবেই “ভালো”। দ্রুত ফোনের পাঠকেরা গড়কে সুন্দর দেখাতে পারেন, কিন্তু ৭৫তম পারসেন্টাইল ধীর ফোনের পাঠকদের ভুলতে দেয় না।

LCP — প্রধান অংশটি কত দ্রুত দেখা যায়

LCP-এর “element” সাধারণত প্রথম পর্দার বড় ছবি, ভিডিওর poster, বড় background ছবি বা লেখার বড় অনুচ্ছেদ। LCP-কে চারটি টুকরোয় ভাঙা যায়: HTML আসার সময় (TTFB), ছবি খোঁজা শুরুর আগের দেরি, ছবি নামানোর সময়, আর নামানোর পরে আঁকার দেরি। একটি কাল্পনিক দোকানের হোমপেজে, ধীর 4G-তে, প্রতিটি সংশোধন কোন টুকরো ছোট করে দেখুন:

1<link rel="stylesheet" href="main.css">2/* main.css: @import "hero.css"; */3/* hero.css: .hero { background: url(hero.jpg) } */4<img src="hero.avif" fetchpriority="high"5     srcset="hero-800.avif 800w, hero-1600.avif 1600w"6     width="1600" height="800" alt="…">7<link rel="preload" href="bn.woff2" as="font" …>

CLS — পাতা কতটা লাফায়

পড়তে পড়তে লেখা হঠাৎ নিচে নেমে গেল, অথবা বোতামে চাপ দিতে যাচ্ছিলেন আর ঠিক তখন ওপরে একটি ব্যানার ঢুকে অন্য কিছুতে চাপ পড়ে গেল — এটাই layout shift. CLS এই লাফগুলোর মাপ: কতটা জায়গা জুড়ে কতদূর সরল। ব্যবহারকারী নিজে কিছু চাপার ঠিক পরের (প্রায় আধা সেকেন্ডের মধ্যে) বদল গোনা হয় না, কারণ সেটি প্রত্যাশিত। প্রধান কারণগুলো চেনা:

• মাপ ছাড়া ছবি, ভিডিও, iframe — নামার আগে উচ্চতা শূন্য।
• পরে ঢোকা জিনিস — বিজ্ঞাপন, কুকি-ব্যানার, “অ্যাপ নামান” পট্টি, জায়গা না রেখে লেখার ওপরে।
• ওয়েব ফন্ট বদল — সিস্টেম ফন্ট আর ওয়েব ফন্টের মাপ আলাদা হলে swap-এর মুহূর্তে লাইন ভাঙা বদলায়, লেখা লাফায়।
• top/margin দিয়ে অ্যানিমেশন — অন্যদের ঠেলে সরায়; transform সরালে layout shift গোনা হয় না (পর্ব ৩৮)।

নিচের প্রিভিউতে একটি খবরের পাতা। ৭০০ মিলিসেকেন্ড পরে একটি “বিজ্ঞাপন” এসে ঢোকে — ধীর নেটওয়ার্কে যেমন হয়। ব্রাউজারের নিজের PerformanceObserver দিয়ে layout shift মাপা হচ্ছে:

<style>
  body { font-family: sans-serif; max-width: 420px; min-height: 300px; }
  .slot { background: #f1f5f9; }
  .slot.reserve { min-height: 120px; }   /* আগে থেকে জায়গা রাখা */
  .banner { height: 120px; display: grid; place-items: center;
            background: #fde68a; font-weight: bold; }
</style>
<h3>আজকের খবর</h3>
<div class="slot" id="slot"></div>
<p>মেট্রো রেলে আজ রেকর্ড যাত্রী। এই লেখাটি পড়তে পড়তেই ওপরে হঠাৎ কিছু ঢুকলে লেখা নিচে সরে যায়।</p>
<button>পুরো খবর পড়ুন</button>
<script>
  let cls = 0;
  if (PerformanceObserver.supportedEntryTypes.includes('layout-shift')) {
    new PerformanceObserver(list => {
      for (const e of list.getEntries()) if (!e.hadRecentInput) cls += e.value;
    }).observe({ type: 'layout-shift', buffered: true });
  } else console.log('এই ব্রাউজার layout-shift মাপে না (এখন শুধু Chromium-এ আছে)');
  setTimeout(() => {
    document.getElementById('slot').innerHTML = '<div class="banner">বিজ্ঞাপন</div>';
  }, 700);
  setTimeout(() => console.log('CLS = ' + cls.toFixed(3)), 1500);
</script>

৪ · INP — চাপ দিলে পাতা কত দ্রুত সাড়া দেয়

পাতা দ্রুত দেখা গেলেই কাজ শেষ নয়। bKash অ্যাপে “Send Money” চাপার পর এক সেকেন্ড কিছু না ঘটলে মনে হয় অ্যাপ আটকে গেছে, আর মানুষ আবার চাপেন। ওয়েবে এই অনুভূতির মাপ INP: একটি ক্লিক, ট্যাপ বা কী চাপা থেকে পর্দায় পরের ছবি আসা পর্যন্ত সময়। পুরো ভিজিটে যত interaction হয়, তার মধ্যে প্রায় সবচেয়ে ধীরটিই INP (অনেক interaction থাকলে ব্যতিক্রমী দু-একটি বাদ দেওয়া হয়)।

আগে এই জায়গায় ছিল FID, যা শুধু প্রথম interaction-এর আগের অপেক্ষা মাপত — handler চালানো আর পর্দা আঁকার সময় ধরত না। ২০২৪ সালের মার্চে INP তার জায়গা নেয়। একটি ট্যাপের ভেতরে কী কী ঘটে, দেখুন:

INP-এর বড় অংশ JavaScript-এর বিষয় (JavaScript কোর্সের event loop-এর পর্ব)। তবে HTML-CSS লেখকেরও ভূমিকা আছে: ছোট DOM, সস্তা CSS, আর যেখানে সম্ভব HTML-এর নিজের <details>, <dialog>, popover (পর্ব ১১) — এগুলো আপনার script-এর সারিতে দাঁড়ায় না।

৫ · মাপুন, অনুমান নয় — Lighthouse, field data আর Performance প্যানেল

পারফরম্যান্সের প্রথম নিয়ম: আগে মাপুন, তারপর ঠিক করুন, তারপর আবার মাপুন। অনুমানে কাজ করলে প্রায়ই এমন জিনিস “ঠিক” করা হয়, যা সমস্যাই ছিল না। মাপ দুই রকম:

Lab data আর field data প্রায়ই মেলে না, আর সেটি স্বাভাবিক। Lighthouse-এ ৯৫ স্কোর পেয়েও CrUX-এ INP “খারাপ” হতে পারে, কারণ আসল ব্যবহারকারী পাতা খোলার পর ক্লিক করেন, স্ক্রল করেন, বিজ্ঞাপন দেরিতে আসে — ল্যাবের একবার খোলায় এসব ঘটে না।

পাতার ভেতর থেকেও মাপা যায়: ব্রাউজার প্রতিটি নামানো ফাইলের হিসাব রাখে (Resource Timing API), আর web-vitals-এর মতো ছোট library দিয়ে LCP, INP, CLS সংগ্রহ করে নিজের সার্ভারে পাঠানো যায় — একেই বলে নিজের RUM.

৬ · CSS লোডের কৌশল — render-blocking থেকে caching

পর্ব ১৬-এ জেনেছেন, head-এর stylesheet render-blocking — তাই CSS যত বড় আর যত দেরিতে আসে, প্রথম পর্দাও তত দেরিতে।

media attribute — কোন stylesheet আসলে আটকায়

একটি <link rel="stylesheet">-এর media যদি এখনকার পর্দার সাথে না মেলে — যেমন media="print" — ব্রাউজার ফাইলটি কম অগ্রাধিকারে নামায় ঠিকই, কিন্তু তার জন্য render আটকায় না। তাই print-এর CSS আলাদা ফাইলে media="print" দিয়ে রাখলে প্রথম পর্দা হালকা হয়। নিচের প্রিভিউতে তিনটি stylesheet, তিনটি আলাদা media:

<style>
  body { font-family: sans-serif; }
  p { padding: 8px; border-radius: 6px; }
</style>
<style media="print"> .a { background: #fecaca; } </style>
<style media="(min-width: 400px)"> .b { background: #bbf7d0; } </style>
<style media="screen"> .c { background: #bfdbfe; } </style>

<p class="a">media="print" — শুধু ছাপার সময় লাল</p>
<p class="b">media="(min-width: 400px)" — চওড়া পর্দায় সবুজ</p>
<p class="c">media="screen" — পর্দায় সবসময় নীল</p>
<script>
  (function m() {
    if (!document.body.offsetWidth) return setTimeout(m, 50);  // পর্দার মাপ জানা পর্যন্ত
    for (const s of document.styleSheets) {
      const q = s.media.mediaText || 'all';
      console.log(q + (matchMedia(q).matches
        ? '  → এখন মেলে: link হলে render আটকাত'
        : '  → মেলে না: link হলে নামত, কিন্তু render আটকাত না'));
    }
  })();
</script>

Critical CSS — প্রথম পর্দার CSS head-এ

দেড়শো পাতার একটি সাইটের পুরো CSS হয়তো কয়েকশো KB, অথচ হোমপেজের প্রথম পর্দা আঁকতে লাগে তার সামান্য অংশ। Critical CSS কৌশলে সেই অংশটুকু <style> হিসেবে HTML-এর ভেতরেই রাখা হয় — আলাদা ফাইলের অপেক্ষা নেই — আর বাকি CSS আসে পরে, render না আটকে:

<head>
  <style>
    /* critical: শুধু header, hero আর প্রথম পর্দার layout */
    body { margin: 0; font-family: "Anek Bangla", system-ui, sans-serif; }
    .site-header { display: flex; justify-content: space-between; padding: 12px 16px; }
    .hero { min-height: 60vh; display: grid; place-items: center; }
  </style>

  <!-- বাকি CSS: আগে print হিসেবে নামে (আটকায় না), নামা শেষে সব পর্দায় প্রযোজ্য -->
  <link rel="stylesheet" href="/css/site.css?v=20261020"
        media="print" onload="this.media='all'">
  <noscript><link rel="stylesheet" href="/css/site.css?v=20261020"></noscript>
</head>

দামও আছে: inline CSS ক্যাশ হয় না, প্রতিটি পাতায় আবার আসে; হাতে বেছে বের করা কঠিন, তাই সাধারণত build টুল দিয়ে করা হয়; আর critical অংশ ভুল হলে পাতা সাজানোর পরে আবার বদলায়, যা CLS বাড়ায়। ছোট সাইটে প্রায়ই একটিমাত্র ছোট, minify করা, ভালোভাবে ক্যাশ হওয়া CSS ফাইলই যথেষ্ট।

@import-এর শিকল, minification আর compression

• @import এড়ান। CSS-এর ভেতরের @import ব্রাউজার দেখে প্রথম ফাইল নামার পরে, তাই প্রতিটি ধাপ এক দফা বাড়তি অপেক্ষা। দরকার হলে HTML-এ পাশাপাশি একাধিক <link> দিন — এরা একসাথে নামে। (Google Fonts-এর @import কোডের বদলে তাদের <link> কোডটিই নিন।)
• Minification. space, লাইন-ভাঙা আর comment মুছে ফাইল ছোট করা। নিজের কোড পড়ার মতো রেখে, প্রকাশের সময় build টুল (পর্ব ৫০-এর PostCSS, বা cssnano, Lightning CSS) দিয়ে minify করুন।
• Compression — gzip আর Brotli. সার্ভার পাঠানোর আগে ফাইল চেপে ছোট করে; ব্রাউজার Accept-Encoding header-এ জানায় সে কোনগুলো বোঝে, আর উত্তরে আসে Content-Encoding: br বা gzip. লেখা-ভিত্তিক HTML, CSS, JS, SVG অনেক ছোট হয়; Brotli সাধারণত gzip-এর চেয়েও ভালো চাপে। ছবি আর WOFF2 আগে থেকেই চাপা। Network প্যানেলে ফাইলের Response Headers-এ দেখে নিন compression চালু কি না।

Caching আর cache-busting

সবচেয়ে দ্রুত ফাইল সেটি, যা নামাতেই হয় না। সার্ভার Cache-Control header দিয়ে ব্রাউজারকে বলে একটি ফাইল কতদিন নিজের কাছে রাখা যাবে। কিন্তু দীর্ঘদিন ক্যাশে রাখলে ফাইল বদলানোর পর পুরোনো কপি দেখানোর ঝুঁকি — তার সমাধান পর্ব ১৬-এর cache-busting: ফাইল বদলালে ঠিকানাও বদলানো (style.css?v=20261020, বা build টুলের style.3f9a1c.css). এই সাইটটি নিজেও এভাবেই চলে — CSS-JS কয়েকদিন ক্যাশে থাকে, আর বদলালে ?v=-এর তারিখ বদলানো হয়। cPanel-এর মতো Apache সার্ভারে .htaccess-এ এমন নিয়ম লেখা যায়:

# ঠিকানায় version থাকা CSS/JS/ফন্ট/ছবি — দীর্ঘ সময় ক্যাশ
<FilesMatch "\.(css|js|woff2|avif|webp|svg)$">
  Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>
# HTML — প্রতিবার সার্ভারকে জিজ্ঞেস করো নতুন আছে কি না
<FilesMatch "\.html$">
  Header set Cache-Control "no-cache"
</FilesMatch>

এক বছরের immutable ক্যাশ নিরাপদ তখনই, যখন প্রতিটি বদলে ঠিকানাও বদলায়। আর no-cache মানে “ক্যাশ কোরো না” নয়, “ব্যবহারের আগে জিজ্ঞেস করো” — ফাইল না বদলালে সার্ভার ছোট্ট 304 Not Modified পাঠায়।

৭ · ফন্ট আর ছবি — পাতার সবচেয়ে ভারী দুই অতিথি

ওয়েব ফন্ট — বিশেষ করে বাংলা

বাংলা ফন্ট ইংরেজির চেয়ে প্রায়ই অনেক ভারী, কারণ যুক্তাক্ষর, কার-চিহ্ন আর তাদের নানা রূপের জন্য ফাইলে অনেক বেশি glyph থাকে (পর্ব ১৪, ২১)। চারটি weight-এর একটি বাংলা ফন্ট মানে চারটি আলাদা ভারী ফাইল। কৌশলগুলো:

/* বাংলা অক্ষরের ফাইল — পাতায় বাংলা থাকলে তবেই নামবে */
@font-face {
  font-family: "Anek Bangla";
  src: url(/fonts/anek-bangla-bn.woff2) format("woff2");
  font-weight: 400 700;                   /* variable font: এক ফাইলে সব weight */
  font-display: swap;
  unicode-range: U+0980-09FE, U+200C-200D, U+25CC;
}
/* ইংরেজি অক্ষরের ছোট ফাইল */
@font-face {
  font-family: "Anek Bangla";
  src: url(/fonts/anek-bangla-latin.woff2) format("woff2");
  font-weight: 400 700;
  font-display: swap;
  unicode-range: U+0000-00FF;
}
body { font-family: "Anek Bangla", "Noto Sans Bengali", system-ui, sans-serif; }

• font-display: swap — ফন্ট আসার আগে লেখা সিস্টেম ফন্টে দেখায়, অদৃশ্য রাখে না (FOIT নয়, FOUT). সাজসজ্জার ফন্টে optional ভাবা যায় — ধীর নেটওয়ার্কে ফন্ট বাদ পড়বে, কিন্তু লেখা লাফাবে না।
• Subsetting আর unicode-range — ফন্টকে অক্ষরের দল ধরে কয়েকটি ফাইলে ভাগ করা; ব্রাউজার শুধু সেই ফাইল নামায়, যার অক্ষর পাতায় আছে। Google Fonts বাংলা ফন্টকে এভাবেই “bengali”, “latin” subset-এ ভাগ করে পাঠায়।
• কম weight — বেশিরভাগ সাইট দুটিতেই চলে: সাধারণ আর মোটা। অথবা একটি variable font — এক ফাইলে সব weight.
• preconnect আর preload — বাইরের ফন্ট-সার্ভারে <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> (পর্ব ১৩)। নিজের সার্ভারের একটি জরুরি ফন্টে <link rel="preload" href="/fonts/anek-bangla-bn.woff2" as="font" type="font/woff2" crossorigin> — ফন্টের preload-এ crossorigin লাগবেই, নইলে ফাইল দুবার নামে। সব ফন্ট preload করবেন না; preload করা জিনিস অন্য জরুরি জিনিসের সাথে প্রতিযোগিতা করে।
• সিস্টেম ফন্টও একটি উত্তর — বেশিরভাগ Android ফোনে বাংলা ফন্ট (যেমন Noto Sans Bengali) আগে থেকেই থাকে: শূন্য byte, শূন্য অপেক্ষা।

ছবি — পর্ব ৩২-এর পুনরাবৃত্তি, পারফরম্যান্সের চোখে

বেশিরভাগ পাতায় byte-এর হিসাবে সবচেয়ে বড় অংশ ছবি। পর্ব ৩২-এ শেখা নিয়মগুলো এখানে একসাথে: srcset আর sizes দিয়ে ফোনে ছোট ছবি; <picture> দিয়ে AVIF/WebP (দুটিই সব প্রধান ব্রাউজারে আছে — WebP বহু বছর ধরে, AVIF তুলনামূলক সাম্প্রতিক; Can I use দেখে নিন) আর পুরোনো ব্রাউজারের জন্য JPEG; প্রথম পর্দার বাইরের ছবিতে loading="lazy" (Widely available); প্রধান ছবিতে fetchpriority="high" (Baseline Newly available — না চিনলে ব্রাউজার শুধু উপেক্ষা করে, কোনো ক্ষতি নেই); আর প্রতিটি ছবিতে width ও height.

শেষেরটির কাজ নিজের চোখে দেখুন। দুটি ছবি — প্রথমটিতে width/height আছে, দ্বিতীয়টিতে নেই। ছবি নামা শুরুর মুহূর্তে আর নামা শেষে দুটির উচ্চতা মাপা হচ্ছে, তারপর Resource Timing থেকে প্রতিটি ছবির সময় আর আকার:

<style>
  img { display: block; width: 280px; max-width: 100%; height: auto;
        margin-bottom: 8px; background: #e2e8f0; }
</style>
<img id="a" alt="মাপ দেওয়া ছবি" width="1280" height="720" fetchpriority="high">
<img id="b" alt="মাপ ছাড়া ছবি">
<script>
  const a = document.getElementById('a'), b = document.getElementById('b');
  const r = '?r=' + Math.random();              // ক্যাশ এড়াতে
  (function go() {
    if (!document.body.offsetWidth) return setTimeout(go, 50);
    a.src = '../image/ABCL-TECH-Cover.jpg' + r;
    b.src = '../image/ai-and-education.jpg' + r;
    console.log('নামার আগে:  a = ' + a.offsetHeight + 'px, b = ' + b.offsetHeight + 'px');
    let n = 0;
    a.onload = b.onload = () => {
      if (++n < 2) return;
      console.log('নামার পরে:  a = ' + a.offsetHeight + 'px, b = ' + b.offsetHeight + 'px');
      performance.getEntriesByType('resource')
        .filter(e => e.name.includes('/image/'))
        .forEach(e => console.log(e.name.split('/').pop().split('?')[0] + ': ' +
          Math.round(e.duration) + 'ms-এ নেমেছে'));
    };
  })();
</script>

৮ · ব্রাউজারের আঁকার খরচ — containment, content-visibility আর layout thrashing

সব ফাইল দ্রুত এলেও পাতা ধীর লাগতে পারে, যদি আঁকতে আর সাজাতে ব্রাউজারকে বেশি খাটতে হয়। পর্ব ৩৮-এ দেখেছেন: transform আর opacity-র অ্যানিমেশন সাধারণত শুধু compositing-এ চলে, আর width, top, margin প্রতি ফ্রেমে layout জাগায়, যা jank আনে। সেই চিন্তা এবার গোটা পাতায়।

contain — ব্রাউজারকে দেওয়া প্রতিশ্রুতি

একটি বড় পাতায় একটি কার্ডের লেখা বদলালে ব্রাউজারকে ধরে নিতে হয়, এর প্রভাব পুরো পাতায় পড়তে পারে — পাশের কার্ড সরতে পারে, ছায়া বাইরে ছড়াতে পারে। contain property দিয়ে আপনি প্রতিশ্রুতি দেন যে “এই বাক্সের ভেতরের বদল বাইরে যাবে না”, আর ব্রাউজার হিসাব ছোট এলাকায় রাখে:

contain সব প্রধান ব্রাউজারে বহুদিন ধরে আছে (Baseline Widely available). কিন্তু পার্শ্বপ্রতিক্রিয়াগুলো সত্যিকারের — নিজে দেখুন:

body { font-family: sans-serif; padding: 24px; }
.card {
  position: relative; width: 220px; margin-bottom: 28px;
  padding: 18px; border-radius: 10px;
  background: #ecfeff; border: 1px solid #67e8f9;
}
.badge {
  position: absolute; top: -12px; right: -14px;
  padding: 2px 8px; border-radius: 99px;
  background: #e11d48; color: #fff; font-size: 13px;
}
.contained {
  contain: paint;          /* বাক্সের বাইরে কিছু আঁকা হবে না */
}

content-visibility: auto — পর্দার বাইরের অংশ পরে

একটি লম্বা পাতা ভাবুন — অর্ডারের ইতিহাস, মন্তব্যের দীর্ঘ তালিকা, বা এই কোর্সের মতো লম্বা পর্ব। ব্যবহারকারী প্রথমে দেখেন শুধু ওপরের অংশ, অথচ ব্রাউজার শুরুতেই হাজারো element-এর style আর layout হিসাব করে। content-visibility: auto বলে: “এই অংশ পর্দা থেকে দূরে থাকলে এর ভেতরটা আঁকা আর সাজানো বাদ রাখো; কাছে এলে করো।” মাপ না জেনে বাদ রাখলে বাক্সের উচ্চতা শূন্য হয়ে scrollbar লাফাত — তাই সাথে লাগে contain-intrinsic-size, একটি আন্দাজি মাপ। auto 60px লিখলে প্রথমে 60px, আর একবার আঁকা হলে ব্রাউজার আসল মাপ মনে রাখে।

<style>
  .item { padding: 8px; border-bottom: 1px solid #ddd; font: 14px sans-serif; }
  .cv .item { content-visibility: auto; contain-intrinsic-size: auto 60px; }
</style>
<p id="out">মাপা হচ্ছে…</p>
<script>
  function timeLayout(cls) {
    const box = document.createElement('div');
    box.className = cls;
    for (let i = 1; i <= 3000; i++) {
      const d = box.appendChild(document.createElement('div'));
      d.className = 'item';
      d.innerHTML = '<b>অর্ডার #' + i + '</b> — ঢাকা থেকে খুলনা, ৳ ' + i * 37 +
        '<br>অবস্থা: কুরিয়ারের পথে · আনুমানিক ২ দিন';
    }
    const t0 = performance.now();
    document.body.append(box);
    box.offsetHeight;                          // এখনই layout করতে বাধ্য করা
    const ms = performance.now() - t0;
    box.remove();
    return ms.toFixed(1) + 'ms';
  }
  (function m() {
    if (!document.body.offsetWidth) return setTimeout(m, 50);
    timeLayout('');                            // প্রথম চালানোর বাড়তি খরচ বাদ
    console.log('content-visibility ছাড়া:   ' + timeLayout(''));
    console.log('content-visibility: auto সহ: ' + timeLayout('cv'));
    document.getElementById('out').textContent = 'মাপা শেষ — ফল নিচে।';
  })();
</script>

সাপোর্ট: content-visibility প্রথম আসে Chromium-এ, পরে Firefox আর Safari-তেও এসেছে; এখন এটি Baseline Newly available. যে ব্রাউজার চেনে না, সে স্বাভাবিকভাবে সব আঁকে — তাই এটি নিরাপদ progressive enhancement. আরেকটি সুবিধা: display: none-এর মতো নয়, auto অবস্থায় না-আঁকা লেখাও পাতার ভেতরে খোঁজা (Ctrl+F) যায় আর screen reader-এর কাছে থাকে।

দামি property — যা আঁকতে ফোন হাঁপায়

• বিশাল, ঝাপসা box-shadow — 0 30px 120px-এর মতো ছায়া শত শত কার্ডে, বিশেষ করে স্ক্রল বা অ্যানিমেশনের সময় আবার আঁকতে হলে ভারী।
• filter: blur() আর backdrop-filter — বড় এলাকায় glassmorphism দুর্বল GPU-তে ধীর (পর্ব ৪১)। ছোট এলাকায়, অল্প জায়গায় রাখুন।
• background-attachment: fixed — স্ক্রলের প্রতিটি ধাপে পুরো পটভূমি আবার আঁকা লাগতে পারে; অনেক মোবাইল ব্রাউজার একে উপেক্ষাই করে।
• সব কিছুতে will-change — প্রতিটি আলাদা স্তর GPU-র মেমরি খায়; মেপে, অল্প জায়গায় (পর্ব ৩৮)।

DevTools-এর Rendering প্যানেলে “Paint flashing” চালু করলে আবার আঁকা অংশ সবুজ ঝলক দেয়, আর “Layout Shift Regions” লাফানো অংশ দেখায়।

Layout thrashing — JavaScript-এর লুকানো ফাঁদ

ব্রাউজার অলস, আর সেটি ভালো: style বদলালে সে তখনই layout করে না, ফ্রেম আঁকার আগে একবারে করে। কিন্তু JavaScript যদি বদলের ঠিক পরেই offsetWidth, getBoundingClientRect()-এর মতো মাপ জানতে চায়, ব্রাউজারকে তখনই layout করতে হয় — একে বলে forced synchronous layout. লুপের ভেতরে “লেখো-পড়ো-লেখো-পড়ো” করলে প্রতিটি ঘুরে একটি করে layout — এটাই layout thrashing. মেপে দেখুন:

const wrap = document.getElementById('boxes');
for (let i = 0; i < 600; i++) {
  const d = document.createElement('div');
  d.style.cssText = 'height:10px; width:20px; background:#0f766e';
  wrap.append(d);
}
const items = [...wrap.children];

function thrash() {               // পড়ো → লেখো → পড়ো → লেখো …
  for (const d of items) d.style.width = (d.offsetWidth + 1) + 'px';
}
function batched() {              // আগে সব পড়ো, তারপর সব লেখো
  const widths = items.map(d => d.offsetWidth);
  items.forEach((d, i) => { d.style.width = (widths[i] + 1) + 'px'; });
}
function measure(fn) {
  const t0 = performance.now();
  fn();
  wrap.offsetHeight;              // শেষের layout-টিও হিসাবে ধরা
  return (performance.now() - t0).toFixed(1) + 'ms';
}
(function go() {                  // পাতা সাজানো শুরু হওয়া পর্যন্ত অপেক্ষা
  if (!document.body.offsetWidth) return setTimeout(go, 50);
  console.log('layout thrashing: ' + measure(thrash));
  console.log('batched:          ' + measure(batched));
})();

৯ · DOM-এর আকার, third-party script আর একটি চেকলিস্ট

কম element, কম কাজ

প্রতিটি element ব্রাউজারের কাছে একটি বাড়তি হিসাব: style মেলানো, layout, paint, আর মেমরি। অপ্রয়োজনীয় <div>-এর স্তরের পর স্তর (“div-soup”) পাতা বড় করে, আর প্রতিটি ক্লিকের পরের style হিসাবকেও ভারী করে — যা INP-তে ধরা পড়ে। DOM অনেক বড় হলে Lighthouse “excessive DOM size” সতর্কতা দেয়। অর্থবহ HTML (পর্ব ১০) সাধারণত ছোটও হয়।

একটি লুকানো ভার হলো একই inline SVG আইকন বারবার। ৫০টি কার্ডে একই আইকনের পুরো <path> মানে ৫০ গুণ HTML. সমাধান পর্ব ৪৪-এর: একবার <symbol> হিসেবে রেখে প্রতিটি জায়গায় <use href="#cart">, অথবা আইকনটি আলাদা .svg ফাইল হিসেবে <img>-এ — তখন সেটি একবার নেমে ক্যাশে থাকে।

Third-party script — অন্যের কোড, আপনার খরচ

বিজ্ঞাপন, analytics, চ্যাট উইজেট, সোশ্যাল শেয়ার বোতাম, ভিডিও embed — এগুলো third-party script: অন্য কোম্পানির সার্ভার থেকে আসা কোড। এদের আকার আর আচরণ আপনার হাতে নেই; একটি script আরও কয়েকটি script ডেকে আনতে পারে, main thread-এ long task চালাতে পারে, দেরিতে জায়গা নিয়ে CLS বাড়াতে পারে। এই সাইটটিও Google AdSense বিজ্ঞাপন আর analytics ব্যবহার করে — বিজ্ঞাপনই কোর্সগুলোকে বিনামূল্যে রাখে। তাই প্রশ্নটি “থাকবে কি না” নয়, “কীভাবে কম খরচে”:

• async বা defer — কোনো third-party script যেন parser না আটকায়। AdSense আর Google Analytics-এর নিজেদের দেওয়া কোডেও async থাকে।
• জায়গা আগে রাখুন — বিজ্ঞাপন বা embed-এর জন্য আন্দাজি min-height, যাতে এলে লেখা না লাফায় (অংশ ৩-এর প্রিভিউ)।
• দরকার হলে তবেই লোড — YouTube ভিডিওর জায়গায় শুরুতে শুধু ছবি আর play বোতাম (facade), চাপ দিলে তবেই আসল <iframe>.
• হিসাব রাখুন — মাঝে মাঝে তালিকা করুন কোন script আছে আর এখনো কাজে লাগে কি না; ভুলে যাওয়া tracking script নীরব শত্রু।

প্রকাশের আগে — পারফরম্যান্সের চেকলিস্ট

বড় দলে এই সীমাগুলো আগে থেকে লিখে রাখা হয় — একে বলে performance budget. ছোট প্রজেক্টে নিচের তালিকাটিই যথেষ্ট:

• PageSpeed Insights-এ মোবাইলে LCP ≤ ২.৫ সেকেন্ড, CLS ≤ ০.১; field data থাকলে INP ≤ ২০০ মিলিসেকেন্ড
• CSS-এ কোনো @import নেই; CSS minify করা, সার্ভারে gzip/Brotli চালু; print-এর CSS-এ media="print"
• CSS-JS-এর ঠিকানায় version (?v=), সাথে দীর্ঘ Cache-Control
• ফন্টে font-display: swap, দুই-তিনটির বেশি weight নয়, বাংলা-ইংরেজি subset; জরুরি একটি ফন্টই শুধু preload
• প্রতিটি <img>-এ width/height আর alt; প্রধান ছবি HTML-এ, lazy নয়, fetchpriority="high"; বাকি নিচের ছবি lazy; AVIF/WebP আর srcset
• সব script-এ defer বা async; বিজ্ঞাপন-embed-এর জন্য জায়গা রাখা
• CPU 4× আর “Slow 4G” throttling দিয়ে Performance প্যানেলে রেকর্ড করে দেখেছি — বড় long task বা layout thrashing নেই

১০ · AI-এর যুগে — AI-এর “দ্রুত করার” পরামর্শ যাচাই

“আমার সাইট দ্রুত করে দাও” — AI কয়েক সেকেন্ডে লম্বা তালিকা দেয়। অনেক পরামর্শ ঠিক, কিন্তু অভিজ্ঞতায় দেখা যায় কয়েকটি ভুল বারবার আসে, কারণ AI শিখেছে বহু বছরের পুরোনো ব্লগ থেকে, আর সে আপনার পাতা মেপে দেখেনি:

AI-এর পারফরম্যান্স-পরামর্শ হাতে পেলে — যাচাইয়ের চেকলিস্ট

• পরিবর্তনের আগে আর পরে একই অবস্থায় (একই throttling, Incognito) Lighthouse চালিয়ে তুলনা করেছি
• Performance প্যানেলে দেখেছি LCP element আসলে কোনটি — AI যেটি ধরে নিয়েছে, সেটিই কি না
• Rendering প্যানেলের “Layout Shift Regions” দিয়ে দেখেছি কিছু লাফায় না
• নতুন attribute বা property-র সাপোর্ট MDN আর Can I use-এ নিজে মিলিয়েছি
• validator.w3.org-এ HTML পরিষ্কার; গতি বাড়াতে গিয়ে alt, label বা কীবোর্ড-ব্যবহার বাদ পড়েনি
• কয়েক সপ্তাহ পরে PageSpeed Insights-এ field data-ও উন্নত হয়েছে কি না, দেখেছি