How to Speed Up Your Website: A Practical Checklist

Website speed is not a single setting you switch on. It is the result of a few ordinary decisions: how big your images are, how much JavaScript you ship, how long browsers can cache files, and how quickly the server responds. The useful approach is to measure, fix the biggest bottleneck, and measure again.

Measure before you change anything

Start with a baseline. Run your page through Lighthouse in Chrome DevTools, or use PageSpeed Insights for both lab and field data. Lab tests are repeatable and good for spotting problems. Field data comes from real visitors and shows what they actually experience.

Test more than the homepage. A fast homepage with a slow product page is still a slow site. Test the pages people use most, on a mid-range phone and a slower connection if you can.

Write down the numbers before you edit: largest contentful paint, interaction to next paint, cumulative layout shift, total page weight and time to first byte. Without a baseline, it is easy to “optimise” something that was not the problem.

Start with images

Images are often the largest part of a page. A photo exported at 4000 pixels wide and displayed at 600 pixels wastes bandwidth on every visit. You can resize and compress an image locally with the free NelcByte image compressor before uploading it.

• Resize images to the largest size they will actually be displayed at, then compress them.
• Use WebP or AVIF where you can, with a sensible fallback for older browsers.
• Set width and height attributes so the browser reserves space and does not shift the layout.
• Use srcset and sizes when the same image is shown at different widths.
• Lazy-load images below the fold, but do not lazy-load the main hero image. That can delay the largest contentful paint.

Check the network panel after a hard refresh. If an image is over a few hundred kilobytes and it is not a full-screen photo, there is probably room to improve it.

Keep fonts under control

Every font file is a request, and custom fonts can delay text rendering. Use one family if possible, limit the weights, and prefer WOFF2. If you self-host the font, preload the file that appears above the fold and use font-display: swap so text is readable while the font loads.

Do not load five weights because the design might need them. Load the two or three you actually use. If the brand allows it, a system font stack is free and already on the device.

Ship less JavaScript

JavaScript is expensive: the browser has to download, parse, compile and execute it. A small file that runs on every page can cost more than a larger image.

• Remove libraries you no longer use. Check before deleting anything that looks unused.
• Prefer small, focused code over a large framework for a simple page.
• Use defer or module scripts for non-critical code.
• Load third-party widgets only when needed. Chat widgets, heatmaps and tag managers can add significant weight.
• Split code so a visitor does not download the checkout bundle to read a blog post.

Open the coverage panel in DevTools. It shows how much CSS and JavaScript was downloaded but never used. That is a useful place to start trimming.

Simplify CSS

Large CSS files delay rendering. Remove unused rules, avoid @import chains, and minify the final file. If you use a utility framework, configure it to include only the classes you need. If you use hand-written CSS, keep the critical above-the-fold styles small and load the rest normally.

Be careful with “critical CSS” tools that duplicate rules. Measure the result, and make sure the page does not flash with unstyled content.

Cache and compress

Static assets should be cached for a long time. Give each version a new filename or query string, then set a long Cache-Control lifetime for CSS, JavaScript, images and fonts. HTML should usually be cached for a short time or revalidated so visitors see new content.

Enable gzip or Brotli compression on the server for text assets. Most shared hosts support this. A CDN can help if your visitors are far from the server, but it will not fix a slow origin or a five-megabyte image.

Look at the server

Time to first byte measures how long the server takes to start responding. If it is consistently slow, caching and image work will only help so much.

• Check whether the hosting plan is overloaded or throttled.
• Cache database queries and expensive templates where appropriate.
• Keep PHP, plugins and dependencies updated, and remove plugins you do not use.
• Choose a server region close to your audience when you can.

Core Web Vitals, in plain terms

Metric	What it measures	Common fix
LCP	How long the largest visible element takes to appear	Optimise the hero image, font and server response
INP	How quickly the page responds to taps and clicks	Reduce long JavaScript tasks and third-party scripts
CLS	How much the layout moves unexpectedly	Reserve space for images, ads and late-loading content

Do not chase a perfect score. A useful target is a page that feels responsive on a normal phone and does not jump around while loading.

A practical order

1. Measure the pages that matter.
2. Fix oversized images and reserve their dimensions.
3. Remove unused JavaScript and defer what is left.
4. Load only the font weights you use.
5. Enable compression and sensible cache headers.
6. Check server response time.
7. Measure again and compare.

Do not break the site while making it faster

Test after each change. Check keyboard navigation, mobile layouts and the pages that depend on JavaScript. A fast page that no longer works is not an improvement. Keep a staging copy, and roll back if a change causes errors in the console or a visible layout problem.

Speed work is iterative. A few focused changes usually beat a long list of speculative tweaks.