Page Speed Optimization Checklist: Find and Fix Your Biggest Slowdowns

A slow page is rarely cursed. It is usually carrying an oversized hero image, too much JavaScript, a stack of third-party tools, or a server that takes its time answering the door.

Page speed optimization means reducing the time and browser work required to show useful content and respond to visitors. The goal is not a perfect score for bragging rights. It is a page that loads and works well for real people, including those on mobile networks and less powerful devices.

Use a simple loop: measure one meaningful page, find its biggest bottleneck, make one focused change, retest, and repeat. Test changes on a staging site when possible, and create a backup before changing themes, plugins, scripts, or server settings.

Main Highlights

Fix the bottleneck with the largest user impact first. That is often the resource delaying the Largest Contentful Paint, excessive JavaScript work, an oversized image, or a slow server response.

One verified improvement is more useful than 20 unchecked tips copied from a forum at 2 a.m.

Why Slow Pages Are Harder Than They Look

Speed tools report symptoms, while your job is to find the cause. A poor Largest Contentful Paint score might result from a huge image, delayed CSS, slow server response, or JavaScript that keeps the browser too busy to render.

Use both types of data:

• Lab data comes from a controlled test, such as Lighthouse. It is useful for debugging and comparing changes immediately.

• Field data comes from real visitors. It shows what users actually experience, but it takes longer to reflect recent changes.

Google’s Core Web Vitals use these “good” thresholds for the 75th percentile of page visits: Largest Contentful Paint at or below 2.5 seconds, Interaction to Next Paint at or below 200 milliseconds, and Cumulative Layout Shift at or below 0.1.

Signal	What it represents	Good threshold, where applicable	Common causes	First place to investigate
Largest Contentful Paint, LCP	When the largest visible content element appears	≤ 2.5 seconds	Large hero image, slow HTML, render-blocking CSS	Identify the LCP element
Interaction to Next Paint, INP	How quickly the page responds to an interaction	≤ 200 ms	Heavy JavaScript, long tasks, complex event handlers	JavaScript execution and event handlers
Cumulative Layout Shift, CLS	Unexpected movement of visible content	≤ 0.1	Images without dimensions, ads, font swaps, banners	Elements that shift in the viewport
First Contentful Paint, FCP	When the first text or image appears	Diagnostic metric	Slow CSS, server response, blocking scripts	Initial HTML and CSS
Time to First Byte, TTFB	How quickly the server begins responding	Diagnostic metric	Hosting, database work, redirects, uncached pages	Network waterfall and server logs
Page weight and request count	How much data and how many files a page loads	No universal target	Large media, plugins, third-party tools	Network panel and audit report

A loading waterfall helps make this less mysterious:

HTML request ────────┐
                     ├─ CSS ──────────────┐
                     ├─ JavaScript ──────────────┐
                     ├─ Fonts ────────┐           │
                     └─ Hero image ───────────────┤ → Largest visible element renders
                                                   └→ Page becomes usable

If the hero image starts downloading late, or JavaScript occupies the main thread first, the page can feel slow even when the server is technically working.

What to Gather Before You Optimize

Choose one or two important pages that represent real visitor journeys: a homepage, product page, high-traffic article, category page, or landing page. Do not begin with a contact page that receives three visits a month, two of which are probably bots.

Gather:

• Access to your CMS, code repository, or website settings

• A staging site or a tested backup

• A clean browser session or incognito window

• Access to analytics or Google Search Console, if available

• A simple change log or spreadsheet

• A representative mobile and desktop device profile

For each tested page, record the URL, date, page template, baseline metrics, largest visible element, transferred bytes, and number of requests.

Run the URL through PageSpeed Insights. It provides Lighthouse lab data and, when enough real-user data exists, field data from the Chrome User Experience Report. You can also use web.dev Measure to run and track audits.

Quick Prioritization Checklist

Audit finding	Likely first fix	Tradeoff or caution	How to verify
LCP image is large or requested late	Resize, compress, and prioritize the image	Do not reduce quality until it looks blurry	Confirm LCP improves and image remains sharp
Render-blocking CSS or scripts	Remove unused assets; defer noncritical scripts	Test menus, forms, checkout, and consent tools	Compare render timing and functionality
Excessive JavaScript	Remove plugins, widgets, or duplicate tags	Some tools may be business-critical	Check JavaScript execution time
Slow TTFB	Investigate hosting, caching, redirects, or backend work	Front-end changes may not solve it	Check initial HTML response timing
Layout shifts	Reserve space for images, ads, and embeds	Fixed space must fit responsive layouts	Test page loading and scrolling
Large repeat-visit downloads	Improve cache headers and asset versioning	Incorrect caching can serve stale files	Test first and repeat visits

Step 1: Run a Baseline Test and Save the Evidence

Test the same URL in PageSpeed Insights on mobile and desktop. Save screenshots or export the report before changing anything. Note whether field data is available, because that affects how much weight you should give the results.

Then inspect the page in Chrome DevTools. Chrome’s Performance panel documentation explains how to record loading activity, while the Network panel shows requests, file sizes, cache status, and timing.

For example, your mobile audit may show:

• LCP: 4.1 seconds

• LCP element: homepage hero image

• Hero image transfer size: 2.8 MB

That gives you a specific target. “Make the site go zoom” is not yet a troubleshooting plan.

Do not compare unrelated pages, different device settings, or tests taken under wildly different conditions as if they were identical experiments.

Step 2: Find the Biggest Bottleneck Before Changing Anything

Review these items in your audit:

1. The LCP element and when it starts loading

2. Render-blocking CSS and JavaScript

3. Long JavaScript tasks

4. Unused CSS and JavaScript

5. Image transfer sizes

6. Font loading

7. TTFB and redirect chains

8. Third-party requests

A Lighthouse score is a weighted summary, not a business-priority list. Chrome documents how Lighthouse performance scoring works, but a score alone cannot tell you which change will matter most to visitors.

If the LCP element is a 2.8 MB hero image, optimize that image before spending an afternoon replacing a tiny footer icon library. Choose one primary issue and one secondary issue. Leave the rest of the list alone until you retest.

Step 3: Make the Largest Visible Content Load Faster

The LCP element is often an image, heading block, or video poster in the first screen of content. Google’s LCP optimization guidance recommends identifying that resource and making sure it can load promptly.

For an LCP image:

• Serve dimensions close to its displayed size.

• Use responsive image variants for different screen sizes.

• Compress the file with visual review.

• Use modern formats when your CMS and browser support allow it.

• Avoid lazy-loading it.

A 3,000-pixel-wide banner displayed at 1,200 pixels wastes bytes. Replace it with appropriately sized responsive versions, then verify that the browser still requests the image early.

<img
  src="hero-1200.webp"
  srcset="hero-800.webp 800w, hero-1200.webp 1200w, hero-1600.webp 1600w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width="1200"
  height="675"
  alt="Description of the image">

This example illustrates the principle. Most CMS platforms can generate responsive images without requiring hand-written HTML.

Step 4: Reduce Image Weight Without Making the Site Look Faxed

Images are frequently the largest files on beginner websites because source files are uploaded directly from cameras, stock libraries, or design tools.

Use this image checklist:

• Resize images before upload when your CMS does not create suitable versions.

• Select formats suited to the image and your workflow.

• Compress images, then inspect them at realistic screen sizes.

• Provide responsive variants.

• Remove decorative images that do not support the page’s purpose.

• Lazy-load images that begin below the fold.

MDN’s lazy loading guide explains how delayed loading can reduce initial work. Use it for content that visitors do not need immediately.

Initial viewport:
[Logo] [Navigation]
[Primary heading]
[Main product or hero image]  ← Load immediately
[Introductory content]

Below the fold:
[Gallery images]              ← Can lazy-load
[Map embed]                   ← Can wait or click-to-load
[Related content images]      ← Can lazy-load

For example, lazy-load product-gallery images below the first screen, but keep the main product image available immediately if it is the LCP candidate.

Step 5: Remove or Delay Render-Blocking Resources

CSS tells the browser how to display the page. JavaScript can add useful behavior, but it can also make the browser pause, parse, execute, and sigh dramatically before rendering.

Start by removing assets that are not earning their keep:

• Unused plugins

• Duplicate analytics tags

• Social widgets

• Auto-loading chat tools

• Page-builder features not used on the page

• Old tracking scripts from campaigns that ended months ago

web.dev’s JavaScript payload guidance explains why shipping less JavaScript is often more effective than trying to optimize every byte of a large bundle.

Noncritical scripts may be deferred or loaded after interaction, but do not defer everything indiscriminately. A script may control navigation, checkout, cookie consent, forms, or accessibility behavior.

A safe test: disable a chat widget on staging, rerun the audit, and test the page manually. Compare JavaScript execution time with the value the widget provides. If removing it saves 600 KB and visitors rarely use it, the decision becomes clearer.

Step 6: Improve Caching and Compression

Browser caching lets repeat visitors reuse files they already downloaded, such as logos, stylesheets, and JavaScript. Versioned static files are important because they tell browsers when a file has actually changed.

MDN’s HTTP caching guide explains the headers and behavior involved. Coordinate cache changes with your host, CDN, CMS, or developer.

Also check whether your host or CDN supports text compression such as Brotli or gzip. Compression can reduce the transfer size of HTML, CSS, JavaScript, and other text-based files. It is a configuration item, not a magic button to press repeatedly until the internet applauds.

After changing cache behavior:

1. Test a fresh visit in an incognito window.

2. Test a repeat visit.

3. Purge relevant caches if required.

4. Confirm updated files receive a new versioned URL.

5. Check that logged-out visitors do not receive stale HTML or broken assets.

Step 7: Investigate Server Response and Third Parties

If the initial HTML document waits a long time before loading, image compression may not be your main problem. A slow TTFB can point to backend processing, database queries, redirects, inadequate hosting capacity, or ineffective page caching.

Use the Network waterfall to look for:

• Slow initial HTML responses

• Redirect chains

• Slow API calls

• Video embeds

• Fonts

• Maps

• Ads

• Analytics platforms

• Social media widgets

• Chat tools

The HTTP Archive Web Almanac provides broader web-performance context, but aggregate trends cannot diagnose your specific site. Your waterfall is the more useful witness.

For example, replace an automatically loaded map with a click-to-load placeholder. Then compare request count, transferred bytes, and page behavior. Keep a third-party tool when its business value outweighs its measurable speed cost, privacy implications, and maintenance burden.

Step 8: Prevent Layout Shifts and Slow Interactions

A page can load quickly and still frustrate visitors if buttons jump away just as someone tries to tap them.

Common CLS causes include:

• Images without width and height attributes

• Ad slots without reserved space

• Late-loading newsletter forms

• Cookie banners and promotional bars

• Font changes that alter text size

• Dynamic embeds

Google’s CLS optimization guidance recommends reserving space for elements that load later. Set image dimensions or aspect ratios, and test banners, personalization tools, and embeds at different screen widths.

For example, reserve a defined area for a newsletter form that appears after load. Without that space, the form may push article text downward after a visitor has started reading.

Slow interactions are often JavaScript problems. Long tasks and heavy event handlers can harm responsiveness. Google’s INP optimization guidance is useful when clicks, taps, or typing feel delayed.

Step 9: Retest and Keep a Change Log

After each meaningful change, rerun the same mobile and desktop tests using the same URL and comparable conditions.

Record:

• What changed

• Why you changed it

• LCP element and timing

• TTFB

• Request count

• Transferred bytes

• Lighthouse findings

• Whether menus, forms, analytics, and checkout still work

Field data updates more slowly than lab tests. Use controlled retesting to validate an immediate change, then monitor real-user trends over time.

Troubleshooting When the Checklist Does Not Produce a Miracle

Symptom	Likely cause	Safe next check	When to ask for help
Scores vary widely between tests	Network variation, caching, third-party content	Repeat comparable tests and inspect the waterfall	Ask a developer if changes are unexplained or persistent
Score gets worse after lazy loading	An above-the-fold image was deferred	Check whether the LCP image has loading="lazy"	Ask a developer if your CMS applies lazy loading globally
Menu, form, checkout, or analytics breaks	A required script was deferred or removed	Restore the change and test scripts individually	Ask a developer before altering critical functionality
Visitors see old pages after cache changes	Wrong cache layer was purged or assets are not versioned	Test logged-out users and inspect asset URLs	Ask your host or CDN provider for cache guidance
Front-end fixes barely help	Slow server, redirects, database work, or APIs	Check TTFB and initial document timing	Contact your host or development team
Layout still shifts	Banners, embeds, fonts, or ads load late	Record the page while loading and identify movement	Ask a developer if the shifting element is generated dynamically

Tips for Keeping the Site Fast

Measure before adding a plugin. A feature request is also a performance request.

Optimize images before upload. A media library is not a storage unit for camera-original files wearing tiny hats.

Test new third-party tags on a representative page before adding them sitewide.

Set a performance budget, such as a maximum JavaScript size or target page weight, for important templates.

Test mobile conditions, not only a developer laptop connected to heroic office Wi-Fi.

Document approved exceptions, such as a required video or business-critical tool, along with its measured cost and any mitigation.

Make performance part of publishing and release workflows. Check important templates after theme updates, ecommerce app installations, popups, campaign changes, and tracking updates. Assign someone responsibility for deciding whether a new script or feature is worth its ongoing cost.

Final Thoughts

Measure a meaningful page, identify its largest slowdown, make a focused change, verify the result, and repeat. The best next fix comes from evidence on your own site, not from whichever generic recommendation sounds most exciting.

The goal is not to win a trophy from a test tool. It is to stop making visitors watch the loading spinner perform its entire one-person show.

FAQ Section

What is a good page speed score?

A high score is useful, but it is not the final goal. Prioritize user-focused metrics such as LCP, INP, and CLS, along with real-user performance and reliable page functionality. A slightly lower score on a useful, stable page can be better than a perfect-looking audit for a broken experience.

How often should I check page speed?

Check after major releases, theme or plugin changes, new marketing tools, tracking changes, and ecommerce updates. Monitor key templates regularly so small additions do not become a large performance problem.

Can a plugin or one-click tool fix page speed?

It can help with specific tasks, such as caching, compression, image optimization, or minification. It cannot solve every problem, especially slow server responses, unnecessary third-party tools, or oversized source files. Test every optimization tool for duplicate processing and broken functionality.

Should every image be lazy-loaded?

No. Do not lazy-load images needed in the initial viewport, especially the LCP image. Lazy-load images that start below the fold and are not needed immediately.

Why is mobile slower than desktop?

Mobile audits commonly use more constrained network and CPU conditions. Real visitors may also have slower connections, lower-powered devices, background apps, and less available memory. A page that feels acceptable on a desktop can still be frustrating on a phone.

When should I hire a developer or contact my host?

Ask for help when the bottleneck involves slow server response, database queries, complex JavaScript, deployment caching, redirect behavior, or changes that could affect critical features such as checkout, account access, forms, or consent management.