All services

Service 03

Angular Performance Optimization Consultant

Profile loading, interaction and layout stability with Core Web Vitals (LCP, INP and CLS), then address duplicate API calls, rendering costs and bundle size.

Discuss a project See related work
Performance optimization analytics dashboard

Performance work is measurement first and code second. Most of the frontend slowness I am asked to look at is not caused by the thing the team suspects, and the fastest way to waste a month is to start optimising before knowing which of the four common causes — bundle size, render behaviour, network waterfalls, or change detection — is actually costing the user time.

What you get

  • Core Web Vitals
  • Rendering and runtime
  • API and network optimization
  • Bundle optimization
  • Lighthouse
  • Code splitting
  • SSR
  • Image strategy

Ideal for: Products that already work, but feel heavy.

The problem this usually solves

The application works, and it feels heavy. Core Web Vitals are failing in field data while the lab score looks acceptable. A screen that was fine at launch now takes several seconds because the data behind it grew. Someone has already tried lazy loading and it did not move the number, because the number was never about the bundle.

The other version of this is operational rather than commercial. On an internal system used all day by the same people, a two-second delay repeated across hundreds of case screens is not a metric — it is hours of somebody’s working week. That is the framing I bring to it: load behaviour is a product requirement with a cost attached, not a polish item to schedule after the features.

How I work on performance

The first deliverable is a measurement, not a patch: field data where it exists, a profile of the slow interaction on hardware comparable to what users actually have, and a network trace of the screen in question. That usually separates the problem into one of four buckets — what is downloaded, what is rendered, what is requested, and what re-runs — each of which has a different fix and a different price.

On a government case management system the reported symptom was slow page loads, and the cause was none of the usual suspects: independently built panels each fetched the same shared reference data on init, so opening one record fired the same lookups five or six times. Putting those behind a shared, cached stream cut API consumption by around 40% and load time by roughly half, without touching a single component’s logic. That is the typical shape of this work — the expensive fix is rarely the invasive one.

After the fix comes the guard. A budget in CI, a check on the bundle, and the measurement written down where the next developer will see it, so the regression that would have arrived three releases later gets caught by the pipeline instead of by a user.

What working together looks like

Performance engagements are usually short and scoped: an investigation of one to two weeks that produces a written diagnosis, a prioritised list of fixes with estimated cost and expected gain, and the measurements behind both. You can hand that to your own team, or I can implement it.

I will also tell you when the answer is no. If the profile says the time is being spent in the API rather than in the browser, frontend work will not fix it, and saying so at the end of week one is worth more than a month of tuning the wrong layer.

Questions before we start

No, and be careful with anyone who does. A lab score is a proxy; what I commit to is measuring the real bottleneck, fixing what is fixable in the frontend, and showing you the before and after on field-comparable conditions. On most projects the honest gains are large — around 40% fewer API calls and roughly half the load time on the case system above — but they are the result of the diagnosis, not a number promised before it.

Core Web Vitals (LCP, INP, CLS) as the user-facing frame, plus the things that cause them: bundle composition, render and change-detection behaviour, request waterfalls, and payload sizes. Field data first where it exists, because lab conditions flatter almost every application.

No. Angular is where most of my depth is — change detection, zoneless, RxJS-level request behaviour — but bundle, network and rendering work applies equally to React and Next.js applications.

One to two weeks for a diagnosis with a prioritised plan. Implementation depends entirely on what the diagnosis finds, which is why I do not quote it in advance.

Further reading