06_performance_testing

Performance Testing

Application performance is a critical feature. A slow and unresponsive application leads to a poor user experience and can negatively impact business goals. This document outlines our approach to performance testing.

Key Performance Metrics (Core Web Vitals)

We focus on the Core Web Vitals, a set of metrics that Google uses to measure user experience.

1. Largest Contentful Paint (LCP):

   • What it is: The time it takes for the largest content element (e.g., an image or a block of text) on the page to become visible.
   • Goal: Below 2.5 seconds.

2. First Input Delay (FID) / Interaction to Next Paint (INP):

   • What it is: Measures the time from when a user first interacts with your page (e.g., clicks a button) to the time when the browser is able to respond to that interaction. INP is the newer, more comprehensive metric.
   • Goal (INP): Below 200 milliseconds.

3. Cumulative Layout Shift (CLS):

   • What it is: Measures how much the content on the page unexpectedly shifts around during loading. A high CLS is very annoying for users.
   • Goal: A score below 0.1.

Other Important Metrics

• Time to First Byte (TTFB): The time it takes for the browser to receive the first byte of data from the server. A high TTFB can indicate a slow backend or API.
• Total Bundle Size: The total amount of JavaScript, CSS, and other assets that the user has to download.

Performance Testing Tools

1. Lighthouse

• What it is: An automated tool built into Chrome DevTools that audits your page for performance, accessibility, and SEO.
• How we use it:
  • Local Development: Developers should run Lighthouse audits on their local machine to get a quick read on the performance of a new feature.
  • CI/CD: We can integrate Lighthouse into our CI pipeline using tools like Lighthouse CI to automatically run audits on every Pull Request. This helps us catch performance regressions before they reach production.

2. PageSpeed Insights

• What it is: A web-based tool from Google that analyzes your live, public URL and provides a performance report based on both lab data (from Lighthouse) and real-world field data (from the Chrome User Experience Report).
• How we use it: To get a more accurate picture of how real users are experiencing our site’s performance.

3. Cloudflare Analytics

• What it is: Cloudflare’s Web Analytics provides real-user measurement (RUM) data for our Core Web Vitals.
• How we use it: To monitor the performance of our production environment over time and identify pages that need optimization.

Performance Budget

• For new projects, we will establish a “performance budget.” This is a set of constraints that we aim to stay within.
• Example Budget:
  • LCP: < 2.5s
  • Total JavaScript bundle size: < 500 KB
  • Number of network requests: < 50
• The performance budget is checked automatically in our CI pipeline. If a PR causes the budget to be exceeded, the build will fail.

Load Testing (for backend services)

• For applications with significant backend logic or high traffic expectations, we may also conduct load testing.
• Goal: To understand how our server-side functions and databases perform under heavy load.
• Tools: k6, Locust, or other load testing tools.
• This is a more specialized form of testing and will be planned on a per-project basis.