Skip to content
fullstack.sg
Menu

Speed and responsiveness

Finding out why it’s slow, then fixing the cause

Who it’s for
Product and marketing teams, Agencies, Application teams
To start, send
The URLs that matter most
Pricing
Quoted for each project

We measure what’s making your pages slow, fix the causes that matter most, and help stop them coming back.

Discuss a projectHow pricing worksOne-pager for your proposal
  1. Interface (not central to this service)
  2. Logic (not central to this service)
  3. Data (not central to this service)
  4. Integrations (not central to this service)
  5. Deployment (used by this service)

Is this for you?

“The site is slow” can mean a dozen different things. It might be a huge image at the top of the page, scripts that hold everything up, a slow database query, a tag manager full of tracking code, or a server on the other side of the world. Each has a different fix, and fixing the wrong one wastes time and money.

So we measure first, using data from your real visitors where it exists and repeatable lab tests where it doesn’t. Then we fix the problems that affect people most, and set up checks so they don’t creep back.

Who it’s for

  • Product and marketing teams

    Your pages feel slow on phones, or Search Console says important pages fail Core Web Vitals.

  • Agencies

    A client is unhappy with the speed of a site you built or took over, and you need a clear answer.

  • Application teams

    Particular screens or actions are slow, and you’re not sure whether the problem is in the browser, the server or in between.

Usually, one of these has just happened

  • Search Console reports poor Core Web Vitals for important pages.
  • Lighthouse scores are low, and it isn’t clear which of its suggestions matter.
  • A dashboard or search takes several seconds to respond.
  • Pages jump around while loading, so people tap the wrong thing.

What we measure

Google’s Core Web Vitals give everyone the same words for how fast a page feels. The targets below are Google’s published thresholds for “good”, measured across real visits.

LCP

Largest Contentful Paint

How long until the main content is visible.

Good: ≤ 2.5 s

INP

Interaction to Next Paint

How quickly the page responds when someone taps, clicks or types.

Good: ≤ 200 ms

CLS

Cumulative Layout Shift

How much the layout jumps while the page loads.

Good: ≤ 0.1

Why a page is slow: a loading waterfallIllustrative, not a client page
  • HTML document, 0.0 to 0.6 secondsFix: The server took 600 ms to respond. Cache the page on a CDN.
  • Render-blocking CSS, 0.6 to 1.2 secondsFix: Put the essential CSS in the page and load the rest without holding it up.
  • Web fonts (4 files), 0.7 to 1.9 secondsFix: One variable font, preloaded, with a matched fallback.
  • Hero image (2.4 MB), 1.2 to 3.6 secondsFix: Responsive AVIF/WebP at the right size, fetched with high priority.
  • Tag manager + 6 tags, 1.3 to 4.1 secondsFix: Load tags after the page is usable, and remove two nobody uses.
  • Largest Contentful Paint at 3.7 seconds

What we can’t promise

  • A particular Lighthouse score, because lab results vary from run to run.
  • Changes in search rankings.
  • Better real visitor data by a set date, because it’s averaged over 28 days.
  • Speed that a third-party script or your platform won’t allow.

What you get

  1. A diagnosis

    What’s slow, for whom and why, based on real visitor data where it exists and lab tests where it doesn’t, with the causes ranked by how much they matter.

  2. Targeted fixes

    Changes to images, fonts, scripts, caching, database queries or hosting, each measured before and after.

  3. A review of tracking and third-party scripts

    How much each one slows the page down, so you can decide which are worth keeping.

  4. A performance budget

    Agreed limits on things like JavaScript size, image weight and loading times, with automated checks that warn when a change breaks them.

Before we start

What we’ll need from you

The URLs that matter most
Usually the pages that bring traffic or revenue, not just the homepage.
Search Console or analytics access
Real visitor data shows what people actually experience.
Access to the code and a test server
So changes can be tried before they go live.
A list of tracking and third-party scripts
And who asked for each, because removing one is a business decision.

Decisions we’ll help you make

Lab scores or real visitor data?

Google’s Core Web Vitals are based on real visitors, and that’s what reflects your users’ experience. Lab tools like Lighthouse are useful for finding causes and comparing changes, but a lab score isn’t the goal.

Quick wins or structural change?

Images, fonts and how scripts load often give quick improvements. Other problems, such as too much work happening in the browser or a slow backend, need bigger changes. The diagnosis tells you which kind you have.

What about third-party scripts?

They’re often the biggest cost and the hardest to change, because each one belongs to someone in the business. We’ll measure them and explain the trade-off. What to remove is your call.

How the work runs

  1. 1

    Measure

    Real visitor data plus repeatable lab tests on your key pages and devices.

  2. 2

    Find the causes

    We trace the slowest experiences back to what’s causing them.

  3. 3

    Prioritise

    We agree which fixes to make, weighing impact against effort.

  4. 4

    Fix and re-measure

    Each change is measured against where we started.

  5. 5

    Guard against slip

    Limits and automated checks so the gains don’t quietly disappear.

  6. 6

    Check real data

    Real visitor data takes weeks to catch up, so we look again once it has.

Usually included

  • Finding the causes of slow loading, slow interaction and jumpy layouts
  • Fixing images, fonts, scripts and page rendering
  • Speeding up the backend and database queries
  • Caching and CDN setup
  • Performance limits and monitoring

Not included unless agreed

  • Guaranteed scores or search rankings
  • Changing other companies’ scripts
  • Redesigning pages, unless agreed as part of the fix

Third-party scripts, hosted platforms and embedded widgets often limit how fast a page can get. Some online-store and website-builder platforms barely let you change anything.

The full process, from first message to handover, is on How we work.

How the costis worked out

We usually price the diagnosis and the fixes separately. The diagnosis has a fixed price, and the fixes are estimated from what it finds, so you’re not paying for guesswork.

After a first call, we send a written quote that says what’s included and what isn’t.

What affects the cost

  1. How many page types or user journeys need looking at
  2. Whether real visitor data is available
  3. Whether the causes are in the browser, the server or both
  4. What your platform allows us to change
  5. How many third-party scripts there are
  6. Whether you want ongoing monitoring

Questions

Can you guarantee a Lighthouse score of 100?

No, and we’d be wary of anyone who does. Lab scores vary from run to run, and chasing a perfect score can mean removing things the business needs. We’ll agree measurable targets based on your real visitor data instead.

Will this improve our search rankings?

Core Web Vitals are one of many things Google takes into account. A faster site is better for your visitors either way, but nobody can promise a ranking change.

How long until we see results?

Lab results show straight away. Search Console’s real visitor data covers the previous 28 days, so it takes a few weeks to fully catch up.

Can you speed up a Shopify, WordPress or Webflow site?

Often, at least partly. Themes, images, apps and scripts can usually be improved, but these platforms limit what can be changed, and we’ll be clear about where that limit is.

Pages or screens slower than they should be?Discuss a project →Send us the pages that matter and any reports you have. We’ll tell you what we’d measure first.