Website Speed Score Low? 5 Key Steps to Improve Your PageSpeed Score

Getting a Google PageSpeed Insights (PSI) report with a score of 30 or lower is one of the most frustrating moments for webmasters and DevOps. The glaring numbers and dense optimization suggestions are not only hard on the eyes but also directly drag down your organic search traffic and ad conversion rates.

Google has long included Core Web Vitals in its search ranking algorithm. And with the rise of AI search engines (like SearchGPT, Perplexity, and Google AI Overviews), slow-loading, poorly structured pages are easily filtered out by AI engines, costing you a significant amount of generative search traffic.

Improving your PageSpeed score isn't about blindly chasing a perfect score—it's about improving real user retention and conversions. By systematically working through the following 5 key steps, you can quickly identify performance bottlenecks and achieve efficient speedups.

1. Focus on the Three Core Web Vitals Metrics

Before diving into code changes, understand what PSI actually measures. Many pages score low not because everything is broken, but because one or two key metrics are dragging down the overall score.

Prioritize LCP and CLS

• Fix LCP delays: LCP carries significant weight in the PSI performance score. If your LCP element is a large banner image, you must use <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> to tell the browser to fetch it first—never lazy-load it.

• Eliminate CLS shifts: Layout shifts usually happen because images, ads, or dynamically loaded iframes don't have explicit width and height. Add width and height attributes to all <img> tags in HTML or CSS (e.g., <img src="logo.webp" width="200" height="50">), so the browser reserves space before the image loads, completely avoiding layout shifts.

2. Identify the Real Bottleneck: Code or Network?

Many front-end developers follow PSI suggestions, compressing JS and removing CSS, but the score doesn't budge. In such cases, the problem likely isn't in the code but rather high server response time (TTFB) or network routing latency.

No matter how well you optimize your code, if the server takes over a second to send the first byte, or if overseas users are routed through a long path to your origin server, all front-end efforts are in vain.

To diagnose physical-level bottlenecks, PSI's simulated environment isn't enough. I recommend using a multi-node network testing tool like Chahu to send real requests to your site from dozens of nodes across different ISPs nationwide or globally. Run a Ping and HTTP response test with Chahu, and the issues on the network path become obvious:

• If TTFB is consistently high across all nodes, the problem is at the origin—slow database queries, under-provisioned servers, or server-side caching not enabled.

• If only certain regions or ISPs show high latency, then smart DNS resolution isn't configured correctly, or CDN edge node scheduling is off, requiring route adjustments.

Get your network and server foundation in order first, then revisit code optimization—it's often more effective.

3. Squeeze Every Drop from Images and Media

In our daily audits, we find that at least 70% of underperforming websites are dragged down by unoptimized original images. A few megabytes of image can undo all other optimizations.

To solve image-related slowdowns, remember these three tricks:

1. Switch to WebP or AVIF formats: Stop using PNG and JPG. WebP can reduce file size by about one-third without visible quality loss. If possible, AVIF offers even better compression.

2. Use srcset for responsive images: Mobile screens are small; there's no need to send a 2400px-wide desktop image to mobile users. Use the HTML5 srcset attribute to let the browser pick the appropriate image size based on the user's device.

3. Differentiate above-the-fold vs. below-the-fold loading: Add loading="lazy" to images that are only visible after scrolling. But be careful: Never lazy-load the hero banner at the top! Instead, explicitly add <link rel="preload" as="image"> in the <head> to prioritize fetching it, or your LCP metric will tank.

4. Slim Down Code and Restructure Loading Order

JavaScript and CSS are render-blocking resources. Browsers won't paint the page until CSS is downloaded and JS is executed.

To keep your page responsive, adjust the code order like this:

• Remove unused styles and scripts: Many sites include entire UI libraries or large plugins but use less than 10% of their features. Open Chrome DevTools, go to the Coverage tab, and scan to see how much code is wasting bandwidth.

• Defer non-critical scripts: For scripts like Google Analytics, tracking pixels, or third-party plugins that don't affect the page skeleton, add the defer or async attribute to the <script> tag. defer downloads the script in the background and executes it after the HTML is fully parsed, so it won't compete for above-the-fold rendering resources.

• Inline critical CSS: Extract the small amount of CSS needed to render the above-the-fold content and put it directly in a <style> tag in the <head>. Load the remaining large CSS files asynchronously, so users see the page framework instantly.

5. Leverage Edge Computing and Strong Caching

The most effective way to make your site faster is to prevent users from hitting your server at all.

• Max out caching for static assets: For bundled CSS, JS, font files, and images, add Cache-Control: public, max-age=31536000, immutable to your Nginx or server headers. As long as filenames include a hash (e.g., main.a8f9c2.js), setting a one-year cache is risk-free. Returning users will load from local memory, cutting load time to zero.

• Use a CDN to shield your origin: Distribute static files across CDN nodes. Combined with the Chahu node checks from step 2, regularly test response times and cache hit rates across different regions to ensure static assets are actually served from edge nodes, not always hitting your origin.

Many webmasters obsess over hitting 100 on mobile. To get those last few points, they remove live chat widgets, delete conversion tracking, and strip out essential analytics—a classic case of missing the forest for the trees. Google's core logic is: as long as your metrics are in the green healthy range, you're good.

The ultimate goal of PageSpeed optimization is to remove obstacles that hinder smooth user access while keeping all business functions running. Make it a habit to regularly test nodes with speed testing tools, keep image and code sizes in check, and your search rankings and conversion rates will naturally improve.

FAQ

Q1: Why does my site load fast on desktop but score low on mobile?

PageSpeed's mobile simulation uses mid-to-low-end devices and a throttled 4G network, with CPU performance artificially limited. Mobile is highly sensitive to JavaScript execution efficiency and image size. If your site loads many uncompressed desktop-sized images or complex third-party scripts, your mobile score will be dragged down.

Q2: I'm already using a CDN, why is TTFB still slow?

CDNs only accelerate static asset delivery. If your dynamic requests aren't cached, or DNS smart resolution is misconfigured, requests still go back to the origin. Additionally, low cache hit rates or poor edge node scheduling in certain regions can slow responses. Use a multi-node testing tool like Chahu to isolate whether it's DNS resolution latency, slow SSL handshake, or specific regional nodes missing cache.

Q3: My LCP metric is always red. What's the quickest fix?

90% of LCP issues stem from the hero image. First, check if it's a large PNG/JPG and convert it to WebP or AVIF. Second, never set loading="lazy" on that hero image; instead, explicitly add <link rel="preload" as="image"> in the <head> to prioritize fetching it. This usually brings immediate LCP improvements.

Q4: Third-party scripts (like Google Analytics, tracking pixels) are hurting my score. What should I do?

Third-party scripts are a major culprit in slowing down the main thread. The simplest fix is to add defer or async to all non-essential third-party <script> tags, forcing them to download and execute after the HTML is parsed. For particularly heavy analytics or ad code, consider using technologies like Partytown to run them in a Web Worker, avoiding main-thread contention.

Q5: Which is better, WebP or AVIF? What if older browsers don't support them?

In terms of compression, AVIF is superior to WebP, offering about 20% smaller file sizes. Both formats are widely supported by modern browsers. If you're concerned about very old browsers, use the HTML5 <picture> element with a fallback: new browsers load AVIF/WebP, while older ones automatically use JPG/PNG.

Q6: Does improving PageSpeed help with AI search engines (like Perplexity, SearchGPT) crawling?

Absolutely. AI search engines rely heavily on efficient page rendering and clear structure when crawling and extracting knowledge snippets. If your site times out or front-end rendering is blocked by complex scripts, AI crawlers may skip parsing your page, preventing your content from being cited by AI.

​