Performance as a Feature: A Founder's Case

What you need to know

• Performance has a direct relationship with conversion, retention, and user satisfaction. Treating it as background engineering work rather than a product feature means not managing one of the product's most visible user experiences.
• The performance investments with the highest return are the ones that move pages from "noticeably slow" (above 3 seconds) to "acceptable" (under 2 seconds). Optimizing already-fast pages produces diminishing returns.
• Core Web Vitals (LCP, INP, CLS) are Google's measurements of user-perceived performance. They affect search ranking and are visible to users in search results. Measuring and tracking them provides a baseline for improvement.
• Performance regressions are invisible until they accumulate. A page that adds 200 milliseconds per quarter will be unacceptably slow within two years without anyone making a deliberate decision to make it slower.
• The business case for performance investment is strongest for high-traffic, conversion-focused pages. Build the ROI case before prioritizing performance work against feature development.

The core argument

Performance is not a technical concern that product teams delegate entirely to engineers. It is a product decision: how fast should the user experience be, how much engineering investment justifies that speed, and which parts of the product are most performance-sensitive? Founders who do not engage with these questions leave performance to engineering judgment alone, which produces either over-investment (optimizing paths that do not matter to users) or under-investment (shipping slow experiences because there was always a feature to build instead).

The argument for treating performance as a feature is most compelling when framed around the user's experience of speed as a quality signal. Users do not distinguish between "the page loaded slowly because the database query was unoptimized" and "the page loaded slowly because the design is heavy." They experience the page as slow and form a quality impression accordingly. A product that is functionally superior but consistently slower than a competitor will be perceived as lower quality by users who make no distinction between product features and product speed. This perception influences referral behavior, renewal decisions, and willingness to recommend.

In my experience building and reviewing product roadmaps, performance work consistently loses prioritization battles to feature development because performance improvements do not appear in feature release notes and do not generate the same enthusiasm in product demos as new features. The teams that maintain performance discipline treat performance as a feature with its own metrics (Core Web Vitals, time-to-interactive, API response time percentiles), its own roadmap items, and its own success criteria. Performance regressions are tracked the same way that feature regressions are tracked, and performance improvements are communicated to users the same way that feature improvements are.

Common mistakes

1. Not establishing performance baselines before beginning optimization work. Performance optimization without a baseline cannot demonstrate improvement. Measure current Core Web Vitals, time-to-interactive for key pages, and API p95 response times before starting work. The baseline is the proof that the optimization produced results.

1. Optimizing the wrong pages. Not all pages have equal performance impact. The landing page, the signup flow, the product dashboard, and the most-used feature pages have the highest impact on conversion and retention. Optimizing a rarely-visited settings page with a small user base produces minimal business impact regardless of how fast it becomes.

1. Not including performance in the definition of done for new features. Features that ship without performance measurement create performance debt. Adding a performance requirement to the definition of done (the new feature must not increase LCP by more than X milliseconds on the affected pages) prevents performance degradation from accumulating unnoticed.

1. Treating performance optimization as a project with a completion date. Performance degrades continuously as the product grows: more data, more features, more third-party scripts, more users. Performance maintenance is ongoing, not a one-time project. Allocating a percentage of engineering capacity to performance work every sprint prevents the "the product is slow now, let us do a performance sprint" cycle.

1. Ignoring mobile performance in favor of desktop optimization. In most B2C contexts and many B2B contexts, a significant portion of initial visits are from mobile devices. A product that has excellent desktop performance and poor mobile performance has optimized for the secondary experience of many of its users. Measure and optimize mobile performance separately from desktop.

Where to start

1. Run a Lighthouse audit on the three most traffic-heavy pages. Lighthouse produces Core Web Vitals scores, a list of specific improvement opportunities with estimated time savings, and diagnostics for the most common performance issues. The first audit is a prioritized to-do list.

1. Set performance budgets for key pages. Define the acceptable LCP, CLS, and INP for each high-traffic page. These budgets become alerts in CI that prevent new deploys from worsening performance beyond the acceptable threshold.

1. Calculate the conversion impact of the largest performance gap. Identify the page with the worst performance and the highest traffic. Use the Lighthouse score and published elasticity estimates to build a rough ROI model for bringing that page to a "good" score. This model is the business case for prioritizing the performance work.

Related reading

• Core Web Vitals in 2026: What Still Matters
• Largest Contentful Paint: The Metric That Changes Conversions
• INP: The New Core Web Vital Most Teams Are Failing
• Memory Leaks in Long-Lived Web Apps