Website speed in 2014: PageSpeed, images, hosting and CDNs

Two free tools, used together, tell you what you need to know.

Google PageSpeed Insights gives a score out of 100 for mobile and desktop plus a prioritized list of fixes. Since last year it also reports on the mobile user experience: tap target size, viewport configuration, legible font sizes. The score is a grade against a checklist, not a stopwatch. A page can score 90 and still load slowly if the server is slow.

WebPagetest gives you the stopwatch. Run from a US location in Chrome, three runs, first and repeat view. Read three numbers: time to first byte (server speed), start render (when the visitor sees something), and fully loaded. Then look at the waterfall chart, which shows every request in order. Most speed problems are visible in the waterfall within a minute.

Record the results for your home page, your most important landing page and a typical product or service page. That is your baseline.

On most business sites images are 60 to 70 percent of page weight and the fastest thing to fix.

1. Resize to the display size. A 4,000-pixel photo from the camera scaled down by the browser to 800 pixels is still a 2 MB download. Export at the size it is shown, at most twice that for high-density screens.
2. Choose the format properly. JPEG for photographs at 70 to 80 quality; PNG for logos, icons and anything with transparency; GIF only for simple animation. WebP is smaller still but only Chrome and Opera display it, so it requires serving different formats to different browsers and is not worth the complexity for most sites yet.
3. Compress losslessly. Tools like ImageOptim, JPEGmini, Kraken.io and the WP Smush.it plugin for WordPress strip metadata and recompress without visible loss, typically saving 20 to 50 percent.
4. Combine small icons into a sprite or replace them with an icon font or inline SVG, cutting dozens of requests to one.
5. Load below-the-fold images lazily. Several JavaScript libraries and WordPress plugins defer images until the visitor scrolls near them.
6. Set long cache headers on image directories so repeat visitors do not download them again.

Doing the first three alone often halves page weight.

Time to first byte above 500 milliseconds means the server is slow before a single image is requested, and no front-end work fixes that.

For a content-managed site on shared hosting, the single biggest improvement is usually a move to managed hosting or a properly configured VPS, plus page caching. WordPress sites should run a caching plugin (W3 Total Cache or WP Super Cache) regardless of host, so that each page is built once and served as a static file until something changes. Dynamic e-commerce platforms such as Magento need server-side caching (Varnish, Redis or Memcached) and enough memory; Magento on $10 shared hosting is a common cause of ten-second pages.

A content delivery network serves your images, scripts and stylesheets from servers near the visitor instead of from your host. For a site with visitors across the US or overseas, that cuts hundreds of milliseconds from every asset. It also takes load off the origin server.

Realistic options this year: CloudFlare has a free plan that sits in front of the whole site, with paid plans from $20 a month that add more optimization; MaxCDN starts around $9 a month for a pull zone; Amazon CloudFront charges by usage, typically a few dollars a month for a small business site; Akamai and similar enterprise networks are priced for enterprises. WordPress sites can integrate any of them through the caching plugin in under an hour.

One caution: a CDN does not fix slow page generation. If first byte is two seconds, the HTML still takes two seconds.

After images and hosting, the remaining time usually goes to scripts and styles.

• Minify and combine CSS and JavaScript. Fewer, smaller files. Most CMS caching plugins and build tools do this automatically.
• Move render-blocking JavaScript to the bottom of the page or load it asynchronously. PageSpeed Insights now flags this specifically, and it is the most common reason for a low mobile score on an otherwise reasonable site.
• Audit third-party tags. Each social button, chat widget, heat-map tool, remarketing pixel and A/B testing script adds requests, and several of them block rendering. Remove what is not used; load the rest through Google Tag Manager asynchronously.
• Enable gzip compression on the server. It is a one-line configuration change that typically cuts HTML, CSS and JavaScript size by 70 percent, and a surprising number of sites still do not have it on.
• Limit web fonts. Two families, two or three weights. Each weight is a download, and a page that waits for five font files shows blank text on slow connections.

A focused speed project on an existing site, without a redesign, typically moves a four-to-eight-second page to two-to-four seconds and lifts the PageSpeed mobile score by 20 to 30 points. Cost ranges from a few hundred dollars for image compression and caching setup on a small WordPress site to several thousand for an e-commerce platform that needs server-side caching, a CDN and a front-end cleanup. Hosting and CDN add $20 to $300 a month depending on scale.

The business case is straightforward: retail studies consistently find that each second of delay costs measurable conversion, and on a site turning over $500,000 a year online, a modest lift pays for the work many times over.

Chasing the score instead of the time. A score of 95 on a page that takes four seconds to first byte helps nobody.

Optimizing the home page only. Visitors from search land on inside pages. Measure and fix those.

Installing three optimization plugins. They conflict, cache each other's output and break the checkout. One caching plugin, configured properly.

Breaking things silently. Combining scripts in the wrong order breaks forms and trackers. Test the contact form, the cart and the analytics tag after every change.

Speed work is part of how we build and maintain websites rather than a separate service. In discover we baseline the key pages in PageSpeed Insights and WebPagetest, review hosting and server configuration, and inventory every third-party tag and plugin. In plan we order the fixes by impact against effort, which almost always means images and caching first, hosting second, front-end cleanup third, and set a target load time and score for each page type. In build our web and infrastructure team makes the changes in a staging environment, tests forms, checkout and tracking after each step, and moves hosting or adds a CDN where the numbers justify it. In improve we re-measure, set up monitoring so regressions are caught, and feed the results into the conversion and campaign work.

Having brand, growth, web and technology under one roof means the speed work accounts for the remarketing tags the growth team needs, the fonts the brand guidelines specify and the server the infrastructure team manages, instead of each one undoing the other.

A representative engagement was a retailer whose product pages loaded in more than seven seconds on desktop and scored in the 40s on PageSpeed mobile. The work began with a baseline and a waterfall review that showed oversized product photography, no page caching and a shared server struggling under modest traffic. We compressed and resized the catalog images, moved the site to a managed cloud environment with server-side caching, put a CDN in front of the assets, and cut the third-party tags by half. Product pages dropped under three seconds, the mobile score rose into the 70s, and mobile conversion improved in the following quarter. You can read more about that kind of work in our infrastructure case study.