Measure before you change anything. Run the page through Google's PageSpeed Insights and look at two things: how long your server takes to start answering, and what the page loads after that. Google's guidance is that a page's main content should appear within 2.5 seconds. A slow server usually means slow database queries or an undersized host. A slow page usually means oversized images, too much JavaScript, or too many third-party scripts.
What's the problem
Pages take seconds to appear, visitors leave before they load, and it's worse on phones. You may have been told to "get a better server", or that the whole site needs rebuilding.
Why it happens
- The server is slow to answer. Time to first byte is high: database queries scanning whole tables, work that could be cached being redone on every visit, redirects, or a server too small for the traffic.
- The page is heavy. Large uncompressed images, big JavaScript bundles, web fonts, and analytics or chat widgets all loaded up front.
- Nothing is cached. Pages that could be stored and reused are rebuilt for every visitor.
- Visitors are far away. A server in another country with no content delivery network in front of it.
How to fix it
- Measure with PageSpeed Insights on your key pages, on mobile. Note the server response time and the largest items it flags.
- If the server is slow, find the slowest requests in your logs or monitoring. Usually it's a few database queries. See my database is slowing everything down.
- Cache whole pages or expensive results where the content doesn't change per visitor.
- Shrink images: resize them to the size they're shown at, use modern formats, and lazy-load those below the fold.
- Cut JavaScript: remove unused libraries and widgets, and load the rest without blocking the page.
- Put a CDN in front so static files come from near your visitors.
- Only then consider a bigger server, if measurements show it's working at full capacity.
When to call Preventionlabs
If PageSpeed points at images and a couple of scripts, you can fix those yourself. Call us when the slowness is part of a bigger problem: an app that's falling over, out of date, or can't take more users. One of the three things every resurrection delivers is infrastructure that scales, meaning capacity can be increased through configuration, without changes to the code. That's about handling more users, not a page-speed tune-up. If speed is your main concern, say so when you submit, and the free assessment will tell you what's causing it.
Submit your project for a free assessmentFree assessment. $10,000 AUD flat to get it live, only if we take it on and you go ahead.
Sources
- web.dev (Google): Web Vitalsweb platform guidance
To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.
- web.dev (Google): Optimize Largest Contentful Paintweb platform guidance
A high TTFB can be due to multiple server redirects, visitors located far away from the nearest site server, visitors on poor network conditions, or an inability to use cached content due to query parameters.
- PostgreSQL: Indexesdatabase docs
An index allows the database server to find and retrieve specific rows much faster than it could do without an index.