There is a common sequence in how websites get built: design first, then develop, then optimise for performance once everything else is done. Speed is treated as an engineering task — something to be fixed at the end, like compressing images after the site is already live.
We do not work that way. At Paeveul, speed is a design constraint from the first decision. Not an afterthought. Not a finishing step. A first-class requirement that shapes every other choice.
This article explains why we hold that position — and why we think it matters for your business, not just for our build process.
Slow Sites Are a Trust Problem Before They Are a Technical One
When a visitor lands on your website and waits five seconds for it to load, they do not think "there must be a server issue." They think — at a level they may not consciously articulate — "this business is not professional."
That is not a stretch. We make these assessments constantly and automatically. A cracked paint job on a shopfront reads as neglect. A slow website reads the same way. It signals that the business either does not know its site is slow, or does not care enough to fix it.
For a Malaysian SME trying to earn the trust of a prospective client who has never heard of you, the first few seconds of your website are a character reference. A fast, clean page that loads immediately says: we are organised, we pay attention, we deliver. A slow, clunky page that loads in fragments over six seconds says something else entirely.
This is a design problem, not an engineering one. It cannot be bolted on afterward.
Speed Shapes Every Design Choice
When performance is treated as a design constraint from the start, it changes specific decisions in specific ways.
Images. Photography is the most common cause of slow websites. A hero image at full resolution from a modern camera is 4 to 8 MB. An 8-photo gallery is 40 to 60 MB. That is not a fast website waiting to be compressed at the end — it is a slow website from the moment the design brief includes a photo gallery.
Our decision at the design stage: every image in a Paeveul site is converted to WebP before it goes near the codebase. WebP images are 60 to 80% smaller than JPEG equivalents at equivalent visual quality. We use Squoosh — a free, browser-based tool — and convert at the point of receiving client assets, not as a last step before launch.
Fonts. Custom web fonts are attractive and they have a genuine cost: each font file is an additional network request, and loading fonts poorly causes text to flicker or render late. Our default is system fonts for body text. If a custom font is used for headings, we load only the weights we actually use and preload the critical file.
Frameworks and libraries. JavaScript frameworks make some development tasks faster. They also add hundreds of kilobytes to the amount of code a visitor's browser must download before seeing anything on the page. For a single landing page, the overhead of a full framework is rarely justified.
We write in vanilla HTML, CSS, and minimal vanilla JavaScript. There is no build step, no bundling process, and no 200 KB JavaScript payload. The trade-off is a slightly more constrained development environment. The result is a site that loads in under 2 seconds on a mid-range Android phone on Malaysian LTE.
Hosting architecture. A site hosted on a single shared server somewhere in Singapore delivers content at the speed of that server's connection to the visitor's device. A site hosted on Vercel's global CDN delivers content from the edge node geographically closest to the visitor — typically 40 to 60% faster for Malaysian visitors compared to regional shared hosting.
Hosting is not a launch detail. It is a design constraint we decide before a single line of code is written.
The 85 to 95 Standard
Every site Paeveul builds is expected to score 85 to 95 on Google PageSpeed Insights mobile before it goes to the client for review. Not after launch. Before.
That standard forces us to make performance decisions continuously throughout the build, not once at the end. When a new image comes in from a client that is 6 MB, it gets converted before it goes into the site, not after we notice the score dropped. When we add a new section with embedded content, we check the impact on load time before the commit.
The average score for Malaysian SME websites — based on spot checks we have run across comparable businesses — sits in the 30 to 60 range on mobile. A score of 85 to 95 is not exceptional by global standards. For a Malaysian small business website, it is substantially above the norm.
Why This Is Our Design Manifesto, Not Just a Technical Checklist
We are a small studio. Every site we build reflects what we believe a professional website should be. Speed is part of that belief — not because Google rewards it (though it does), and not only because it reduces bounce rates (though it does). Because a slow website is a failure to respect the visitor's time.
Malaysian mobile users — browsing on 4G during a lunch break, checking a supplier's website from a construction site, vetting a contractor from a phone with 15% battery — do not have the patience or the bandwidth for a slow site. Designing for speed is designing for the actual conditions under which real clients encounter your business.
Every design decision that makes a site heavier — larger images, richer animations, more dependencies, heavier fonts — must justify its weight. If it does not make the site meaningfully more useful or credible for the visitor, it does not belong in the build.
That is the principle we apply from brief to launch. Speed first. Everything else earns its place.
