Is your feature request related to a problem? Please describe.
Currently, as we introduce more complex themes, SVG filters, and custom features, we lack a formal way to measure performance regressions in our SVG rendering pipeline (lib/svg/generator.ts). I'm frustrated that we have no objective "performance budget" to ensure that as the application scales, we aren't inadvertently increasing the latency of the /api/streak endpoint for our users.
Describe the solution you'd like
I propose implementing an automated performance benchmarking suite within the CI pipeline:
Integrate a Benchmarking Tool: Add tinybench to the existing vitest configuration to provide structured performance metrics.
Create Benchmark Suite: Add a new file at bench/svg-render.bench.ts that benchmarks the generateSVG function under various scenarios (e.g., complex themes, high contribution counts).
Define Performance Budget: Establish a threshold (e.g., < 100ms for standard renders) so that if a code change causes a significant slowdown, the CI build alerts contributors immediately.
Reporting: Ensure benchmark results are logged during CI runs to track performance trends over time.
Describe alternatives you've considered
I have considered the following alternatives, but found them insufficient:
Manual Performance Profiling: Running Chrome DevTools performance audits manually is time-consuming and not repeatable for every PR, making it prone to human error and difficult to enforce as a standard.
Existing Unit Tests: While we have functional tests in lib/svg/generator.test.ts, they focus on output correctness rather than execution time. Attempting to hijack these for performance measurements would couple functional requirements with performance budgets, which is poor practice.
External Monitoring Tools: Integrating third-party SaaS performance monitoring would increase infrastructure complexity and cost for what is essentially a build-time requirement. An in-repo benchmarking suite with tinybench is more lightweight, free, and aligns with the project’s existing CI/CD setup.
Is your feature request related to a problem? Please describe.
Currently, as we introduce more complex themes, SVG filters, and custom features, we lack a formal way to measure performance regressions in our SVG rendering pipeline (lib/svg/generator.ts). I'm frustrated that we have no objective "performance budget" to ensure that as the application scales, we aren't inadvertently increasing the latency of the /api/streak endpoint for our users.
Describe the solution you'd like
I propose implementing an automated performance benchmarking suite within the CI pipeline:
Integrate a Benchmarking Tool: Add tinybench to the existing vitest configuration to provide structured performance metrics.
Create Benchmark Suite: Add a new file at bench/svg-render.bench.ts that benchmarks the generateSVG function under various scenarios (e.g., complex themes, high contribution counts).
Define Performance Budget: Establish a threshold (e.g., < 100ms for standard renders) so that if a code change causes a significant slowdown, the CI build alerts contributors immediately.
Reporting: Ensure benchmark results are logged during CI runs to track performance trends over time.
Describe alternatives you've considered
I have considered the following alternatives, but found them insufficient:
Manual Performance Profiling: Running Chrome DevTools performance audits manually is time-consuming and not repeatable for every PR, making it prone to human error and difficult to enforce as a standard.
Existing Unit Tests: While we have functional tests in lib/svg/generator.test.ts, they focus on output correctness rather than execution time. Attempting to hijack these for performance measurements would couple functional requirements with performance budgets, which is poor practice.
External Monitoring Tools: Integrating third-party SaaS performance monitoring would increase infrastructure complexity and cost for what is essentially a build-time requirement. An in-repo benchmarking suite with tinybench is more lightweight, free, and aligns with the project’s existing CI/CD setup.