Learn Tailwind CSS - Testing, Observability & Monitoring

#Introduction

A wrong utility class can break the layout without any error — no exception, no failing test, just pixels shifting. Episode 20 covers how to catch such regressions: visual regression testing, performance monitoring, and quality gates on CI.

Because utility-based UI is hard to test with ordinary assertions, the strategy shifts to visual comparison and objective metrics: pixel-by-pixel screenshot comparison, CSS size budgets, and continuously monitored Web Vitals metrics.

#Visual Regression Testing

#Playwright Snapshots

Playwright can take screenshots and compare them against a baseline:

Snapshot with Playwright

import { test, expect } from "@playwright/test";
 
test("halaman utama tidak berubah", async ({ page }) => {
  await page.goto("/");
  await expect(page).toHaveScreenshot("home.png", { maxDiffPixelRatio: 0.02 });
});

toHaveScreenshot saves the first image as a baseline, then compares against it on subsequent runs. maxDiffPixelRatio: 0.02 allows a two percent difference tolerance — enough to suppress small noise without missing real regressions.

#Chromatic for Storybook

For components that already have stories from episode 19, Chromatic compares Storybook captures in the cloud. Every class change shows up as a visual diff you can review pixel by pixel — a flow that suits component libraries very well.

Remember: visual testing is only as good as its baseline. A stale baseline — for example not updated after a major redesign — will make the whole team chase misleading diffs. Update baselines deliberately on commits that genuinely change appearance, not automatically on every run.

#Performance Monitoring

#Lighthouse and Web Vitals

Lighthouse audits performance, accessibility, and best practices:

npx lighthouse https://example.com --output=html --output-path=report.html

Pay attention to the metrics CSS affects: LCP (time for the largest element to be visible — affected by render-blocking CSS), CLS (layout shift — affected by fonts and images without dimensions), and TBT (total blocking time). For continuous monitoring, Lighthouse CI runs audits on every commit.

#Budgets in Webpack and Vite

Set CSS size budgets directly in the bundler:

Performance budget in Vite

export default {
  build: {
    cssCodeSplit: true,
    chunkSizeWarningLimit: 300,
  },
};

And for full-scale audits, set up Lighthouse CI:

ci:
  budget:
    - path: "/*"
      resourceSizes:
        stylesheet: 100

stylesheet: 100 means the total CSS per page is capped at 100KB — above that, CI fails.

#Error-flooring CSS Regressions in CI

Combine three gates into the pipeline so CSS regressions are caught before production:

1. Unit tests — CVA class snapshots and toHaveClass assertions from episode 15.
2. Visual tests — Playwright or Chromatic screenshots for critical components.
3. Budget check — CSS size and Lighthouse metrics compared against thresholds.

An example CI step that checks CSS size:

size=$(wc -c < dist/output.css)
if [ "$size" -gt 102400 ]; then
  echo "CSS terlalu besar: $size bytes" >&2
  exit 1
fi

wc -c < dist/output.css counts the CSS file's bytes, and the script fails the pipeline if it exceeds 100KB. That's a cheap error floor — any PR that bloats it is immediately visible.

#Conclusion

Episode 20 completed your quality gates: visual regression testing with Playwright and Chromatic, performance monitoring with Lighthouse and Web Vitals, and budgets and automated checks that prevent CSS regressions from reaching CI.

Key takeaways:

• Screenshot snapshots catch visual regressions without any error.
• Chromatic compares Storybook captures in the cloud.
• LCP, CLS, and TBT are the metrics most affected by CSS.
• Lighthouse CI runs audits on every commit.
• Stylesheet budgets can be enforced in the bundler and CI.
• Combining unit, visual, and budget creates a strong regression floor.

Next, in episode 21, we'll cover migration strategies & large-scale refactors — incremental migration techniques from traditional CSS, monorepo considerations for sharing config and tokens, and rollback and compatibility testing strategies.