Speed builds audience, sloth loses them

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.

The problem is most apparent in the list of articles, where large original-size photos are squeezed into small thumbnails. For 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

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

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.