How to make your website load faster: a practical checklist
A faster site keeps more visitors, converts more of them, and gives search engines less reason to rank a competitor above you. You do not need to be technical to know what matters. Most of the gain comes from a handful of things, and they are best done in a particular order: measure first, fix the foundations, then trim the page itself.
Step 1: measure before you change anything
Run your homepage and your most important service page through Google PageSpeed Insights, on the mobile result. Ignore the single headline score at first and read the three Core Web Vitals, because they describe what a visitor actually feels.
- Largest Contentful Paint (LCP): how long until the main content appears. Google treats 2.5 seconds or less as good.
- Interaction to Next Paint (INP): how quickly the page responds when someone taps or clicks. 200 milliseconds or less is good.
- Cumulative Layout Shift (CLS): how much the page jumps around while loading. 0.1 or less is good.
Test on mobile, on a normal connection, more than once. A single run on a fast office network tells you very little, and scores move a few points between runs even when nothing has changed.
Step 2: fix the foundations, hosting and server response
If the server is slow to start responding, nothing you do to the page can fully make up for it. That delay is called time to first byte (TTFB): how long the server takes to begin answering after a visitor asks for a page. Google considers 800 milliseconds or under good, and a slow figure here is most often caused by cheap shared hosting or a site that rebuilds every page from scratch for every visitor.
Three things move it the most, and they work together:
- A content delivery network (CDN). A CDN keeps copies of your site on servers around the world and serves each visitor from one near them, so a customer in Vancouver and one in Miami both get a quick response. Most good modern hosting includes one by default.
- Caching. Rather than rebuilding a page for every visitor, the server or CDN keeps a ready-made copy and hands that over. This is also what lets a site cope with a sudden spike in visitors without slowing down.
- Better hosting. If TTFB stays slow after the first two, the hosting itself is the limit. Moving is usually cheaper than endlessly tuning around it.
On a well-built, well-hosted site all three are handled for you. If you are on a platform where you cannot tell, that is itself a finding worth knowing.
Step 3: images, usually the biggest single win
Images are normally the heaviest part of a page, so they are normally where the largest saving is.
- Resize before you upload. A photo straight off a phone can be several times larger than any screen will ever show.
- Use a modern format such as WebP or AVIF, which are meaningfully smaller than JPEG at similar quality.
- Serve the right size for the device, so a phone is not downloading a desktop-sized image.
- Lazy-load images below the fold. Lazy loading means an image only loads as it is about to scroll into view, so the visible part of the page loads first and visitors do not download pictures they never reach.
- Do not lazy-load your main image at the top of the page. That image is usually what LCP measures, and delaying it makes the page look slower, not faster.
Step 4: trim the code
Once the foundations and images are sorted, the remaining weight is code.
- Minification. This strips the spaces, line breaks and comments out of CSS and JavaScript without changing what they do, so the files are smaller. It should be automatic in any modern build process; you should never be doing it by hand.
- Render-blocking resources. Some CSS and JavaScript must load before the browser can show anything at all, which delays that first appearance. Deferring scripts that are not needed immediately, and keeping CSS lean, cuts it down.
- Fonts. Custom fonts are a common hidden delay. Limit how many weights you load, and make sure text shows in a fallback font while the real one arrives, rather than staying invisible.
- Third-party scripts. Chat widgets, trackers, review badges and ad pixels each add a request, and often a lot of JavaScript. Audit them honestly and remove the ones nobody looks at.
Step 5: know what a page builder costs you
Some drag-and-drop builders ship a large amount of code on every page whether you use it or not. You can often improve a slow builder site with the steps above, but there is a ceiling, set by the platform rather than by anything you did.
When to rebuild instead
If a site is slow because of how it was built, and you have already done the image and script work, no amount of tweaking will fix it. A lean rebuild is then usually cheaper than another year of workarounds, and it recovers the visitors the slow site was losing. If you are weighing that up, our website redesign service covers how we handle the migration, including redirects so that what you have already earned in search carries over.
A short order of operations
- Measure on mobile and write down the three Core Web Vitals.
- Check TTFB, then CDN, caching and hosting if it is slow.
- Compress and resize images, lazy-load only the ones below the fold.
- Remove third-party scripts you do not use.
- Confirm minification and script deferral are happening automatically.
- Measure again, and compare against the first run.