BanTool Documentation

Appearance

Epilogue for the Frontend Series: The Performance Budget ​

Excellent! We've been on a long and detailed journey. To conclude our frontend series, we won't discuss a specific coding technique, but rather a mindset and workflow that helps ensure your application stays fast, even as the development team and the product grow over time: the Performance Budget.

The Scenario 📝 ​

  • System: A large web project with many developers contributing.
  • Problem: Initially, the website was very fast. But after a year, with many new features added, it has become sluggish. Each new feature (a JS library, a background image, a custom font...) added just "a little" bit of overhead, but gradually, "death by a thousand cuts" occurred.

The Bottleneck: Reactive Optimization 🧐 ​

The bottleneck here is the workflow. The team only starts thinking about performance after the website has already become slow. At this point, optimization becomes difficult, costly, and feels like "firefighting."

The Solution: Establish a Performance Budget (Proactive Optimization) ✅ ​

  • The Logic: A Performance Budget is a set of limits that the team sets for themselves and commits to not exceeding. It transforms performance from a "nice-to-have" into a mandatory requirement of the project.

  • Items in a Performance Budget:

    1. Size-based:
      • Total JavaScript size: e.g., < 170KB (gzipped).
      • Total image size: e.g., < 500KB.
      • Total network requests: e.g., < 20 requests.
    2. Time-based (Core Web Vitals):
      • Largest Contentful Paint (LCP): < 2.5 seconds.
      • Interaction to Next Paint (INP): < 200 milliseconds.
      • Cumulative Layout Shift (CLS): < 0.1.
    3. Tool-based:
      • Lighthouse Performance Score: Always > 90.

  • How to Apply It:

    1. Establish: The team agrees on the budget at the very beginning of the project.
    2. Automate: Integrate tools like Lighthouse CI or WebPageTest into the CI/CD pipeline.
    3. Enforce: Every time a developer creates a Pull Request, the CI/CD pipeline automatically runs performance checks. If the new code causes the page to exceed the budget (e.g., adding a library increases the JS size to 200KB), the build will fail or alert the entire team.

Analyzing the Result ✨ ​

  1. Shift from Reactive to Proactive: Instead of waiting for the site to slow down before fixing it, the team prevents performance issues before they even arise.
  2. Create a Performance Culture: Performance becomes a shared responsibility. Before adding a new library, a developer must ask themselves, "Is this library worth the performance 'cost' it introduces?"
  3. Data-Driven Decisions: All the techniques we've learned (Image Optimization, Code Splitting, Tree Shaking...) become tools for the team to use to stay under the established budget.

Final Words for Both Series ​

Our journey has taken us from optimizing the smallest SQL statements, through database architecture, to patterns in ASP.NET Core, and finally to frontend strategies.

The most important principle doesn't lie in any single technique, but in a general mindset:

  1. Start simple.
  2. Measure to find the real bottleneck.
  3. Apply the right solution to the right problem.
  4. Establish a workflow to prevent the problem from recurring.

Thank you for joining me on this very long and detailed series. I hope this knowledge will be a valuable toolkit for you in your career path. Wishing you success!