Why We Stripped 80 Percent of JavaScript From Our Agency Showcase
Last November, our lead creative director stood in front of a prospective European client to present a sixty-thousand-dollar brand redesign pitch. He opened our agency portfolio on his iPad Pro, clicked on our featured cases page, and waited. The screen stayed completely white for three seconds while the browser downloaded two megabytes of packed animation libraries, web fonts, and dynamic grid calculators. When the page finally rendered, the custom cursor lagged behind his finger input, and the primary case study video frame jumped twice before settling down.
We did not win that account. The feedback email was short: the client loved our static design work, but they questioned our technical capability to build responsive, fast digital experiences for their global customer base.
Losing that project was a wake-up call for our dev team. Over four years of agency growth, we had slowly turned our own website into a bloated testing ground. We had stacked interactive cursor plugins, heavy smooth-scroll wrappers, full-screen canvas particle engines, and complex masonry grid scripts onto our theme. The site looked impressive in static design mockups, but under real-world network conditions and across mid-tier mobile devices, it was a usability nightmare.
We spent the next three weeks performing a complete, top-to-bottom architectural overhaul of our digital portfolio. This case study details how we eliminated client-side execution bottlenecks, refactored our CSS layout pipeline, cleaned up database options, configured Varnish edge caching, and rebuilt our agency platform around speed, usability, and search engine visibility.
Diagnosing Layout Thrashing and Main Thread Delays
We started our performance investigation by opening Chrome DevTools on a fresh browser profile with CPU throttling set to 4x slowdown and network set to Fast 3G. We recorded a ten-second performance profile while scrolling through our agency case studies archive.
The performance timeline revealed severe main-thread congestion. The browser spent 1,420 milliseconds executing JavaScript, 680 milliseconds recalculating layout styles, and 410 milliseconds rendering pixels. Total main thread blocking time exceeded 950 milliseconds during initial page load, far above Google recommended limit of 200 milliseconds.
# Chrome DevTools performance capture summary baseline
# Total loading time: 3.82 seconds
# Script execution: 1420 milliseconds
# Style recalculation: 680 milliseconds
# Layout reflow calls: 312 instances
# Interaction to Next Paint: 340 millisecondsThe primary culprit was layout thrashing caused by a legacy JavaScript layout library. To create an staggered masonry layout for our portfolio thumbnails, the script queried the offsetHeight and offsetWidth properties of every DOM node inside a tight loop, forced an immediate style recalculation, and then set inline CSS top and left positions for each image card.
Because this calculation ran every time the user scrolled or resized their browser window, the main thread was constantly locked in a recalculation loop. User scroll inputs were delayed, mobile devices heated up rapidly, and Google Interaction to Next Paint metric flashed red across our Search Console diagnostics.
Auditing the Backend Dependency Chain with WP-CLI
Before modifying frontend template code, we examined our application backend to identify unused plugins, orphan option keys, and slow database queries. We connected to our staging server using SSH and ran a series of diagnostic WP-CLI commands.
We audited active database queries using the Query Monitor hook alongside WP-CLI to inspect total autoload size inside the options table.
# Query total autoloaded option size in kilobytes
wp option list --autoload=on --format=total_bytes | awk '{print $1/1024 " KB"}'
# Identify the top 15 largest options loaded on every request
wp db query "SELECT option_name, LENGTH(option_value) AS option_size FROM wp_options WHERE autoload = 'yes' ORDER BY option_size DESC LIMIT 15;"The database inspection revealed that our options table contained nearly 2.8 megabytes of autoloaded data. Previous developers had installed multiple analytics tools, social feed aggregators, and dynamic style builders that left behind massive JSON state objects. Every single PHP execution thread was reading and parsing this 2.8MB payload from disk before processing page templates, adding nearly 280 milliseconds of unnecessary Time to First Byte latency.
We also found over forty inactive transient records storing expired external API tokens, along with dozens of orphan metadata rows associated with deleted custom post revisions.
Moving to Zero-Runtime CSS and Clean HTML Scaffolding
To eliminate main-thread layout thrashing and cut script execution to the absolute minimum, we decided to completely discard our legacy frontend framework. We wanted a structure that relied on native browser layout engines rather than running continuous JavaScript math routines.
While evaluating lightweight framework options for agency and freelancer portfolios, we migrated our client showcase layout to the Minfolio WordPress Theme because its architectural design relies on native CSS Grid and container queries rather than dynamic script calculations, delivering clean HTML output with minimal layout nesting.
By switching to native browser capabilities, we eliminated the layout calculation library entirely. We replaced JavaScript-driven masonry math with native CSS subgrid and CSS flexbox rules that calculate positions instantly at the browser engine level.
/* Lightweight native agency showcase grid layout */
.portfolio-case-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(340px, 1fr));
gap: 2rem;
width: 100%;
}
.portfolio-card {
display: flex;
flex-direction: column;
background-color: #0d0e12;
border-radius: 8px;
overflow: hidden;
transition: transform 0.25s cubic-bezier(0.16, 1, 0.3, 1);
}
/* Container query for responsive card typography without window listeners */
@container (min-width: 400px) {
.portfolio-card-title {
font-size: clamp(1.25rem, 2vw, 1.75rem);
line-height: 1.2;
}
}
.portfolio-card:hover {
transform: translateY(-4px);
}This transition reduced our total DOM element count on case study archives from 1,950 nodes down to 420 nodes. More importantly, it completely eliminated forced synchronous layout reflows during scrolling, dropping our main-thread style calculation time from 680 milliseconds to under 18 milliseconds.
Automating Critical Path CSS and Font Preloading
Rendering visual agency portfolios requires crisp typography and sharp imagery, but external web fonts and heavy CSS stylesheets often block page rendering. The browser pauses rendering until all render-blocking stylesheets are downloaded, parsed, and applied.
We optimized our asset loading pipeline by extracting critical inline CSS required to render above-the-fold content and deferring non-critical styles until after initial paint.
We hosted all typography files locally using modern WOFF2 compression formats instead of loading external font stylesheets from third-party networks. This eliminated external DNS lookups, TLS handshakes, and network connection delays.
// Preload local font assets and inject critical CSS inline
function optimize_agency_critical_assets() {
// Preload primary heading WOFF2 font file
echo '<link rel="preload" href="' . get_template_directory_uri() . '/assets/fonts/inter-bold.woff2" as="font" type="font/woff2" crossorigin>' . "\n";
// Inject minimal inline CSS for above-the-fold layout structure
echo '<style id="critical-path-css">
body{margin:0;padding:0;background-color:#07080a;color:#f0f2f5;font-family:-apple-system,BlinkMacSystemFont,sans-serif}
.header-nav{display:flex;justify-content:space-between;align-items:center;padding:1.5rem 2rem}
.hero-title{font-size:clamp(2rem,5vw,4rem);font-weight:700;line-height:1.1;letter-spacing:-0.02em}
</style>' . "\n";
}
add_action( 'wp_head', 'optimize_agency_critical_assets', 1 );We also configured asynchronous font loading with font-display swap, ensuring text remains visible in system fonts immediately while custom typography downloads in the background. This eliminated flash of unstyled text layout shifts entirely.
Database Cleaning and Option Table Autoload Optimization
With the frontend rendering cleanly, we returned to our database layer to resolve the 2.8MB options table bloat identified during our initial WP-CLI diagnostic.
We wrote a custom database cleanup script to disable autoloading on large non-essential settings keys and removed expired transient records from MariaDB.
# Delete all expired transients directly via WP-CLI
wp transient delete --expired
# Clean up orphan post metadata rows from deleted revisions
wp db query "DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts wp ON wp.ID = pm.post_id WHERE wp.ID IS NULL;"
# Disable autoload on heavy third-party settings keys
wp db query "UPDATE wp_options SET autoload = 'no' WHERE option_name LIKE '%_transient_%' OR option_name IN ('heavy_analytics_cache', 'legacy_theme_settings');"After clearing orphan data and disabling autoloading on non-critical options keys, total autoloaded database size dropped from 2,800 kilobytes down to 84 kilobytes.
-- Query to verify updated autoload size across active options
SELECT SUM(LENGTH(option_value)) / 1024 AS autoload_kb FROM wp_options WHERE autoload = 'yes';Lowering the database memory footprint reduced PHP database initialization times from 280 milliseconds down to 14 milliseconds per request, giving our application backend an instant speed boost across both dynamic and admin routes.
Streamlining Plugin Dependencies and Asset Dequeueing
Agency portfolio sites often accumulate plugins installed for temporary client demos or isolated utility tasks. Every added plugin introduces extra CSS stylesheets, script files, and potential database hooks that degrade site health.
When building client agency sites or evaluating fresh design options, utilizing a curated WordPress themes bundle download library enables rapid prototyping across sandbox environments without loading down production installs with excess plugins.
We removed seventeen non-essential extensions, retaining only a focused set of Essential Plugins dedicated to object caching, media compression, form processing, and security protection.
To ensure remaining plugin scripts loaded only on pages where they were actually required, we implemented a granular script dequeueing function in our theme setup file.
// Selective asset dequeueing based on context
function purge_unused_agency_scripts() {
if ( is_admin() ) {
return;
}
// Dequeue form scripts on pages without active contact forms
if ( ! is_page_template( 'page-templates/contact.php' ) ) {
wp_dequeue_style( 'contact-form-7' );
wp_dequeue_script( 'contact-form-7' );
wp_dequeue_script( 'google-recaptcha' );
}
// Remove block editor styles on custom HTML portfolio layouts
if ( is_post_type_archive( 'portfolio' ) || is_singular( 'portfolio' ) ) {
wp_dequeue_style( 'wp-block-library' );
wp_dequeue_style( 'wp-block-library-theme' );
wp_dequeue_style( 'global-styles' );
}
}
add_action( 'wp_enqueue_scripts', 'purge_unused_agency_scripts', 100 );Unloading non-critical CSS and JS payloads reduced our total network request count on portfolio archives from 78 requests down to 14 requests, saving over 1.2 megabytes of bandwith per visitor.
Varnish Edge Caching and Custom Purge Logic
To serve unauthenticated visitors at scale without hitting PHP execution workers, we placed Varnish Cache in front of our Nginx web server layer.
Varnish stores fully rendered HTML pages directly in RAM and serves guest visitor requests in under 10 milliseconds. However, portfolio sites require immediate cache purging when new case studies are published or existing projects are modified.
We added a custom Varnish configuration file designed to handle cache purges via HTTP requests sent directly from WordPress.
vcl 4.0;
backend default {
.host = "127.0.0.1";
.port = "8080";
}
sub vcl_recv {
# Allow PURGE requests from localhost
if (req.method == "PURGE") {
if (!client.ip ~ purge_allowed) {
return (synth(405, "Not allowed."));
}
return (purge);
}
# Pass authenticated users or POST requests directly to backend
if (req.method == "POST" || req.http.Cookie ~ "wordpress_logged_in_") {
return (pass);
}
# Strip non-essential cookies to maximize cache hit ratio
set req.http.Cookie = regsuball(req.http.Cookie, "has_js=[^;]+(; )?", "");
set req.http.Cookie = regsuball(req.http.Cookie, "_ga=[^;]+(; )?", "");
return (hash);
}
sub vcl_backend_response {
# Cache static asset and guest responses for 24 hours
if (beresp.status == 200) {
set beresp.ttl = 24h;
set beresp.grace = 1h;
}
}We paired this Varnish configuration with a lightweight PHP save_post hook that sends an HTTP PURGE request to Varnish whenever a team member updates a case study or publishes a new portfolio piece.
// Automatically purge Varnish cache when portfolio posts are updated
function purge_varnish_cache_on_portfolio_update( $post_id ) {
if ( wp_is_post_revision( $post_id ) || get_post_type( $post_id ) !== 'portfolio' ) {
return;
}
$site_url = get_option( 'siteurl' );
$purge_url = parse_url( $site_url );
// Send PURGE request to local Varnish daemon
wp_remote_request( 'http://127.0.0.1:80', array(
'method' => 'PURGE',
'headers' => array(
'Host' => $purge_url['host'],
),
) );
}
add_action( 'save_post', 'purge_varnish_cache_on_portfolio_update' );With Varnish active, our application server handled sustained traffic spikes of over 400 requests per second with average response times lingering at 8 milliseconds.
Performance Metrics and SEO Ranking Growth
Three weeks after pushing our refactored architecture to production, we ran comprehensive benchmark audits across Google PageSpeed Insights, WebPageTest, and Google Search Console real-user monitoring.
# Post-optimization performance audit summary
# Time to First Byte: 8 milliseconds (Varnish cached)
# Largest Contentful Paint: 0.7 seconds
# Interaction to Next Paint: 24 milliseconds
# Cumulative Layout Shift: 0.00
# Performance Score: 99 / 100 on MobileOur Largest Contentful Paint metric plummeted from 3.8 seconds down to 0.7 seconds, well under Google 2.5-second benchmark. Interaction to Next Paint dropped from 340 milliseconds to 24 milliseconds, delivering instant visual feedback across touchscreens and desktop mice alike.
The business impact was immediate. Within two months of deploying the performance updates, our organic search impressions jumped 64 percent across high-value commercial keywords like digital design agency, custom branding showcase, and responsive portfolio development.
More importantly, our conversion rate on incoming client lead forms increased by 38 percent. Potential clients were no longer abandoning our portfolio mid-scroll due to white screens or laggy animations. By stripping away non-essential code and building on a clean, speed-focused foundation, we turned our agency site from a technical liability into our strongest sales engine.
