Web performance · Assessment
Does your slow site really need a rewrite?
If a slow website’s only proposed fix is a rewrite, we measure its speed and list the fixes that work without one. On one marketplace, the twenty slowest queries got 90% faster before any rewrite.
FormatWritten assessment
TimelineDate agreed up front
PricingFixed-price assessment · hourly work
Proof2 case studies
The assessment in 4 parts
01 · Signs you need it
If two of these apply, this is a good fit.
- Lighthouse performance sits around 60, and no one can say what is holding it down
- The only proposal on the table is to rewrite everything
- Images and mail are handled by the same server that renders the pages
- A few pages are slow because of database queries that have never been looked at
- Your customers find you through search, and the site is the product
02 · What you get
The document sets out:
- What makes the pages slow, split by cause: the server, the database, the assets or the frontend. Each one is found and fixed in a different way.
- The slowest queries, one by one, with what an index or another change would gain.
- Everything that can be fixed without a rewrite, ordered by what it gains against what it costs.
- What a rewrite would give you that these fixes would not, which is usually less than it seems.
03 · How we decide
STEP 01We measure before changing anything.Lighthouse and the slowest queries come first, so every change has a before and an after.
STEP 02Stabilizing comes before any rewrite.On the marketplace, the first two months went to fixing the crashes, the security holes and the slowest queries. The two-year rebuild came after that, and Lighthouse went from 60 to 90+ once the public site moved to Next.js.
STEP 03We start with the database.Indexing the twenty slowest queries gave a 90% improvement, with no change to the product.
STEP 04Then other work moves off the page server.Images go to object storage and mail goes into a queue, so the server that renders pages does nothing else.
04 · If we find nothing
Then the document says your site is fast for its current load and shows the point where growth would slow it down. Any case for a rewrite would have to rest on something other than speed.
Proof
Where we’ve done this before
Case study 04 · MarketplaceZero outagesA US marketplace on shared hosting that could not scale. In the first two months, without rewriting its PHP, we made its twenty slowest queries 90% faster. Lighthouse performance went from 60 to above 90, and SEO from 30 to above 90, after its public site moved to Next.js.Read the case study →Case study 13 · Data15 min → 0.2 sA sales report in a BI tool went from over fifteen minutes to 0.2 seconds, without changing a single query or column.Read the case study →WritingUpload to S3 with a signed URL instead of through your backendSending uploads straight to storage instead of through the backend allowed smaller instances and made uploads faster. It was one of three changes that took a monthly bill from $24,000 to $2,000.Read the post →
FAQ
Questions about this service
We set the date after seeing how much there is to read, and it is written into the offer before we start.
Not always. On the marketplace in our case study, the twenty slowest queries got 90% faster on the code it already had. Lighthouse went from 60 to above 90 later, with the move to Next.js. We measure first, then tell you which fixes need a rewrite and which don’t.
Yes, as separate work. Once the document shows what is needed, we make the fixes and bill them by the hour.
Access to the repository, and read access to hosting and monitoring. We don’t need production data.
Next step
Describe the problem and we’ll come back with three options.
The first call takes 30 minutes, and you’re under no obligation.