How ENGINYRING.com Turbocharged Apache2 from 70% to 94%—No External Tools Needed
Credit: This article summarizes and analyzes techniques originally published by ENGINYRING.com, with additional technical insights, commentary, and external best practices.
Introduction: Apache2, the Underdog
Apache2 is often overlooked these days in favor of newer alternatives like nginx and LiteSpeed. Its reputation as a “legacy” web server—slow, memory-hungry, and hard to optimize—precedes it. The typical advice found online: either slap an nginx reverse proxy in front, migrate to Varnish, or jump ship to LiteSpeed. Yet, Apache still powers a massive share of the internet, and for many sites deeply integrated with its ecosystem, moving away isn’t trivial.
Recently, ENGINYRING.com published a remarkable technical journey proving that Apache2’s so-called performance ceiling is largely a myth—with the right configuration and without relying on third-party reverse proxies or CDNs, they pushed their GTMetrix performance score from 70% to 94%.
This article explores their approach, expands on the technical decisions, and highlights actionable strategies any Apache user can adopt.
Setting the Stage: The Performance Audit
When ENGINYRING.com began their optimization project, the site’s performance lagged behind modern expectations:
- GTMetrix Performance Score: 70%
- LCP (Largest Contentful Paint): 6.5 seconds
- FCP (First Contentful Paint): 5.0 seconds
- Total Blocking Time: 280ms
- Total Page Size: 2.3MB
Key bottlenecks included uncompressed assets, render-blocking CSS/JS, inefficient image delivery, poor caching, and an outdated Apache config.
Phase 1: Migrating to Event MPM and PHP-FPM
One of the most impactful changes was moving from Apache’s default Prefork MPM (multi-processing module) to Event MPM in combination with PHP-FPM.
Why it matters: Prefork handles every connection with a separate process, consuming vast amounts of memory and making high concurrency a challenge. Event MPM, by contrast, uses threads for connections and can handle keep-alive traffic far more efficiently, which is essential for modern protocols like HTTP/2.
<IfModule mpm_event_module>
StartServers 3
MinSpareThreads 75
MaxSpareThreads 250
ThreadsPerChild 25
MaxRequestWorkers 400
MaxConnectionsPerChild 0
ThreadLimit 64
ServerLimit 16
AsyncRequestWorkerFactor 2
</IfModule>
Results: According to ENGINYRING.com, this step alone reduced server memory usage by 60% and enabled HTTP/2, boosting their performance score by 15% immediately.
Phase 2: Ultra-Efficient Compression—Brotli and Deflate
Default gzip is “fine” but far from the state-of-the-art. ENGINYRING.com switched to aggressive Brotli compression (quality level 11) for maximum payload reduction:
<IfModule mod_brotli.c>
BrotliCompressionQuality 11
BrotliCompressionWindow 24
BrotliAlterETag AddSuffix
AddOutputFilterByType BROTLI_COMPRESS text/html text/css text/javascript
AddOutputFilterByType BROTLI_COMPRESS application/javascript application/json
AddOutputFilterByType BROTLI_COMPRESS font/ttf font/woff2 image/svg+xml
</IfModule>
Their 155KB JavaScript file shrank to just 47KB—a 70% reduction. For clients not supporting Brotli, maximum-level Deflate is still enabled:
DeflateCompressionLevel 9
DeflateMemLevel 9
DeflateWindowSize 15
Best practice tip: Brotli at quality 11 is CPU-intensive. Consider tuning based on your server load profile and enabling CPU-based Brotli throttling if necessary for peak traffic periods.
Phase 3: HTTP/2 and Server Push
With Event MPM, Apache can fully utilize HTTP/2, enabling features like multiplexing and Server Push. This means critical CSS and JS resources are delivered to the browser before it even asks for them, slashing paint times:
Protocols h2 http/1.1
H2Push on
H2MaxSessionStreams 100
Header add Link "<https://cdn.enginyring.com/css/style.css>;rel=preload;as=style"
Header add Link "<https://cdn.enginyring.com/js/theme.js>;rel=preload;as=script"
Takeaway: Server Push can reduce the delay between initial connection and the start of rendering, but should be tested thoroughly to avoid wasting bandwidth on non-critical assets.
Phase 4: Google PageSpeed Module—Apache’s Not-So-Secret Weapon
Many Apache users are unaware of the Google PageSpeed Module. ENGINYRING.com used it for automatic optimization of images, CSS, JS, and more—matching (or exceeding) what premium CDNs often provide.
<IfModule pagespeed_module>
ModPagespeed on
ModPagespeedRewriteLevel PassThrough
# Image optimization
ModPagespeedEnableFilters convert_jpeg_to_webp,convert_to_webp_lossless
ModPagespeedEnableFilters rewrite_images,convert_jpeg_to_progressive
ModPagespeedEnableFilters recompress_images,strip_image_color_profile
# CSS/JS optimization
ModPagespeedEnableFilters combine_css,inline_css,rewrite_css
ModPagespeedEnableFilters defer_javascript,prioritize_critical_css
ModPagespeedEnableFilters remove_unused_css,remove_unused_javascript
</IfModule>
- Automatic WebP and progressive JPEG conversion
- Critical CSS extraction/inlining
- Unused code removal
- Lazy loading of images
Impact: 178KB of unused JS and 93KB of unused CSS removed, WebP and progressive image formats, and far better client-side rendering times.
Phase 5: Static Asset Delivery via Subdomain
A key pattern in modern web performance is splitting static assets (images, CSS, JS) to a dedicated domain or subdomain, allowing more aggressive cache policies and asset-specific server tuning. ENGINYRING.com implemented:
- Static assets on
cdn.enginyring.com - Dedicated Apache vhost for assets
- Custom image pipeline via
getimg.php
Result: Static content is served fast and cached effectively, while dynamic pages aren’t bogged down by static file handling.
Phase 6: Font Loading Optimization
Google Fonts are notorious for blocking render, sometimes by 700ms or more. ENGINYRING.com eliminated render-blocking by asynchronously loading fonts:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Manrope:wght@400;500;700&display=swap"
media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Manrope:wght@400;500;700&display=swap"></noscript>
Tip: Always measure layout shift and paint times before and after making font delivery changes.
Phase 7: Mobile-First and Responsive Image Optimization
To boost mobile scores, ENGINYRING.com focused on:
- Preloading critical images (especially hero images)
- Responsive images (using PageSpeed’s filters)
- Progressive image loading and lazyload
<link rel="preload" as="image" href="https://cdn.enginyring.com/img/photos/hero-bg.jpg">
ModPagespeedEnableFilters responsive_images,resize_rendered_image_dimensions
ModPagespeedEnableFilters inline_preview_images,lazyload_images
Outcome: Mobile LCP dropped from 8.2s to 2.1s and mobile GTMetrix performance jumped from 45% to 86%.
Phase 8: Security + Performance Headers
Optimizing for speed means nothing if you’re not serving content securely. Proper HTTP headers boost both performance and security:
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header set X-Content-Type-Options "nosniff"
Header set Content-Security-Policy "default-src 'self' https:; script-src 'self' https: 'unsafe-inline' 'unsafe-eval'"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Note: Some of these headers (like CSP) may require tuning for your site’s JS/CSS structure. Test thoroughly!
Results: Numbers Don’t Lie
After applying the above, ENGINYRING.com’s GTMetrix results improved dramatically:
- Performance Score: 94% (up from 70%)
- Structure: 95%
- LCP: 1.3 seconds (down from 6.5s)
- Total Blocking Time: 23ms (down from 280ms)
- Cumulative Layout Shift: 0 (perfect)
- Total Page Size: 1.73MB (25% reduction)
Mobile performance saw even bigger gains:
- Mobile Performance: 86% (up from 45%)
- Mobile LCP: 2.1 seconds (down from 8.2s)
- Cumulative Layout Shift: 0
Lessons for Other Apache2 Users
- Don’t accept defaults: Apache’s out-of-the-box configuration is built for compatibility, not speed. Modernize it—starting with Event MPM and PHP-FPM.
- Use advanced compression: Brotli (with fallback) offers huge real-world gains, especially on large JS/CSS bundles.
- Automate optimization: The Google PageSpeed module can replace a host of external asset pipeline tools.
- Separate static and dynamic: A CDN subdomain strategy is a simple, high-leverage move—even if you’re not using a third-party CDN.
- Measure, don’t guess: Track all changes with tools like GTMetrix, WebPageTest, and Google PageSpeed Insights. What helps one site may not help another.
The Bottom Line
The ENGINYRING.com case study (read the original here) proves that Apache2 is far from obsolete. With a thoughtful, holistic approach, Apache2 can match or exceed the performance of its more fashionable competitors—no external proxies, no LiteSpeed migration, and no magic tricks required.
For those running critical sites on Apache2, this optimization journey is both a playbook and an inspiration. It’s also a reminder that with enough persistence and the right tools, “legacy” doesn’t mean “slow.”
Further reading and original technical deep dive:
ENGINYRING.com – From 70% to 94%: How We Turbocharged Apache2 Without External Solutions
Comentarii
Trimiteți un comentariu