The Obsession with a Perfect Score

When Google introduced PageSpeed Insights as a ranking signal, the web development community split into two camps: those who chased the perfect 100/100 score and those who dismissed it as a vanity metric. After delivering over 175 WordPress projects — from simple brochure sites to complex membership platforms — we’ve landed firmly in the middle: a perfect score isn’t everything, but the discipline required to achieve it produces genuinely better websites.

At CODE TOT, our Hanoi-based WordPress agency, we’ve maintained an average PageSpeed score of 96+ across all projects, with over 60% hitting a perfect 100/100 on both desktop and mobile. This article breaks down the exact stack, configuration, and workflow that makes this possible — no magic plugins, no black-hat tricks, just systematic optimization.

“A 100/100 PageSpeed score is not the goal. The goal is a fast, reliable, accessible website. The perfect score is merely a byproduct of getting the fundamentals right.”

Foundation: The Server Stack Makes or Breaks You

You cannot out-optimize a slow server. Before we touch a single line of WordPress code, we ensure the hosting environment is built for speed. Here’s our standard stack:

ComponentOur ChoiceWhy
Web ServerLiteSpeed EnterpriseUp to 5x faster than Apache under concurrent load; native LSCache support
PHP Version8.2+40-50% faster execution than PHP 7.4; JIT compiler in PHP 8.0+
Object CacheRedis (via LSCache + Redis Object Cache)In-memory caching reduces database queries by 80-90%
CDNQUIC.cloud CDN (or Cloudflare APO)Edge caching with automatic cache purge on content update
DatabaseMariaDB 10.6+Better query optimization and replication than MySQL 5.x

The single biggest performance lever is LiteSpeed Cache (LSCache). Unlike generic caching plugins, LSCache integrates directly with the LiteSpeed web server at the kernel level, enabling page caching, ESI (Edge Side Includes), and image optimization without PHP overhead.

Essential LSCache Configuration

After hundreds of deployments, this is our baseline LSCache setup:

// LiteSpeed Cache Settings (via wp-config.php or .htaccess)
// Enable cache for logged-in users (with ESI for dynamic elements)
define('LITESPEED_ON', true);
define('LITESPEED_ALLOW_ADMIN', true);

// Cache TTL: 1 hour for pages, 24 hours for feeds
// Cache varies by: cookie, user-agent, SSL, query string
// Exclude: cart, checkout, my-account (WooCommerce)

For QUIC.cloud CDN, we enable the following features:

  • Auto Purge: Cache is automatically purged when content is updated
  • Critical CSS: Generated per-device (desktop/mobile) and served inline
  • CSS/JS Minification: Combined and minified with async loading
  • Image Optimization: WebP conversion with lossless compression

Image Optimization: The Low-Hanging Fruit That Keeps Giving

Images account for 50-70% of a typical page’s weight. In our 175-project dataset, improper image handling was the #1 cause of sub-90 PageSpeed scores. Here’s our image pipeline:

Our Image Workflow

  1. Source optimization: Designers export at 2x resolution (Retina-ready) but we serve at 1x with srcset for high-DPI displays
  2. Format selection: WebP primary, AVIF for supported browsers, JPEG/PNG fallback
  3. Compression: Lossless WebP via QUIC.cloud Image Optimization (or ShortPixel for non-LiteSpeed setups)
  4. Lazy loading: Native loading=”lazy” + LSCache’s lazy-load iframe/images
  5. Responsive images: Full srcset/sizes implementation for art-directed breakpoints
<!-- Example: Optimized image markup -->
<img 
  src="hero-1024.webp" 
  srcset="hero-512.webp 512w, hero-1024.webp 1024w, hero-2048.webp 2048w"
  sizes="(max-width: 768px) 100vw, 1024px"
  alt="WordPress project showcase from CODE TOT agency"
  loading="lazy"
  decoding="async"
/>

Pro tip: We use the fetchpriority="high" attribute on the Largest Contentful Paint (LCP) image to signal its importance to the browser, while all other images use loading="lazy". This single change improved LCP by an average of 0.4s across our projects.

CSS and JavaScript: Eliminating Render-Blocking

Render-blocking resources are the second most common PageSpeed killer. Our approach is aggressive but systematic:

CSS Strategy

  • Critical CSS: Extracted per-page-type (home, single, archive, etc.) and inlined in <head>
  • Deferred CSS: Non-critical styles loaded asynchronously via media="print" onload="this.media='all'"
  • No @import: All CSS loaded via <link> tags — @import is render-blocking by nature
  • Minification: Combined into 1-2 files max, minified via LSCache or Autoptimize

JavaScript Strategy

  • Defer everything: All non-critical JS loaded with defer attribute
  • Inline critical JS: Essential scripts (analytics bootstrap, cookie consent) inlined in <head>
  • Remove jQuery dependency: Where possible, we use vanilla JavaScript or Alpine.js instead of jQuery
  • Code splitting: For complex interactions, we load JS on interaction (not on page load)
<!-- Non-blocking CSS pattern -->
<link rel="preload" href="/css/critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/critical.css"></noscript>

<!-- Deferred non-critical CSS -->
<link rel="stylesheet" href="/css/theme.css" media="print" onload="this.media='all'">

<!-- Deferred JavaScript -->
<script src="/js/app.js" defer></script>

Core Web Vitals: Beyond the Score

Google’s Core Web Vitals — LCP, CLS, and INP — are the metrics that actually impact user experience and SEO rankings. A perfect PageSpeed score must translate to green CWV in the field (real-user monitoring), not just lab tests.

MetricTargetOur AverageKey Technique
LCP (Largest Contentful Paint)< 2.5s1.2sPreload hero image, optimize TTFB, inline critical CSS
CLS (Cumulative Layout Shift)< 0.10.02Explicit width/height on all media, reserve space for embeds
INP (Interaction to Next Paint)< 200ms85msDebounce event handlers, avoid long tasks, code splitting
TTFB (Time to First Byte)< 800ms320msLiteSpeed + Redis + QUIC.cloud edge caching

LCP Optimization Deep Dive

LCP is the most visible performance metric. Here’s exactly how we optimize it:

  1. TTFB first: We ensure the server responds in under 400ms. This means LiteSpeed + Redis + CDN. No exceptions.
  2. Preload the LCP element: We identify the LCP candidate (usually the hero image or heading) and preload it:
<!-- Preload the LCP image -->
<link rel="preload" href="/images/hero.webp" as="image" 
      imagesrcset="/images/hero-512.webp 512w, /images/hero-1024.webp 1024w"
      imagesizes="100vw">

<!-- Preconnect to critical origins -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://quic.cloud" crossorigin>
  1. Inline critical CSS: The CSS needed to render the above-the-fold content is inlined directly in <head>, eliminating the render-blocking CSS request.

CLS: The Silent UX Killer

Cumulative Layout Shift is often caused by images, ads, and web fonts loading after the page has already painted. Our rules:

  • Always set dimensions: Every <img>, <video>, and <iframe> must have explicit width and height attributes
  • Font-display: swap: We use font-display: swap with a size-adjust fallback to prevent layout shift from web fonts
  • Reserve ad/embed space: Any third-party embed (YouTube, Google Maps, Facebook) gets a placeholder container with fixed aspect ratio
/* Web font loading with zero CLS */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100%; /* Match fallback font metrics */
}

/* Reserve space for embeds */
.embed-container {
  position: relative;
  width: 100%;
  aspect-ratio: 16 / 9;
}

Database Optimization: The Hidden Bottleneck

A clean database is essential for consistent performance. WordPress’s default behavior — storing post revisions, trashed items, transients, and session data — creates bloat that slows queries over time.

Our Database Maintenance Routine

// wp-config.php — Limit post revisions
define('WP_POST_REVISIONS', 5);
define('AUTOSAVE_INTERVAL', 300); // 5 minutes

// Disable post-by-email (uses cron + database)
define('WP_POST_BY_EMAIL', false);

Monthly automated tasks via WP-CLI:

# Optimize the database tables
wp db optimize

# Clean up transients (expired)
wp transient delete --expired

# Remove spam comments
wp comment delete $(wp comment list --status=spam --format=ids)

# Clean post revisions older than 30 days
wp db query "DELETE FROM wp_postmeta WHERE post_id IN (SELECT ID FROM wp_posts WHERE post_type='revision' AND post_date < DATE_SUB(NOW(), INTERVAL 30 DAY));"
wp db query "DELETE FROM wp_posts WHERE post_type='revision' AND post_date < DATE_SUB(NOW(), INTERVAL 30 DAY);"

ACF + Custom Blocks: Performance by Design

We moved from page builders to ACF + custom blocks (as detailed in our previous article on project structure) specifically because page builders generate bloated markup and inline styles that tank PageSpeed scores.

Our custom blocks are designed with performance in mind:

  • No inline styles: All styling goes through the theme’s compiled CSS
  • Conditional loading: Block assets (CSS/JS) only enqueue when the block is present on the page
  • Semantic HTML: Clean, accessible markup that browsers can parse quickly
  • Dynamic rendering: Server-side rendered blocks (no client-side hydration overhead)
<?php
/**
 * Example: Performance-optimized ACF block template
 * Block: "Testimonial Carousel"
 * Assets only load when this block is used on the page
 */

// Block registration (functions.php or block plugin)
add_action('acf/init', function() {
    acf_register_block_type([
        'name'            => 'testimonial-carousel',
        'title'           => __('Testimonial Carousel'),
        'render_template' => 'blocks/testimonial-carousel.php',
        'enqueue_assets'  => function() {
            // Only enqueue when block is present
            wp_enqueue_style('block-testimonial', get_template_directory_uri() . '/blocks/testimonial-carousel.css');
            wp_enqueue_script('block-testimonial', get_template_directory_uri() . '/blocks/testimonial-carousel.js', [], false, true);
        },
        'supports'        => [
            'align' => false, // Disable align to reduce inline styles
        ],
    ]);
});
?>

Monitoring: You Can’t Improve What You Don’t Measure

Achieving 100/100 is one thing; maintaining it across content updates, plugin updates, and client changes is another. We use a three-layer monitoring approach:

LayerToolFrequencyWhat We Track
Lab TestingGoogle PageSpeed Insights + Lighthouse CIEvery deploymentScore, LCP, CLS, TBT, SI
Field DataCrUX (Chrome User Experience Report)Daily (via Google Search Console)Real-user LCP, CLS, INP
Server MonitoringNew Relic / RunCloud MetricsReal-timeTTFB, PHP execution time, DB query time, cache hit rate

We also run a weekly automated Lighthouse audit via GitHub Actions that posts results to Slack. If any page drops below 90 on mobile, the development team gets an alert.

The Results: What 175+ Projects Taught Us

After optimizing over 175 WordPress projects, here’s what we’ve learned about what actually moves the needle:

  1. Hosting is 40% of the battle. Moving a client from shared hosting to LiteSpeed + Redis improved scores by 15-25 points on average — before any code changes.
  2. Images are 30%. Proper image optimization (WebP, srcset, lazy loading) alone can take a site from 70 to 90+.
  3. CSS/JS optimization is 20%. Critical CSS + deferred JS typically adds 5-10 points.
  4. Everything else is 10%. Database optimization, font loading, server config tweaks — important but diminishing returns.

“The fastest request is the one never made. Every byte you don’t send, every script you don’t load, every query you don’t run — that’s where real performance comes from.”

Conclusion: The Performance Mindset

Achieving 100/100 on PageSpeed Insights across 175+ projects didn’t come from a single magic plugin or configuration. It came from building a performance-first culture — where every developer, designer, and project manager understands that speed is a feature, not an afterthought.

If you’re starting your performance optimization journey, begin with the fundamentals: get good hosting, optimize your images, and eliminate render-blocking resources. That alone will get you to 90+. The remaining 10 points come from the discipline of maintaining those standards across every project.

For more insights on how we run our WordPress agency, check out our articles on WordPress maintenance retainers and brand identity for SMEs.

External References