Skip to content
MassStart an audit

Website development · est. 2026

We build sites that hold their weight.

A page is a stack of payloads, and every layer costs a visitor something. We treat that stack as a structure: measured, ordered, and cut until what remains earns its place.

Start with an auditSee what a page weighs

LCP

0.0s

good ≤ 2.5s

INP

0ms

good ≤ 200ms

CLS

0.0

good ≤ 0.1

Median page

0.00 MB

mobile, 2025

01 / Weight

Most of a page is not the page.

The median mobile home page is 2.56 MB. Desktop is 2.86 MB. Images and JavaScript are the two largest parts, and most of that mass is delivered before a visitor can act on any of it.

Weight is not a vanity metric. Among desktop inner pages under 1 MB, 79% pass Core Web Vitals. At 5 MB or more, half do. On mobile the pass rate falls with every added megabyte.

Source · HTTP Archive, Web Almanac 2025 · Page Weight

Composition of a median page

  • Images46%
  • JavaScript24%
  • Fonts9%
  • Third-party9%
  • CSS7%
  • HTML5%

Shares are the studio's own working allocation of the 2.56 MB median across resource types, used to size the 3D stack. The total and the ranking of images and JavaScript are from the Almanac chapter.

02 / Speed

Three numbers decide whether the rest mattered.

Google classifies each metric as good, needs improvement, or poor. A page passes when all three are good at the 75th percentile of real visits — not on your machine, and not on the best visit in the sample.

LCP

Largest Contentful Paint

good

0.0s

≤ threshold at p75

Time until the largest visible element has rendered. Loading.

web.dev · Core Web Vitals

INP

Interaction to Next Paint

good

0ms

≤ threshold at p75

Responsiveness across the whole session, not just the first click.

web.dev · Core Web Vitals

CLS

Cumulative Layout Shift

good

0.0

≤ threshold at p75

How much the page moves under the reader. Visual stability.

web.dev · Core Web Vitals

03 / Build

Four steps, in this order.

Design is not a phase that happens before performance. The order below is the whole method, and every step leaves a number behind.

  1. 01

    Audit

    We measure before we touch anything: field data from real users, not a lab score on your laptop. You get the numbers whether or not you hire us.

    Field LCP / INP / CLS at p75

  2. 02

    Structure

    What loads, in what order, and why. Most slow sites are not badly built — they are badly sequenced. We fix the order before the code.

    Load budget per route

  3. 03

    Build

    Server-rendered by default, hydrated only where interaction exists. Images sized to their slot. No framework you do not need.

    Route-level byte accounting

  4. 04

    Measure

    We publish the result against the same field data we started with, including when the answer is that nothing improved much.

    Before / after, same instrument

04 / Craft

The details that actually bite.

WCAG 2.2 added nine success criteria to 2.1 and removed one (4.1.1 Parsing is obsolete). These nine are the ones that break real sites, and each is cheap to get wrong quietly.

We build to them from the first commit, because retrofitting focus management and target sizes after launch costs more than doing it once.

Source · W3C, WCAG 2.2 Recommendation, 5 October 2023

  • 2.4.11AA

    Focus Not Obscured (Minimum)

  • 2.4.12AAA

    Focus Not Obscured (Enhanced)

  • 2.4.13AAA

    Focus Appearance

  • 2.5.7AA

    Dragging Movements

  • 2.5.8AA

    Target Size (Minimum)

  • 3.2.6A

    Consistent Help

  • 3.3.7A

    Redundant Entry

  • 3.3.8AA

    Accessible Authentication (Minimum)

  • 3.3.9AAA

    Accessible Authentication (Enhanced)

05 / Proof

The numbers we will and will not show you.

Performance claims are easy to make and easy to fake. Here is what we publish, and the standard we hold our own site to.

This page, measured

We run the same field-threshold test on our own site and report it. Lab scores from a fast laptop are not proof, so we do not present them as such.

Field data, p75

What we cite

Every figure on this page traces to a named source with a date: the W3C spec, web.dev, or the HTTP Archive. No borrowed headline stats unless we can point at the study.

Linked sources

What we refuse

Invented client names, unverifiable revenue percentages, and screenshot aesthetics standing in for working software. A site that loads is the only claim that survives contact.

On the record

Performance and business outcomes

The published case studies are consistent: the BBC reported losing 10% of users for each additional second, and Vodafone reported 8% more sales from a 31% LCP improvement. Those are their measurements on their sites, not a promise for yours.

Source · web.dev, Why speed matters (cites BBC, Vodafone)

What we will not tell you

That a redesign is the answer, or that a faster site is automatically a more profitable one. Speed removes a ceiling. What you put under it still has to be worth someone's attention.

06 / Contact

Send us the URL that is underperforming.

We will run the field audit and send back the three numbers plus what we would change first. No deck, no discovery call before you have the data.

jai.shevkar@gmail.comBack to the top

What we need from you

  • The URL, and the one that matters most
  • Who you consider your main competitor
  • Whether the constraint is traffic, conversion, or both
  • Any deadline that is real rather than aspirational

One reply, from a person, usually within two working days.