built to measure
loading…
Fast by architecture,
not by plugins bolted on later
How fast a site is gets decided when you choose how it is built, not at the end with a caching plugin. A slow site is not a site that needs optimising: it is a site that was built wrong, and it will keep getting slower with every page you add.
lighthouse https://tensomax.it --preset=mobile
first contentful paint ... 0.7s
largest image ............ 1.2s
layout shift ............. 0.00
[ok] all three metrics green, on a phone
du -h --max-depth=0 ./assets
212K — no libraries loaded "just in case"
waiting
$ ./compare --load --mobile
Same content,
four seconds apart
On the left, a site built on the right architecture. On the right, the same site assembled from a generic theme with twenty plugins. Watch the clock: that is where customers are lost, not in the colour of the button.
theme + twenty plugins
loading…
The thresholds are the ones Google uses to judge loading (Largest Contentful Paint). The two curves are a demonstration, not a measurement of any particular site.
| Stage | Custom built | Theme + plugins |
|---|---|---|
| server response | 0,09s | 0,82s |
| first visible text | 0,24s | 1,60s |
| page content | 0,38s | 2,40s |
| main image | 1,10s | 4,90s |
| ready to click | 1,45s | 6,30s |
// when you actually need one
The signs your site
is costing you clients
A site does not need replacing because it is three years old. It needs replacing when it stops bringing in work, and the signs are always the same.
- 01 On a phone it takes more than three seconds to show anything
- 02 Every change means asking someone, and that someone does not answer today
- 03 Search Console flags slow pages and you have no idea what to touch
- 04 The site runs twenty plugins and nobody remembers what half of them do
- 05 The content lives inside a page builder you cannot take with you
- 06 Photos get uploaded by whoever has them, as they are, three megabytes each
// what we decide before writing a line
Four choices that
decide everything else
These are architectural decisions, and they are made at the start: made later they cost a rewrite, not a setting.
-
01
What ships already built
Pages that do not change on every visit are generated once and served as files. That is the difference between answering in fifty milliseconds and asking the database to rebuild the same page every single time.
-
02
What it actually weighs
Formats, dimensions and lazy loading decided during design, not added afterwards. An image served at the size it is displayed weighs ten times less than the same image scaled down by the browser.
-
03
Who updates what
The parts that change often stay editable by you; the parts that need to stay put cannot be broken by accident. A site you can break yourself is a site you will break.
-
04
What happens without JavaScript
The content is in the HTML. JavaScript adds motion, not structure: if it never arrives — slow connection, error, blocker — the page stays readable and indexable.
// how we get there
The number before
and after, always measured
Speed is not an opinion: it is measured, and it is measured on a phone over mobile data, which is where most of your visits come from.
Baseline measurement
01We measure the current site before touching it, on a phone and on a throttled connection. You need a starting number, or "it feels faster" at the end is just a feeling.
Scope and content
02How many pages are genuinely needed, which can be merged, which should go. Half of all slow sites are slow because they hold three times what they need.
Build with continuous checks
03Metrics get watched during development, not at the end. A regression caught the day it appears costs an hour; caught at launch it costs a week.
Handover with the numbers
04At handover you get the before/after comparison on the same pages and the same devices, plus the access to re-measure it yourself whenever you like.
$ cat stack.json
What we build it on
- Static generation Pages that do not change are served as files: no database in the request path
- Modern image formats AVIF and WebP at the sizes actually used, not one large image scaled down
- Edge caching The page leaves from the node nearest the visitor, not from a server in Milan
- Structured data Schema.org written by hand against the real content: it is how Google understands the pages
- Core Web Vitals The three metrics Google actually uses, kept in check throughout the build
- Cookie compliance Scripts blocked before consent, not a banner that asks and loads anyway
$ ./domande --frequenti
The questions that
always come up
What does a website cost?
The variables are how many pages are genuinely needed, how much of the content has to be rewritten, and whether you need parts you can edit yourselves. We give a number after seeing the structure, not before: a quote given over the phone is a bet dressed up as an estimate.
Can we update it ourselves?
Yes, and it is almost always the right call. The parts that change often — text, photos, posts, references — stay editable without touching code; the structural parts do not, because a site you can break yourself will eventually get broken.
WordPress or not?
It depends on who updates it and how often. WordPress makes sense when content changes constantly and the person changing it is not technical. When the pages are few and stable, a generated site is faster, safer and cheaper to maintain. We make that call together, with the reasoning written down.
Can the current site be saved?
Sometimes: if the structure holds and the problem is images, the theme or twenty plugins, we fix that and you spend a fraction. We say so after the baseline measurement, and sometimes the answer is "do not rebuild it".
How long does it take?
A well-built brochure site takes four to eight weeks, and the long part is almost never the development — it is the content. If the text and photos already exist, the timeline genuinely shortens.
What about Google rankings?
Technical SEO is included — structure, structured data, speed, indexing — because it is part of how the site is built. Ranking for specific terms is separate, continuous work, and anyone promising it in three months is selling you something else.
fymera init --project "yours"
Let us measure
the site you have now
Thirty minutes on a call with your own numbers in front of us. If fixing the images is enough, we will tell you and you save yourself a project.
