Lighthouse scores nobody looks at
The app scored 42 on mobile and nobody has opened the report. Performance is filed under 'we'll fix it later,' and later never arrives.
Frontend Performance
Lighthouse 95+ on every build.
A slow page loses you people before they've read anything, and every extra 100ms of load time has a measurable cost in revenue. Speed is worked on from the first commit, using code splitting, lazy loading, a CDN, and Core Web Vitals, so it's built into your product rather than bolted on later.
- Code splitting and lazy loading built into the component architecture
- Core Web Vitals (LCP, INP, and CLS) all green on real devices
- CDN and edge caching set up before the first deployment
- A performance budget enforced in CI, so regressions never reach production
The tools we measure and tune performance with.
Why
Performance is a product decision, not an engineering afterthought.
Every extra 100ms of load time has a measurable cost in revenue, and Google ranks faster pages higher. On Indonesian mobile connections, where 4G can be patchy, people feel slow load times even more. Performance isn't gold-plating. It's the price of entry.
Core Web Vitals stuck in the red
Search Console has flagged CLS and LCP, and the SEO team has already noticed the drop in rankings. Still, nobody can say which component is causing it.
Third-party scripts hogging the main thread
Analytics, a chat widget, A/B testing, and ad pixels all load synchronously. The browser sits blocked while users wait, and nobody is willing to be the one who removes any of them.
Performance regressions that slip through
A developer adds an unoptimised image or a heavy dependency and the bundle quietly grows by 200kB. Nobody catches it until users start complaining.
The Process
How the work actually runs.
Each step has a clear deliverable and a written handoff, and we get your sign-off before moving to the next one.
01
Performance audit
A full Lighthouse and WebPageTest audit across real devices and network conditions. You get a waterfall analysis, the ten issues that hurt most, and an estimate of the effort to fix each one.
02
Bundle and asset optimisation
Tree-shaking, route-level code splitting, dynamic imports, conversion to WebP and AVIF, responsive images, and font subsetting. On most projects this step alone cuts the bundle by 40 to 60%.
03
Rendering strategy
We review the component architecture for unnecessary re-renders, move expensive work off the main thread, use virtual lists for long data sets, and defer hydration where it's safe to.
04
CDN and caching
Static assets served from the edge, correct cache headers for each type of asset, a service worker for repeat visits, and a lower TTFB through server-side and edge tuning.
05
Performance budget in CI
We set thresholds in CI. Any pull request that drops a Lighthouse score below the floor, or pushes the bundle past its limit, is blocked until it's sorted out.
The Result
What you walk away with.
Real deliverables you can point to and outcomes you can measure. Not a slide deck.
95+Lighthouse score
The baseline you can count on
A Lighthouse score of 95 or above on both mobile and desktop is the floor your build ships against, treated as a minimum, not a stretch goal.
40–60%bundle reduction
Much smaller bundles
Most audits turn up dead code, unoptimised images, and synchronous scripts. Clearing those out usually cuts the bundle roughly in half.
GreenCore Web Vitals
LCP, INP, and CLS all passing
Core Web Vitals feed straight into Google rankings. We measure them on real devices and real network conditions rather than relying on lab data.
Performance gates built into CI
Regressions get caught before they merge. The pipeline holds the budget, so your team doesn't have to remember to check.
FAQ
Common questions.
Can you improve performance on an app you didn't build?
Yes. Most of our performance work is on codebases we inherit. We audit, rank the fixes by impact, and roll them out a step at a time. No rewrite needed.
How do you measure performance for Indonesian network conditions?
We use WebPageTest with throttled mobile profiles that mimic Indonesian 4G and 3G. Lab numbers on their own aren't enough, so we always check against real-world profiles too.
How is a Lighthouse score different from real-world performance?
Lighthouse measures a controlled lab setup. Real-world performance shifts with the device, the location, and the network. We look at both. A Lighthouse score of 95 still doesn't count for much if the page takes 8 seconds on a mid-range Android in Surabaya.
What Core Web Vitals targets do you build to?
We target the 'good' thresholds Google uses: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. These are measured on real devices and real network conditions, since those are the numbers that feed into your search rankings.
What actually affects how fast a page loads?
The main drivers are bundle size, unoptimised images, render-blocking scripts, slow server response (TTFB), and excessive client-side JavaScript. We profile your build to find which of these is hurting most, then fix them in order of impact rather than guessing.
How do you measure performance, and with what tools?
We combine Lighthouse and WebPageTest for lab data with real-user monitoring (RUM) for field data from your actual visitors. Lab numbers catch regressions early, while field data tells you what people genuinely experience on their own devices and networks.
Does SSR or a CDN actually help, and do you set them up?
Both help, in different ways. Server-side rendering (SSR) gets meaningful content to the screen faster and improves LCP, while a CDN serves assets from an edge location close to the user to cut latency. We configure SSR where it fits your stack and set up the CDN with correct cache headers before launch.
How do you stop performance from regressing over time?
We enforce a performance budget in CI: any pull request that drops a Lighthouse score below the floor or pushes the bundle past its limit is blocked until it's fixed. Combined with ongoing RUM, regressions are caught before users feel them.
Do you offer ongoing performance monitoring after launch?
Yes. We can set up real-user monitoring dashboards and alerts so you see Core Web Vitals trending in production. If a third-party script or a new feature degrades performance, you'll know from the data rather than from a user complaint.
Can you improve performance without a full rewrite?
Almost always. Most gains come from bundle optimisation, image work, caching, and removing render-blocking scripts, all of which are incremental. We roll them out a step at a time on your existing codebase, and a rewrite is rarely necessary.
Contact UsEmail
[email protected]
Have a project in mind? Let's build it.
Tell us where the project stands right now. Within one working day we'll come back with a straight read on scope, timeline, and cost. There's no commitment in asking.
Office
Surabaya, Indonesia
Starting price
From USD 4,000
Typical projects: USD 4,000–25,000