Website Speed Optimisation Checklist, in Order of Impact
Short Answer
Work through speed fixes in order: measure field data, fix the LCP image, remove render-blocking code, cut JavaScript, set caching and compression, then check server response time.
Most speed checklists read like a shopping list: forty items, no order and no way to tell which one matters for your site. Teams then spend a week minifying files that were never the problem. Meanwhile the oversized hero image keeps failing Largest Contentful Paint on every phone. Order matters far more than length, and most lists ignore it completely.
This checklist runs in the sequence that usually moves Core Web Vitals fastest, based on Google's web.dev guidance. Each step says what to check, what good looks like and when to move to the next. It suits WordPress, Shopify and custom-coded sites alike. Work through it one step at a time and remeasure between steps, so you know what helped.
Step one: what should you measure before fixing anything?
Measure field data before touching code, because it tells you which metric actually fails for real visitors. Open Google Search Console's Core Web Vitals report, then PageSpeed Insights on one URL from each failing group. Record mobile LCP, INP and CLS with the date.
The good thresholds from web.dev are LCP within 2.5 seconds, INP within 200 milliseconds and CLS within 0.1, at the 75th percentile. Knowing which metric fails decides the rest of this checklist. An INP problem needs script work, not image compression, so skipping measurement wastes effort.
Quick Answer
Start website speed optimisation by recording mobile Core Web Vitals field data in Search Console and PageSpeed Insights. The failing metric, LCP, INP or CLS, decides which fixes come first.
Step two: how do you fix the largest image and fonts?
Find the LCP element that Lighthouse names, which is usually a hero image or a large heading. Serve that image at the displayed size in WebP or AVIF, and never lazy-load it. Adding fetchpriority set to high tells the browser to fetch it early.
Fonts come next, because they can hide or shift text while loading. Use one or two families, self-host them where licensing allows, and set font-display so text appears immediately. Give every image and embed width and height attributes, which stops layout shift from pushing content downwards.
Quick Answer
Fix LCP by serving the hero image at display size in WebP or AVIF with high fetch priority. Limit fonts, use font-display, and set image dimensions to prevent layout shift.
Step three: which code should you cut or defer?
Remove render-blocking CSS and JavaScript from the document head, keeping only the CSS needed for the first screen inline. Load remaining scripts with defer or async. Then audit third-party tools such as chat, heatmaps and extra tracking tags, removing any nobody uses.
For INP, look for long tasks over 50 milliseconds in the Chrome DevTools Performance panel. Split heavy work into smaller tasks, delay widgets until a visitor asks for them, and avoid loading sliders on pages that do not display them. Minification helps slightly, but removal helps far more.
Quick Answer
Cut render-blocking CSS and JavaScript, defer non-critical scripts and remove unused third-party tools. For INP, break up long main-thread tasks over 50 milliseconds and load optional widgets only on demand.
Step four: are caching, compression and a CDN set up properly?
Check that the server sends text files with Brotli or gzip compression, and that static assets carry long cache lifetimes. web.dev suggests caching versioned static files such as images and scripts for six months to a year. Returning visitors then reload almost nothing.
Full-page caching matters on WordPress and similar platforms, since it saves the server rebuilding each page per visit. A content delivery network helps when visitors are spread across regions or the origin server is far away. For a single-city audience with nearby hosting, it is often optional.
Quick Answer
Enable Brotli or gzip compression, long cache lifetimes for versioned static files, and full-page caching where the platform supports it. Add a CDN when visitors are spread across several regions.
Step five: is your hosting holding the site back?
Check Time to First Byte in PageSpeed Insights after caching is working. web.dev rates TTFB of 0.8 seconds or less as good and above 1.8 seconds as poor. A slow TTFB delays every later metric, including LCP, because nothing renders before the first byte.
If TTFB stays high with caching enabled, the cause is usually overloaded shared hosting, an outdated PHP version or slow database queries. Upgrade PHP to a supported branch, review heavy plugins and consider a better plan. Moving hosts comes last, once the cheaper fixes are exhausted.
Quick Answer
Check server response last: web.dev rates Time to First Byte good at 0.8 seconds or less. If caching is on and TTFB stays slow, upgrade PHP first, then your hosting.
Main Takeaways
Measure mobile field data first, because the failing metric decides the order of work. Fix the hero image and fonts for LCP and CLS, then cut or defer JavaScript for INP. Confirm compression and long cache lifetimes, and add a CDN where visitors are spread out. Check Time to First Byte last, upgrading PHP or hosting only if caching fails.
Working through the checklist without wasted effort
Speed work goes wrong when teams fix everything at once and cannot tell what helped. This checklist avoids that by starting with measurement and ending with hosting. Each step has a clear pass condition you can check yourself. Remeasure after each one, on mobile, before moving on to the next.
If mobile scores lag far behind desktop, read our guide to realistic PageSpeed targets before chasing a perfect number. Keep a simple log of each change and its date, because field data lags by weeks. Sites built on heavy themes may need the options in our slow WordPress rebuild guide. For a hands-on audit and fixes, Auronix Web Studio's Core Web Vitals optimisation service covers each step for UAE sites.
Sources & References
FAQs
Questions readers usually ask next
These FAQs are written to match the topic of this post and to help readers move from understanding to action.
What should I fix first to speed up my website?
Fix whichever Core Web Vitals metric fails in field data, usually LCP on mobile. For most sites that means compressing and correctly sizing the hero image before touching anything else.
How long does website speed optimisation take?
A focused pass on images, scripts and caching often takes days rather than weeks for most sites. Field data then needs about 28 days to reflect improvements in PageSpeed Insights.
Can I speed up my website without a developer?
You can compress images, remove unused plugins and enable a caching plugin yourself on most platforms. Script splitting, critical CSS and server tuning usually need a developer to avoid breakage.
Does minifying CSS and JavaScript make a big difference?
Minifying usually saves only a little transfer size, so it rarely fixes a failing metric by itself. Removing unused code and deferring scripts typically delivers far larger improvements than minification.
Which image format is best for website speed?
AVIF and WebP generally produce smaller files than JPEG and PNG at similar quality. Serve them with a fallback where needed, and always resize images to their displayed dimensions first.
Do caching plugins fix a slow WordPress site?
They help by serving stored pages instead of rebuilding them, which improves server response. They cannot fix oversized images, heavy page builders or the third-party scripts that slow INP down.
What is fetchpriority and should I use it?
The fetchpriority attribute tells the browser how important a resource is compared with others. Setting it to high on the hero image can help the LCP element load noticeably sooner.
Should I preload fonts on my website?
Preload only the one or two font files needed for text on the first screen. Preloading many files competes with the hero image for bandwidth and can make LCP worse.
How often should I repeat a speed checklist?
Review Core Web Vitals every month and repeat the full checklist after redesigns, plugin additions or new tracking tags. Speed usually slips gradually as features are added without anyone noticing.
Which PHP version should my website run for speed?
Run a PHP branch that still receives support, such as 8.3, 8.4 or 8.5 in 2026. PHP 8.2 receives security fixes only until 31 December 2026, per the PHP project.
Related Resources
Need your website to load faster on mobile?
We help UAE businesses remove weight, simplify templates, and improve Core Web Vitals without breaking the site structure or search intent.
Built for search-ready UAE websites that need faster pages, clearer journeys, and stronger conversion rates.
