WordPress Speed Optimization Report for http://americanlookout.com/
Since the site is on and now optimally configured with CloudFlare, any performance variance between one location and another is statistically insignificant and/or is entirely dependent on network speeds (which we cannot affect). In short, the results (i.e. the “After”) in this report are identical or quite nearly identical when compared against the results one would get with any location within range of any of CloudFlare’s network servers.
All before-and-after-metrics given illustrate an average user experience on a cable connection (5/1 Mbps 28 ms RTT). This is the ideal ‘middle ground’ and effectively illustrates the mean experience that a visitor to the site had and now has as a result of our work.
Before & After Video (After is on the Left):
Actual video of what visitors to the site experienced prior to our work and what they now experience as a result of it. This video capture represents the mean experience.
About Metrics: Some Matter More Than Others. A LOT More.
When most people refer to the loading of their website, the number usually cited is the total load time; or, more technically, their site’s “Time to Onload” which is the prominent metric provided by such online tools as Gtmetrix and Pingdom. This number is actually almost worthless, at least relative to other, far more meaningful metrics. For example, your users couldn’t care less whether your site’s analytics takes 1 second or 20 seconds to load — it has no bearing on UX (User Experience), SEO, or anything that enters the orbit of these things. And yet, the time it takes for your site’s analytics to load is, by definition of Time to Onload, included in the Time to Onload metric.
The metrics that matter the most are those that contribute to, A.) the speed with which content begins to appear on the page; and, B.) the speed with which that content can be interacted with. As such, do take note, below, of the dramatic improvements to the User-Experience-Centered performance metrics that contribute to the progressive rendering of above the fold content. These metrics include:
- *Start Render Time
- *First Paint
- *The Site’s Speed Index
Performance Metric Improvements (Medians)
*TTFB (Time to First Byte/Server Response Time) Was:
*Start Render Time (Content Begins to Get Painted On the Page) Was:
*Real User First Paint (Content Begins to Get painted On the Page As Reported by the Browser Itself) Was:
3.211s – 3.323s (0.112s)
*domInteractive (the time at which a user can interact with the page, click a link for example) Was:
Total Number of Requests At the Time of Document Completion Was:
280 (mostly external, 3rd-party resources like ads and tracking pixels. This metric will always be highly variable so long as the site uses so many ads).
*Speed Index (See Chart Below) Was:
*TTFB (Time to First Byte/Server Response Time) Is Now:
*Start Render Time (Content Begins to Get Painted On the Page) Is Now:
*Real User First Paint (Content Begins to Get painted On the Page As Reported by the Browser Itself) Is Now:
*domContentLoaded Is Now:
2.185s – 2.257s (0.072s)
*domInteractive (the time at which a user can interact with the page, click a link for example) Is Now:
Total Number of Requests At the Time of Document Completion Is Now:
263 (mostly external, 3rd-party resources like ads and tracking pixels. This metric will always be highly variable so long as the site uses so many ads).
*Speed Index (See Chart Below) Is Now:
Visual Progress, Timings, Requests, & Size (In Bytes) Before and After:
How We Did It
- All possible best practices implemented.
- Optimally minified and concatenated CSS.
- Inlined critical, above-the-fold CSS.
- Minified HTML.
- Eliminated all render blocking resources that can be eliminated (any that reamin must for the site to function properly; or, would not make any real-world performance difference if eliminated).
- Optimized page-to-page navigation and rendering times.
- Optimized Browser Caching.
- Optimized parallel downloading of resources.
- Optimal CloudFlare configuration: everything under the “Speed”, “Page Rules” and “Caching” tabs is configured or optimal performance.
- Developed and implemented custom made mini-plugins to tie the new performance optimization architecture together and test the new performance architecture in the live environment. These mini-plugins can be seen by clicking on “Snippets” in the WP Admin sidebar menu. Not all are active, none should be deleted.
- Assorted other this n’ that tweaks.
- After testing several hundred configuration permutations your site (everything served locally, i.e. from your site’s server) is now as fast as it can possibly be with the site in it’s current build iteration and hosting environment.
- Old versions of the site may still be stored on your in your browser’s cache. So, please clear your browser’s cache including cookies before viewing the site, otherwise you may not be able to immediately see the improvements made. An “Incognito” window in Chrome or a “Private” window in Firefox will work too.
- The performance optimization architecture we have implemented is designed to be self-maintaining and self-evolving. So, things like WordPress and plugin updates should go smoothly and handle themselves for the foreseeable future.
SPEED. YOU GOT SOME!
The entire Viral Media Partners Team