Web performance engineer: what they do and why they are key in modern web applications

A web application can function correctly and still offer a slow experience. Pages load, APIs respond, and functionalities are available, but certain interactions take too long, the interface loses fluidity, or performance worsens as the product grows.

In modern applications, these situations can arise for multiple reasons: too much JavaScript running in the browser, increasingly larger bundles, heavy images, third-party scripts, rendering issues, unnecessary API calls, poor caching strategies, or infrastructure that takes too long to deliver the initial content.

Identifying which of these components is causing the degradation requires measuring before optimizing. That is precisely the territory of the Web Performance Engineer.

This role works on performance as a technical feature of the product. They analyze how an application behaves under real conditions, locate bottlenecks, and help the team implement improvements that can be measured and maintained throughout the software's evolution.

What a Web Performance Engineer does

The work of a Web Performance Engineer begins with a technical question: where is the application really losing time?

To answer this, they need to observe different layers. They can analyze the initial loading process, JavaScript execution, main thread behavior, rendering, network requests, static resources, server responses, or the performance of specific interactions.

Based on these measurements, they establish hypotheses, reproduce problems, and determine which optimizations can generate the greatest impact.

In some teams, these responsibilities are part of the work of Frontend Developers with performance experience. In larger-scale products, they can become a specialization of their own due to the volume of data, components, dependencies, and users involved.

The goal remains the same: to prevent performance from relying solely on ad-hoc optimizations made when a problem arises.

Core Web Vitals allow measuring an important part of the experience

Core Web Vitals provides a standardized set of metrics to evaluate important aspects of the web experience. Currently, the three main metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).

LCP measures the speed at which the main visible content appears. INP observes the page's responsiveness to user interactions. CLS evaluates unexpected layout shifts that can cause visual instability.

Google considers a good experience to have an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less, using the 75th percentile of visits to evaluate each metric.

These metrics provide a common basis for detecting problems, comparing results, and setting goals. However, an application can meet Core Web Vitals and still have slow internal workflows.

A fast application needs more than good Core Web Vitals

Consider a SaaS platform whose initial dashboard loads correctly. The user then opens a table with thousands of records, applies several filters, and the interface begins to respond slowly.

The initial LCP may be good. The problem lies elsewhere.

A similar situation can occur in an e-commerce site where the product page loads quickly, but changing a variant generates multiple requests, unnecessarily recalculates components, and temporarily blocks the interface.

The Web Performance Engineer needs to analyze the complete experience and not just the first load.

This includes aspects such as:

• time needed to load and render the main views;

• responsiveness during important interactions;

• JavaScript execution and main thread utilization;

• behavior on less powerful devices and connections;

• performance of navigation, search, filters, and other critical workflows;

• impact of APIs, external resources, and third-party scripts.

This perspective makes performance a discipline directly linked to the functioning of the product.

JavaScript can become one of the main bottlenecks

Current web applications can execute a considerable amount of logic directly in the browser.

Frameworks, libraries, analytics systems, consent managers, chat, advertising, personalization, and custom components can end up competing for the same resources.

The problem increases when an application incorporates dependencies progressively without controlling how much code ends up being sent to the user.

A Web Performance Engineer can analyze bundles, dependencies, and execution to determine what code is truly necessary during each stage of the experience.

Techniques like code splitting, lazy loading, and conditional loading allow reducing the amount of resources needed initially. It may also be necessary to eliminate unnecessary dependencies or replace components that introduce disproportionate costs.

Optimization must be based on measurements. Reducing a few kilobytes from a bundle may have little impact if the real bottleneck is a JavaScript task that repeatedly blocks the main thread.

Rendering, SSR, and hydration also affect performance

Modern frameworks allow combining different strategies to generate and deliver interfaces.

A page can be initially rendered on the server, generated statically, built in the browser, or combine several strategies within the same application.

SSR can improve certain experiences by delivering HTML from the server, but it also introduces new variables. The server needs to produce the response, the browser downloads the corresponding resources, and certain frameworks must subsequently perform hydration processes to convert the initial content into an interactive application.

When too much JavaScript is involved in that process, a page may appear visually loaded before it is truly ready to respond smoothly.

That’s why Software Architecture directly influences performance. Decisions about rendering, boundaries between client and server, components, and data fetching can have consequences that appear long after the framework has been chosen.

Images, fonts, and resources still have a significant impact

The sophistication of frameworks does not eliminate classic web performance issues.

An image with inappropriate dimensions or format can become one of the heaviest resources on a page. Fonts can delay the rendering of content or cause visual shifts. Videos, widgets, and external resources can significantly increase the transferred volume.

An optimization system should consider appropriate sizes according to device, efficient formats, compression, deferred loading when applicable, and strategies to avoid downloading resources that the user does not yet need.

It is also important to control elements that affect layout. Properly reserving the necessary space for images, banners, or dynamic components helps reduce unexpected movements while the page finishes loading.

The bottleneck can be outside the frontend

An application can have a properly optimized frontend and still respond slowly because it waits too long for its data.

Slow APIs, costly queries, external services, or infrastructure issues can directly affect the user-perceived experience.

The Time to First Byte (TTFB) can help observe how long it takes for the browser to receive the first byte of a response. When that time increases, investigating exclusively JavaScript or CSS will hardly resolve the issue.

Backend Developers can intervene when latency comes from APIs, server logic, data access, or integrations.

Similarly, Cloud Engineers can work on CDN, caching, geographic distribution, infrastructure capacity, and other components that influence how an application reaches the user.

Performance ends up being a shared responsibility, even if the symptom initially appears within the browser.

Lighthouse does not replace real user data

Laboratory tools are extremely useful because they allow running tests under controlled conditions and reproducing certain problems.

Lighthouse can help detect opportunities related to loading, resources, and page behavior. Chrome DevTools allows for much deeper analysis through network traces, performance profiles, and execution analysis.

But a test conducted from a controlled environment does not necessarily represent what all users experience.

Geography, connection, hardware, browser, cache state, and behavior within the product introduce significant variations. Therefore, performance analysis also needs information from real conditions.

Google differentiates between lab data and field data precisely because both approaches provide different insights. Chrome UX Report uses aggregated data from real user experiences of eligible Chrome users to provide this field perspective.

Real user monitoring allows observing the product in production

Real User Monitoring or RUM collects information about the performance experienced during real sessions.

This allows segmenting results and discovering problems that may remain hidden in internal tests. An application might work correctly on powerful machines but show considerable degradation on less capable devices.

There may also be geographic differences, by browser, or even by page.

Percentiles are especially useful here. Working solely with averages can hide a poor experience for a significant portion of users.

The Web Performance Engineer uses this data to decide where to investigate and to check later if an optimization produced a real improvement.

What problems does a Web Performance specialist investigate?

The same symptom — “the web is slow” — can come from completely different components.

The specialist's role is to relate symptoms to technical evidence.

Once the bottleneck is identified, the solution may correspond to the Frontend Engineer themselves or require joint work with Backend, Cloud, DevOps, or other profiles.

Performance budgets help control degradation

Optimizing an application once does not guarantee that it will remain fast.

A team can significantly reduce the bundle and, over the following months, incorporate new libraries, tracking tools, and functionalities until they return to the initial point.

Performance budgets allow for setting measurable limits.

They can be defined based on JavaScript weight, image size, certain metrics, or any technical indicator the team considers critical. These limits can then be integrated into the development process.

When a modification exceeds the established budget, the team receives a signal before the degradation reaches production.

DevOps Engineers can help incorporate these checks into CI/CD pipelines along with other automated tests.

When a company needs specialization in Web Performance

Not all projects need to hire a dedicated Web Performance Engineer.

A relatively small corporate website can maintain excellent performance through good development practices. In these cases, an experienced Frontend Developer can perfectly handle optimization.

Specialization begins to gain value when the complexity of the product increases and performance becomes a recurring problem.

Some relevant signals are:

• Persistently poor Core Web Vitals;

• Continuous growth of the bundle and dependencies;

• Applications with a high amount of logic on the client;

• Performance issues that only appear under real conditions;

• Significant differences between devices, browsers, or regions;

• Architecture migrations that modify rendering, hydration, or content delivery;

• Frequent degradations after new releases.

The business impact also matters. If small performance differences affect a platform with high traffic volume or critical workflows, dedicating specific capacity to performance may be justified sooner.

Frontend Developer or Web Performance Engineer: which profile do you need?

The boundary between the two profiles mainly depends on the level of specialization required.

A Senior Frontend Developer should understand rendering, network requests, resource optimization, JavaScript performance, and Core Web Vitals. These skills are part of solid frontend development.

The Web Performance Engineer delves into measurement, profiling, observability, experimentation, and cross-cutting optimization. They can work on a complete application, establish performance standards, and collaborate with different teams to avoid regressions.

In large organizations, there may also be a dedicated performance team that provides tooling, metrics, and common practices for different products.

Before incorporating this specialization, it is advisable to determine whether the problem is concentrated in specific functionalities or if performance needs to become a permanent capability of the team.

Performance should be treated as a product feature

Web applications will continue to incorporate functionalities, dependencies, integrations, and more complex experiences. Each addition can also increase the amount of work that the browser and the systems feeding it must perform.

Waiting until the application is perceived as slow turns performance into a reactive task.

Web Performance Engineering proposes another model: continuously measure, set goals, investigate degradations, and validate each optimization with data.

For some companies, these responsibilities may remain within their Frontend team. For others, the scale and complexity of the product will justify a dedicated specialist.

The important difference lies in making performance something observable and controllable. When an application can grow without the team knowing how much its execution cost is increasing, degradation ends up accumulating silently.

A good Web Performance Engineer provides precisely that visibility and helps ensure that speed no longer depends on ad-hoc optimizations but becomes a property maintained throughout the product's evolution.