Speed builds audience, sloth loses them

Print More
WebpageTest filmstrip of KQED page loading

WebpageTest filmstrip of KQED page loading.

Delivering great content is the best way to build audience, on air and on the web. But just as a broadcast needs a strong transmitter signal, a website needs fast-loading pages.

Page speed is especially critical for public media sites, which, along with the text and images all sites provide, must also seamlessly stream large audio and video files.

On the air, broadcasters compete mainly in their markets and their media. Online, however, stations are up against the entire World Wide Web of media sites. To be competitive and to boost its online revenue, engagement and audience, a pubmedia website must load quickly.“The single most consistent finding, across the entire web traffic literature, is that faster load times lead to higher traffic,” wrote Matthew Hindman in a 2015 study for Harvard’s Shorenstein Center. “Even tiny user delays, on the order of 100 milliseconds, have been shown to reduce traffic.”

The BBC prioritizes web performance. Matthew Clark, their lead technical architect, found “that for every additional second a page takes to load, 10 percent of users leave.” When the Financial Times tested its speedier new site last fall, its “users were up to 30 percent more ‘engaged.’”

Google and Facebook use data from trillions of web visits to advise publishers on the benefits of speedy sites. “Reading news is slow,” said Facebook’s Mark Zuckerberg, in a 2015 Facebook Townhall Q & A. “A lot of people abandon news before it has loaded.” Google links faster page speed with increased ad revenue, better search results and lower bounce rates. A September 2016 Google DoubleClick study found “53 percent of mobile site visits are abandoned if pages take longer than 3 seconds to load.”

A couple decades of web research have paved the path toward making sites faster. Step one is learning to use web testing tools. Step two is using those test results to follow basic best web practices.

Knowing the numbers

To display a web page, a web server requests a variety of files: images, HTML, JavaScripts and CSS stylesheets. The number of requests and total size of all those requests, known as “page-weight,” are the main factors determining page-load times.

Two tools make it easy to find web performance problems:

  1. WebPagetest returns a comprehensive set of load time metrics, with charts showing any bottlenecks.
  2. Google PageSpeed Insights analyzes your web page, then offers best practices for improving load times.

I tested home pages of 25 pubmedia websites, selected to be a representative sampling of stations: large. small, rural, urban, radio and TV.

The station sites took an average of 8.6 seconds to load. That’s close to half the 16.7-second average I measured in 2015 for all U.S. daily newspapers, but nearly double the 4.6-second average for the top 100 newspapers in the world, as measured by Pingdom last December. Almost all the pubmedia sites tested suffered from two common and easily fixed site-slowing problems: overweight images and poorly placed scripts.

Overweight images

KQED.org is a good example of how bloated images make a site sluggish. Images account for 91 percent of its page weight, 8.9 MB of 9.7 MB, according to the WebPagetest content breakdown. A Google PageSpeed analysis showed their images would be 95 percent smaller, 0.4 MB, and load 95 percent faster had they been optimized — that is, both compressed in file size and scaled to display size.

Google PageSpeed results for KQED.org: Optimize Images list

Google PageSpeed results for KQED.org

The problem is most apparent in the list of articles, where large original-size photos are squeezed into small thumbnails. KQED.org screenshot with pig photo thumbnailFor instance, the little piggy pictured in the screenshot on the right is 781 KB (2048 pixels wide). This one photo took 3 seconds to load. If compressed and scaled to its size on the page (300 pixels wide), it would be a svelte 16 KB, 98 percent smaller and 98 percent faster-loading. Many other thumbnails on the home page also took several seconds to load.

KQED’s head of digital product, Colleen Wilson, tells me their web team “saw we were woefully underperforming.” Their web team has since fixed many oversized images, reducing their load time from 19 seconds in March to 10 seconds this month. They are currently working on a major overhaul, “and site performance is a high priority for us.”

Photoshop and many other tools can quickly optimize images for web publication. It’s the easiest way to build a faster website. Make image optimization part of your graphics workflow.

Watch your waterfall

To find overweight images and other problem files, use a “waterfall”: an interactive chart of a web page that lists the file size and load time of each request. I made this video tutorial to demonstrate the waterfall feature built into the Chrome web browser:

Poorly placed scripts

Load JavaScript last

Google PageSpeed Insights warns you: “Eliminate render-blocking JavaScript in above-the-fold content.” Scripts must load completely before the browser can continuing rendering the rest of your web page. Move as many scripts as possible to the bottom of your HTML, so your visitors can view content while the scripts load.

Request less

In my previous studies, the metric that statistically correlates most closely with page speed was the number of requests. Analyze your waterfall, then talk with your team — editors, writers, marketers, web/media producers, designers and developers. Systematically go through your largest and slowest requests, remove those no longer needed and move any scripts you can from the HTML head section into the footer.

“Make speed a team sport” is the lesson NPR learned while making their site twice as fast. “Every member of the team was responsible for building a faster NPR.org.”

Be careful what you ask for

Check the WPO Stats website for case studies of how media sites boosted audience, revenue and engagement by speeding up their page loads.

A lot of advice for speeding up your site is available. Among the best is: Google’s “Optimizing Performance” and Yahoo’s “Best Practices for Speeding Up Your Web Site.”

You may hit a couple tech snags that prevent you from optimizing certain images and scripts. Some content management systems, including NPR’s Core Publisher and PBS’ Bento, limit customizations, as do most online advertising technologies (which are notoriously slow and insecure). But you and your team can make most of the changes needed to radically reduce page load times.

Pubmedia performance

WebPagetest results for Current.org

The table below lists test data for the home pages of 25 pubmedia stations, their WebPagetest-measured load times, total requests and page-weight (lower is better), along with their Alexa ranks and Google PageSpeed scores (higher is better). I chose from sites that regularly update daily news and programs and have an Alexa U.S. rank under 1,000,000. Other than those criteria, the site selection was meant to be a representative sampling of stations’ size, media and content management systems.

WebPagetest and PageSpeed results

Station site Load time (sec.)Total requestsPage weight (MB)Alexa USA rankDesktop score
(0-100)
Mobile score
(0-100)
Secure site Site secure (lock icon)
Not secure Site not secure
WebPagetest results link:

PageSpeed link:
Should fix
Consider fixing
NWPR.orgSite not secure
3.6
70
1.7
250,836
41
37
KMXT.orgSite not secure
5.0
124
1.5
318,921
67
55
KERA.orgSite not secure
5.0
139
1.6
44,193
63
52
KBIA.orgSite not secure
5.1
70
2.3
135,739
45
35
WGBH.orgSecure site
5.1
173
1.7
9,512
43
34
KVCR.orgSite secure
5.7
92
2.4
464,152
36
26
CPR.orgSite not secure
6.2
77
1.7
24,850
69
55
KAWC.orgSite not secure
6.3
72
3.2
604,733
27
31
SCETV.orgSite not secure
7.0
72
3.5
86,612
38
24
YPradio.orgSite not secure
7.2
71
1.6
305,118
36
32
iJPR.orgSite not secure
7.3
98
3.0
139,683
32
35
OPB.orgSite not secure
7.4
164
3.4
12,608
31
26
KUOW.orgSite not secure
7.6
113
2.6
14,224
38
33
KPFK.orgSite not secure
7.8
107
2.3
66,789
63
66
KCAW.orgSite secure
7.9
98
3.7
533,667
38
29
KYUK.orgSite not secure
8.9
62
4.8
349,740
16
11
CapRadio.orgSite not secure
9.5
137
4.5
32,517
31
37
WNYC.orgSite not secure
10.1
137
4.6
4,187
56
46
KRCB.orgSite not secure
10.2
114
4.6
736,026
20
17
Ideastream.orgSite not secure
10.3
108
2.0
42,932
64
50
WVpublic.orgSite not secure
10.6
104
5.6
60,444
28
47
KCPT.orgSite not secure
11.6
179
5.3
162,510
42
43
KBUT.orgSite secure
14.1
155
4.7
799,399
22
30
KCET.orgSite not secure
15.5
170
7.8
18,301
30
23
KQED.orgSecure site
19.1
141
9.7
2,985
3
0

Barrett Golding produces audio and develops websites. He was Executive Producer of Hearing Voices from NPR, a Peabody Award-winning weekly radio hour. He contributes to the WordPress.org Documentation and Accessibility teams. He worked in 2015–16 as a Fellow at the Reynolds Journalism Institute. In 2010 United States Artists named him a Media Fellow.