Content Builds > Content Entry
After listening to Vox Media’s take on performance during Ethan Marcotte and Karen McGrane’s stellar Responsive Web Design podcast, one specific point stuck in my head…
“So, what we’ve found over this time, and one of the original directives of the performance team was we weren’t going to set ourselves up to be performance cops, we weren’t going to go around slapping people on the wrist, saying, “You built an article that broke the page size budget! You have to take that down or change that immediately!” Our goal setting out was to set up best practices basically, like the budget, make recommendations, be a resource within the company that people can turn to when they have to make performance-related decisions.”
In this passage, Dan says his editorial team builds articles. That syntax shift struck me as a game changer. If you’re not familiar with Vox, it’s a gorgeous, smart repository of articles and other content that’s well organized and updated constantly. Think about a prettier, smarter Buzzfeed that actually has info you want to read and you have Vox. They feature lots of written and design bits on each post, which is one reason that performance is important to them.
Here’s why you should care about “building content” instead of “entering content”:
In a typical engagement, we build a skeleton site filled with templates and perhaps 15% of the content (content is words, images, headlines, graphics, etc.) needed for the full, finished site, then hand it over to our capable clients to populate with the rest of their smart words, images, and videos (using guidelines, of course).
In the past, we’ve talked about this as the content entry phase. That’s an accurate phrase. It’s technically correct. The client literally enters their content into the CMS. No harm in that, right?
TURNS OUT THERE’S A LOT OF HARM.
The term “content entry” undervalues the thinking that goes into creating pages. It also sounds dangerously close to data entry, and therefore, like a prime candidate for delegation to well-meaning interns. And that’s precisely why we’ve seen sites that tested well in QA that launch with 11-second homepage load times. Sidenote: 47% of online users expect web pages to load in two seconds or less. So, inspired by Dan, we’ve started experimenting with calling it the content build phase.
We’ve found this syntax change to be transformative in terms of how our clients view this work. Building, rather than entering, sounds like a task that requires skill and time. Building means stacking components with care and strategy and then assessing how they restack across different devices. If you’ve ever tried to create a visually-pleasing web page while observing a strict performance budget, you know that it requires skill.
THE 80/20 RULE
When we train our clients on their sites, we talk about performance according to the 80/20 rule. Addressing top offenders like uncompressed images and HTML, number of HTTP requests, and wild tangles of CSS will solve 80% of the performance issues in a typical site.
There are additional trade-offs, tricks, and workarounds that will help in this work, but they need to be devised and applied judiciously, with a healthy appetite for experimentation. That takes time and stick-to-itiveness.
Syntax aside, content builders (doesn’t that sound better and more meaningful?) often have a long list of dozens or hundreds of pages to create. Checking page budgets on top of writing and conscientious SEO work is a lot to ask. That said, page speed directly affects a site’s Google quality score, so the work is very interdependent. It’s not an easy job and it requires time.
By calling it a content build phase, our clients have been more successful in convincing their non-digital managers that this phase requires an adequate amount of time and full attention.
We’re all about UX, and if a simple syntax change like “content build” can improve the user experience of a site by helping clients prioritize attention to detail, it’s worth it to everyone.
Progress. Thanks, Dan!