Page speed isn't optional on Indian mobile networks
Most of the traffic to most of the sites we build is mobile, on a mobile network, not office WiFi. A three-second delay on a fibre connection is an inconvenience. The same delay on a patchy 4G connection outside peak signal is often the difference between a customer reading your page and a customer hitting back.
Speed isn't a nice-to-have we bolt on at the end. It's a constraint we design inside from the first page.
Static first, JavaScript only where it earns its place
Every ARTH marketing site ships as pre-rendered static HTML — the page exists fully formed before a single line of JavaScript runs. Interactive flourishes (hover effects, the cycling wordmark, scroll animations) load after the content that actually matters, and are built to degrade gracefully: if JavaScript never loads at all, the page is still complete and readable.
This is the opposite of how page builders work, where a simple business page can ship several megabytes of framework and plugin code before it renders anything a visitor can read.
Images are the real weight — so we treat them like it
On a typical business site, images are most of the download. We run every image through Next.js's built-in optimiser, which serves the right size and format for each visitor's screen and connection automatically, rather than shipping one oversized master file to every device. A hero photo that might be 4MB straight off a camera typically ships at a fraction of that, with no visible quality loss.
We caught this exact problem mid-project on Advaya CoLiving's rebuild — several source images were sitting at 8–10MB uncompressed, a serious risk given the client's own instruction that 90% of their traffic is mobile. Compressing them wasn't a footnote; it was load-bearing for the whole build actually working for its real audience.
What we measure, and what we deliberately don't add
We track Core Web Vitals — the load, interactivity and visual-stability metrics Google actually uses as a ranking signal — because they're a reasonable proxy for what a real visitor experiences. We use Vercel's Web Analytics, which is a few kilobytes and privacy-respecting, rather than a heavier suite that would undo the performance work it's supposed to be measuring.
Even something as small as this page's own visit counter is built to cost almost nothing: one tiny request, no tracking script, no cookie banner requirement. Every byte on a page should be there because it earns its place, the same standard we hold the content itself to.
Questions we hear a lot
How fast should a business website load?
As a rule of thumb, the main content should be visible in under two seconds on a typical mobile connection. Core Web Vitals gives more precise targets, but that's the number that maps to how a real visitor experiences it.
Does a fast website actually affect search ranking?
Yes — Core Web Vitals are an explicit Google ranking signal, not just a nice-to-have. Beyond ranking, speed directly affects how many visitors stay long enough to read your page at all.
Can an existing slow website be fixed without a full rebuild?
Sometimes — compressing images and removing unused scripts can help a lot. But if the site is built on a heavy page-builder or template, the framework itself is usually the bottleneck, and no amount of tuning fixes that without rebuilding on a lighter foundation.
Have something worth building?
Tell us what you're trying to make happen. We'll reply with a plan, not a brochure.
Start a project