Wrap-up and Demo
We've now explored various ways to improve page load time. These techniques are "low-hanging fruit" -- simple efforts that produce big performance wins. But talk is cheap; we have not yet actually seen the techniques in action, so finish up by doing that.
To demonstrate the techniques' effectiveness, we will run various speed tests on different versions of a web page, beginning with no optimization and progressing through some of the speed-up techniques we've discussed, specifically text resource optimization, graphics resource optimization, and HTTP request reduction.
The original target is a simple, single HTML page with text, images, CSS, and JavaScript, hosted on Firebase here: https://page-load-speed-demo.firebaseapp.com/pageload0.html. Have a quick look at that, and then we can start improving it.
Note: The source code for all versions of the demo page referenced in this document can be found in this GitHub repository.
One of the prime considerations in page speed is First Meaningful Paint (FMP), a measure of how users perceive page performance. FMP refers to the time it takes for a page's primary content to appear on the screen. The definition of "primary content" may, of course, differ depending on the page type. For a news article, the primary content might be the headline and the text "above the fold"; for a search engine page, the primary content would be its search results; for an art museum page, the primary content might be a series of thumbnail images and short descriptions.
Another major factor is raw load speed, a measure of how long it takes from the first downloaded byte until the page is completely loaded. Although this is an empirical observation, it may not accurately reflect the user's perception of usable content. That is, viewable content may be on-screen and perceived as usable long before the page load is technically complete.
Clearly, the perception of "page load speed", as opposed to its literal measurement, is a somewhat subjective aspect of the user experience, and is affected by many factors. Perceived performance is a prime indicator of page load speed and, by extension, user satisfaction. While completely objective measurement may ultimately be impossible, that doesn't mean we just guess.
Testing Tools #
There are many, many tools available to help determine a page's load speed, far too many to list here. For this article, we will use three online services to help us see the results of our improvement efforts.
Why three tools? Because different testing services use different methods and algorithms to test speed; they run their tests on different machines and browsers from different locations; they report different results, and report them in different ways. You may find it disconcerting that the same page can test quite differently across tools, but that is the reality of testing.
Rather than perceiving this as a negative, think of it as simply a way to get more and better data. No single testing tool gives you the whole story. Instead of relying on one tool, use multiple tools and run the tests multiple times to get the best and most information you can about specific focus points of your page, and then adjust accordingly.
The Original Page #
Let's get a baseline by looking at various performance audits on the original page. It is admittedly quite sloppy -- raw text, render blockers, large images, too many external files -- but it ultimately loads and displays as it should. Our job is to use available tools to identify some specific things we can improve based on what we've seen in the preceding articles. Here's part of the page.

Let's run it through the testing services.
Note: You may run this same page through the same services and get different results. Again, that's the reality of testing.
PageSpeed Insights scores the page poorly, providing separate ratings at 48/100 for mobile devices and 50/100 for desktop devices, but does not give us a raw load time. Among its observations, it correctly notes that the page's HTML, CSS, and JavaScript are not minified.

Pingdom gives the page a "B" rating and an 81/100 score, which doesn't sound that bad. But, more helpfully, it reports a sub-par 4.73 second load time, and ranks the page among other sites it has tested, placing it in only the 33rd percentile.

WebPageTest by default runs three consecutive tests and averages the results, a unique feature among test services. Its results include a Document Complete load time of 2.743 seconds and total load time of 2.831 seconds, both significantly less than Pingdom's report.

WebPageTest also includes a number of graphical reports, including filmstrip and video views (both very nice), and these handy content breakdown pie charts.

As you can see, the original page's load characteristics aren't very good. It should also be immediately apparent that its characteristics aren't measured and reported identically by the various tools. The best approach, then, is to focus on a few major improvement avenues, and retest after each change to determine whether it achieved the desired effect.
Text Content #
Our demo page largely consists of text-based resources: the main HTML page content and structure plus one or more Cascading Style Sheet and JavaScript files. That text may not be the page's major hangup, but it is a place to start, as it can all be minified to save download time.
Using some of the tools mentioned in the Text Content article, we minified the HTML, CSS, and JavaScript and redeployed the site to the server.
PageSpeed Insights delivered a modest, but interesting, report, correctly noting that the modified page's HTML, CSS, and JavaScript are minified.

Both the mobile and desktop scores improved by just 1% (49 and 52 respectively), indicating that minification had only a small effect. But in fact, minifying the text resources resulted in a 32% reduction in actual character count. Because this is a fairly small page, the resulting speed improvement isn't large, but the percentage of size reduction is very significant.
As before, there are no raw speed numbers, but even this report demonstrates that removing whitespace speeds up your page.
Pingdom's overall grade didn't change, but the page's load time dropped by 1.3 seconds, and its percentile ranking jumped to 47.

The load time improvement is more obvious here than in the PageSpeed Insights report, and a speed-up of over a second is certainly a worthwhile result for very little effort.
WebPageTest interestingly reports no significant change in either Document Complete or total load time.

However, a bit of hovering over the (tiny) pie slices in the content breakdown charts shows significant reductions in the character counts and relative proportions of the text components: HTML (previously 11,886/0.9%, now 9,237/0.7%), CSS (previously 4,443/0.4%, now 3,295/0.3%), and JavaScript (previously 14,471/1.2%, now 8,060/0.6%). The individual numbers seem small, but that fact is that minification delivered an overall reduction in text resources of nearly one-third.

Interestingly, despite the lack of an overall raw speed increase, WebPageTest's report shows that two of its internal algorithm results go in different directions. The page's Speed Index went up from 1699 to 1797 (about 5% slower), and its First Interactive time (a beta feature) went down from 1.266 seconds to 1.133 seconds (about 10% faster). While those measurements are somewhat subjective, they nevertheless affect how fast the user perceives the site to be. And always remember that user perception is the ultimate arbiter of performance.
Update: The "Time to First Interactive" metric is on the path to deprecation in favor of the more accurate "Time to Consistently Interactive". We encourage you to use the WebPageTest Easy mode and select the Mobile checkbox, which will generate a Lighthouse report. Then click the Lighthouse PWA Score at the top of the page to see the full Lighthouse Progressive Web App report, including the new Consistently Interactive metric.
Here is the text-minified version: https://page-load-speed-demo.firebaseapp.com/pageload1.html.
Graphical Content #
Another area ripe for improvement in this page is its over/misuse of graphics. This is not to say that the images aren't important to the page, just that they could be handled better. Have another look at the WebPageTest pie charts just above; the page's images comprise 53.3% of the HTTP requests and 98.3% of the downloaded bytes.
There are eight images in the original page: the five main article pictures, the vintage Luckies advertisement, and the opening and closing quote graphics around the pull quote. One of Pingdom's additional charts illustrates the time spent waiting for and downloading the images.

There is a lot of room for improvement here.
Based on the techniques discussed in the Graphical Content article, we applied various improvements to the images (even the small ones), including:
- physical resizing,
- establishing best format,
- reducing quality,
- compression, and
- removing metadata.
Note: For this and all subsequent tests in this article, we always started with the original, unmodified page, and made new copies of all resources in order to prevent any one test's procedures or results from contaminating another test.
Here are the results of the improvements for each image.