Episode 02

Headshot of Mark Dorison

with Mark Dorison of Chromatic

This week, Tim talks about performance budgets, and shares how he sets up a performance budget for the sites he works on. We also speak with Mark Dorrison of Chromatic about how he focuses on performance at a technical level, how to talk performance with your clients, how to sell performance to clients that aren’t familiar with how important it really is, and more.

Direct Download

Transcript:

Katie Kovalcin:

Welcome! You’re listening to episode two of the Path to Performance, a podcast for everyone dedicated to making websites faster. I’m your host, Katie Kovalcin.

Tim Kadlec:

And I am Tim Kadlec. Today, we’re going to be talking to Mark Dorison of Chromatic.

Katie:

It will be really interesting to hear the agency-side perspective of getting performance on track and into cultures. I’m really excited for it.

Tim:

Yeah, it will be a nice contrast. Lara’s was excellent on the in-house perspective. It will be really interesting to get somebody on the other side of the coin.

Katie:

As always, if you want to reach out to us about either being a guest or sharing some tidbit or being a sponsor, you can email us at hello@pathtoperf.com. And we also made a Slack group now for people to talk about web performance. You can self sign-up at webperformance.herokuapp.com and it will send you an email invite so you don’t need to worry about asking to be added to all of that stuff. We have a lot of really awesome conversations going on in there, so we’d love to talk to you.

Tim:

That’s been fun. That was a great idea, Katie. People kind of hit the ground running, too. Right away it was people jumping in and immediately asking all sorts of great questions and having some really awesome discussions between people. It’s been fantastic. I like to just eavesdrop sometimes and just see how everything’s going, just sort of be a lurker.

Katie:

Yeah, I’ve just been kind of keeping tabs on what links people are sharing and I’m like, “Oh, I haven’t heard of this. I’ll read that later,” and a lot of good stuff. One of the things that was brought up in Slack several times, and also both Tim and I have been asked this question a bunch, is a lot about performance budgets. Tim, do you want to talk a little bit to what a performance budget is? You have a bunch of articles around that.

Tim:

Yeah, I’ve written a few things on it. It does seem to come up a lot in Slack, and I know at the end of our talks and stuff we get this a lot. The performance budget idea is fairly simple. You’re setting a target for performance for your site, and then you are making sure that you hit that target, that budget. Just like if you have a budget financially for your family, you want to make sure that you’re not spending more than $250 on food a month, you’d want to make sure that you stay under that. It’s the same thing with a performance budget, except now instead of money you’re talking about things like load time, or Speed Index, or weight, or whatever it happens to be.

Katie:

And it’s cool because you can shift those numbers around, so it’s not like, “I just have this money to spend on this thing and that covers everything.” You can kind of give and take from around the page, so that’s really useful for design when trying to prioritize things and maybe taking some of the budget from different aspects of the page and putting it somewhere else if something is really heavy. It’s pretty useful. A lot of people want to know, “What number should I start with? What is this goal number, this magical number to set the performance budget within?” Tim, do you have any thoughts on that?

Tim:

It’s five. [Laughs] Yeah, no, actually that question comes up a lot. I’ve got two standard answers, and the first I think is from Paul Irish, who said, “a Speed Index of 1000” is what you should be going after, which is an awesome, awesome goal. Speed Index is basically a number that represents the visual progress of how your site loads, so it’s a really good indicator of perceived performance. A 1000 Seed Index, if you hit that, that’s pretty snappy, it’s a great-feeling site. I love that as the gold standard, like everybody should be going at that number or under. I do think that it’s not necessarily the best route for everybody right out of the box.

It’s kind of like… So, I don’t exercise, right? I don’t run because I’m lazy. But one time I tried to. I was like, “You know what? I’m going to get in shape because I want to not be winded one game into my two hours of basketball in the morning.” So I got up and I was going to go for a run. My wife is much smarter than I am. She told me that I should ease into it, don’t run too hard, do some walking and running. I’m like, “Pfft, I want to run. People are going to be laughing at me.” So I decided I was going to go out and run, and I used to run in high school quite a bit, so I figured I’d just keep going around the same distance or duration. So I did it, and I died. I was sore for like five days and I didn’t run for at least a month after that.

Anyway, bringing this back to performance. Instead of going all out right away… By doing that, I actually hurt myself and I killed my momentum and it was a really negative experience. But easing into it and building up to it lets you build the momentum and build the enthusiasm. I think it’s the same way with performance. If you’re just starting out with this stuff, sometimes it makes a lot more sense to have a much more conservative target and ease into it, and start getting used to achieving those smaller performance wins.

There’s the 20% rule, which is if something is 20% faster than something else, that’s when people start noticing it’s faster. So, be 20% faster than your current site, or 20% faster than your competition. And then hit that target, and then beat that target again. If you build up, I think it’s a lot more sustainable than if you go out right away and decide you’re going to go after the 1000 Speed Index. When your culture has never really focused on performance in the past, I think that can actually be a negative thing.

Katie:

Yeah, because you don’t want people to lose momentum or get frustrated, or the designer being like, “You set this goal and now I don’t know what to design without using all of these things, or what design decisions to make.” And then your client is like, “Well, you didn’t do the thing you said you were going to do.” Yeah, I think it really helps, from my perspective working with clients, to set these realistic goals. I also think, when working with clients and with a lot of non-technical team members, that the page weight number is the easiest for people to get behind and understand, and it’s not quite as abstract as the load times being in seconds. So, clients can kind of understand, “There is this number that we can very easily add or subtract from.” I think it’s an easier conversation tool to use page weight.

Another alternative to the 20% rule would be indexing where competitor sites are at for a client, and seeing how much their competitors weigh, where they’re currently at, and then maybe setting the goal 20% faster than the competitors, which is still realistic when there’s all that marketing baggage that they may have. A lot of clients will never be a super, super fast site, at least not immediately because they have so many large images or things like that. This will be really interesting to talk to Mark about and to get his perspective on it and what they’re doing agency-side. But I think setting the realistic number, specifically for your client as well, will go a long way.

Tim:

Yeah, absolutely. And you’re right on the weight thing too, because that’s another question—I’m sure you get that, like, “What stat should your budget be?”

Katie:

And then whenever I say, “Oh, I try to focus on page weight for the budget,” then they’re like, “Well, what about the seconds?” We’re not saying they’re not important, but the conversation tool for the PM to understand, for the designers to understand, for the client to understand, I think page weight is the easiest place to start.

Tim:

Yeah, I totally agree. I wrote a short post on this because I had the question so many times. It was nice to be able to just refer people to that. But I think each metric serves its own purpose and, like you said, weight is awesome for exactly what you said—it’s a really tangible thing, it’s really easy for people to understand the consequences of adding another image or another script when they’re looking at the weight budget. I think something a little bit more closely tied to the experience, like Speed Index, is fantastic because that’s probably where your budget should start. But then you derive a weight budget or something off of that so that they relate to each other. But Speed Index, for as awesome as it is, it’s a very hard thing to communicate to people. Like, “What the heck is a Speed Index?” So, breaking it down to weight is super helpful.

Katie:

So Tim, you’re kind of like the performance budget guy, so while I have your attention, can you just straight up here, for research purposes, walk us through how you set a performance budget, to kind of set the record straight? You get a project and you’re about to set the performance budget. What steps do you take? I know that a lot of that will depend, but. A mythical client.

Tim:

A mythical client? Okay. We can do this. We can do this. So, basically it starts off as the mythical client comes through the door and we’re like, “Okay, we need to the site,” or “change the site,” or whatever it happens to be to be faster.

The first thing I do is exactly what you said. The competitors—I take the existing site and about ten competitors usually, depending on how many I can get my hands on, and I shove the URLs for these in a spreadsheet. There’s a spreadsheet that Andy Davies made that does WebPageTest bulk testing. If you have a WebPageTest API, it will automatically submit all the URLs in a spreadsheet for you and get the results back, so that’s how I do it to automate it. But I’ll shove their homepage in. Let’s say that you are a cooking site. I’ll pick a couple other key page templates, so like a recipe or maybe a category, and find the corresponding the pages on those competitor sites as well and then shove those into the spreadsheet. All of those tests get pushed through WebPageTest as a bulk test, so it comes back and it fills in all the metrics, like all the load times and all of that jazz, based on how those tests happened. I usually test once on a mobile connection and once on something like cable or DSL as well.

Then I just add another column that takes the 20% rule into consideration for all of those results. So, “What would be 20% faster for these competitors or this current site?” Out of that analysis—which is actually not that bad because everything is automated—you get your two numbers: you get what’s 20% faster than the current site, what’s 20% faster than your competition. Depending on where you’re at and how far the gap is, you kind of pick your target off of that. For example, if you’re significantly slower than all of your competition right now and you’re just tweaking it, you’re not doing a full redesign, then maybe it makes more sense to try and hit 20% off of your own site than competitors right away and build towards that. It just depends on the team and everything. That’s one of the big question marks, is which one of those metrics you choose, and that depends based on the project and the team.

But once that’s in place, then you make sure that you enforce it. I typically use something like grunt-perfbudget for the build process, which will automatically test the performance of the site against WebPageTest according to the budgets that came out of that spreadsheet, making sure that if anything is over budget, it doesn’t ever make it to live. I also back that up with a simple little script of some nav. timing API that’s displayed on every single page load as we’re working on the site, so that every single time we make a change to the HTML or CSS, we see right away if we’re over budget, it’s red, if we’re under budget, it’s green. We get that performance reminder on every single page load.

Then once you do go live, you have to back it up with some monitoring. So that’s something like either running your own instance of WebPageTest, or using something like SpeedCurve. SpeedCurve actually has the budget stuff built right into it now, so that’s another way. And you can get alerts on that, so when SpeedCurve does a test on your live site and finds out that you’re over budget for some reason, you can dig into it and then dig into the WebPageTest results of that test and find out, “Why was it over budget? What happened? What changed?” and take care of things there. So, it’s kind of a tiered approach.

Katie:

Awesome. So, there you go. That is how Tim Kadlec determines his performance budget. Another common thing: is that number before or after gzipping it?

Tim:

Oh, the weight? I say after gzip. Because it’s based on what’s coming over; it’s what’s going to impact the experience. If you’ve got the gzip enabled, which you should, you give yourself a little extra weight cushion, I guess.

Katie:

Anything else that you can think of that is a frequently asked performance budget question? Oh—I think a lot of people ask, “Do you set an overall page weight?” You mentioned different pages. Can you take budget from different pages that might be over budget? Are there different budgets for different pages?

Tim:

You can get as complex as you want on this. I’ve talked to people who have a mobile performance budget, they have a desktop performance budget, and they have different performance budgets for each key page type. But I’ve also worked on projects or talked to people where it’s like one or two performance budgets. It really just depends. Sometimes it makes sense to do it for different pages, for sure. If you have an article page that’s pretty lightweight but then you also serve up video on your site on another page, obviously that budget is going to be completely blown by your video news, the page is going to be significantly heavier. Or you have a really image heavy gallery page, things like that. They probably need their own budget because it’s going to be such a different experience from a stripped down text-only page.

You have to be careful with that because you don’t want to use that as a scapegoat either. Like, “Oh, we’re serving a big video, so we can give ourselves a ton more weight and Speed Index and all this other jazz on this page.” You still want a fast experience, but sometimes it does make sense to adjust it.

Katie:

Do you think of that as pulling budget from another page?

Tim:

Interesting. No, I don’t. I don’t think that that works as well because it’s not a cumulative thing necessarily, it’s how quickly that individual page is loading. Then you’re going to have a lot of people who are jumping right to that page. I just don’t think you can play that game, where you’re like, “Oh, we’re 200k over budget over here” or “500 Speed Index under budget over here. We can go 500 over.” Yeah, I don’t think so. Good question, though.

Katie:

Those are the ones off the top of my head that I get asked a lot. I don’t know about you.

Tim:

That covers the most common ones, yeah. Honestly, there’s no hard-set rule for, “This is how you do it.”

Katie:

Everyone wants a hard-set rule, though. [Laughs]

Tim:

I know they do. But at the end of the day, it’s whatever works for you. Whatever works as a tool that’s going to help guide your team so that everybody is paying attention to performance and that you’re making sure that it doesn’t get left to chance is probably the right process for you. As long as you can tie it back to your business metrics, make sure you’re continuing improving, and just keeping going and see how fast you can go.

Katie:

Awesome. Thanks for answering that. I feel like I was just interviewing you.

Tim:

[Laughs] Yeah, that’s great.

Katie:

I’m glad we got to cover that on the podcast. Just another place for us to document all of that stuff about performance budget. We are going to take a quick break and we will be back to talk to Mark Dorison of Chromatic.

Tim:

Perfect.

Katie:

And we’re here with Mark Dorison of Chromatic. Mark, can you tell us a little bit about your organization and your role there?

Mark Dorison:

Absolutely. So, Chromatic is a web agency. We focus extensively in the CMS space, a ton of work with Drupal. We’ve become experts in working with especially large publishers who have lots of content and customizing their experiences so that their editors can build great websites for users every single day, and building great experiences for those users as well.

Katie:

Cool. How does performance play into your workflow? We started talking because you told us some interesting stories about performance being the focus of a lot of that work. Can you give us a high level look at some of that?

Mark:

Performance is something we always look at on a technical level, of course. When we’re building a site, whether we’re doing tons of work on the editorial end or whether it’s on the front end that an end user is going to see in the browser at home, we’re of course paying close attention to the performance characteristics of the site. In addition to that, I think we’ve spent a lot of time at a higher level and much earlier on in the process making users who wouldn’t necessarily consider performance one of the objectives, trying to make them see the light or see why it should be important to them and why it’s not just something the developers handle on the last week of the project.

Katie:

That is music to our ears. How do you get people to see the light?

Mark:

Of course if you’re a developer or someone more on the technical end, we look at performance as something of like, “Well of course we want to do this,” and then, “How can we convince everyone else to get on board with that process?” But what I learned earlier on—and not so early, I was going through processes many times where I was frustrated by not being able to get people to prioritize performance or buy in on spending time in that area. What I really learned is what we have to do is incentivize it for them and teach them about why it’s important. It depends on the person. If you’re talking to a marketer, if you’re talking to an executive, if you’re talking to an ad sales person, each one of those people is going to have different objectives for their job and they’re not going to care about the same thing, whether it’s metrics or statistics. So, it’s really tailoring that and selling them in a way to say, “Here’s how this will affect what is important to you.”

I think everyone on this podcast would agree—and if you’re listening, I’m sure you would agree—that performance comes in at every stage. So, it’s really not much of a hard sell from our perspective to figure out, “Okay, well this person is an ad sales person. They care about specific metrics related to time on the site or how many impressions, or all of these things. How is improved performance going to affect those things?” As opposed to an executive, who might be very focused on how the performance compares to other sites in the same category or something like that. Everyone is going to have a slightly different viewpoint on what’s important to them. If we start just diving right to the numbers and the statistics, their eyes will glaze over and they’ll be like, “Okay, yeah, do your developer thing and have fun.” But how do we really get them to be like, “Yeah, this is something we really need to prioritize through the entire project.”

Tim:

So, you’ve got those metrics that you’ve identified are important to the people. How do you present that data to them? Are you relying on external case studies? Are you doing little experiments within your organization and then presenting that to them in that way?

Mark:

It’s a little of both. I think that there’s always great resources out there, whatever is of the moment as far as performance characteristics, and it’s great whenever there’s an existing site of some kind that can be benchmarked. We rely a lot on prototypes too, especially as we’re getting into the early stages of the project, and this is important to us for many other reasons as well, but to be able to say, “Here’s how this is actually going to work and perform in a browser,” and show those characteristics to them early and often to get them vested in the process.

Katie:

How early are you having these conversations where you’re bringing up performance with a client? Is it the very first one that you have? Is it a kickoff meeting of some sort? When do you bring up these different metrics?

Mark:

I would say the kickoff meeting would be the latest. Often times it will be brought up and discussed in some form during the pitch process. It’s not always quite so formal. To us, it’s like a “What is this?” pitch process. It’s getting to know the client or potential client. I think so often with our clients, we have many repeat clients and lots of long term clients, and beyond any of this I think one of the most important aspects that has been valuable to us is building that trust between us and the client, and this plays in here too.

If we can build that trust, when we tell them something is important and that we’ve had a lot of success doing a certain thing on other projects, they’re going to believe us, they’re going to trust us. So, that plays into it a lot for us. Often times, we’re lucky enough to be with a client and tell them, “Yeah, it’s important for us to focus on the performance and this aspect of it, and we’ve had all these great results, and this is a substantial part of it,” and we’re lucky enough that they say, “Okay, let’s do it.” Then, like I said, there’s often that are more skeptical and who we have to sell a little harder.

Tim:

That’s fantastic for the repeat clients. But let’s say you have somebody show up tomorrow. It’s a brand new client, they’ve heard of Chromatic through some of the work you’ve done through one of the other companies, but they’re not at all familiar perhaps with the importance of performance. How are you presenting it to them to get the buy-in for that new project with that new client?

Mark:

One of my more extensive experiences with this was during my time not at an agency but when I was full-time working at Martha Stewart. This was at a time when the site was not responsive, performance was not high on many people’s checklists as far as priorities, and it was not just myself but a number of members of the development team who were really focused on, “How can we improve the site dramatically for our users on mobile?” Mobile was an increasingly big slice of the pie for us, growing at an extremely fast rate. We really had to go in and sell people not just on responsive for all of its benefits as far as user experience, but also performance as a part of that, and why it was important.

The fact of the matter was that many of the members of the time outside of the technical members, they really experienced the site—and I think this is the case in a lot of places—people who work on websites work on a desktop with a big, giant monitor. So, while intellectually they might have been able to see the numbers and say, “Okay, yeah, mobile is important and it’s becoming more important,” it was really hard for them to put themselves in the perspective of the user whose only real experience of the site was through mobile, and get their head around why performance was such an important aspect of that.

So, it took a lot of selling. Internally, we put together pitch decks with lots of case studies and metrics as far as performance goes, and had to essentially sell them like we were pitching a client now, selling the internal executives on investing in a project to improve performance, take the site responsive, and get on board with a new type of workflow that would support this type of work, move to more prototyping, testing these types of things early on in the process and not just, “Here’s a comp. Let someone else go build it. The designer by that point has moved off to something else.” So, it was really getting more focused on the performance aspect, was really part of a whole sea change in the process.

Tim:

So, the selling basically didn’t stop with the pitch deck. The selling of the importance of performance and why they needed to be paying attention to it was something that was taking place throughout the entire duration of the project.

Mark:

And even beyond. That was something that I think we learned as we went as well. Even once we got buy-in and the project(s) began to make this type of change happen… We went for a while and I remember things going well, and I remember a point when all of a sudden things started to seemingly move backwards a little bit as far as process and people not buying into this quite as much, or at least as much as they were in the beginning. Then we sort of had to pick our heads up and say, “Okay, this is nine months later, six months later…” and we realized that while we felt we had done an extremely good job of getting buy-in from all the people that were involved at the beginning, that there were new members of the team that hadn’t been there for that—they didn’t even know the history.

So, we sort of had to take a step back and say okay, this wasn’t just a one time thing of getting everyone to say, “Yes, we’re on board. Let’s do this!” but make it more of like continuing education and in some form, whether it’s when people are coming on board or just regularly giving these sorts of presentations—we’re constantly doing the lunch-and-learns around these topics and things like that—just sharing and continually making it a constant topic of conversation so that people, when they came in, weren’t just like, “Why are we doing it this way?” We wanted there to be an answer for why. We were never happy with, “This is just the way it’s always been done.”

Katie:

I have so many questions. There’s so much good information in there! [Laughs] So, it sounds like it kind of started by the technical people being like, “This is something we should care about,” and then the next step was getting leadership involved behind it. How much did leadership stay behind it? Were they just kind of like, “Yeah, that sounds good, sure. Go forth and do that,” or did they stay actively advocating for it along side you throughout that as well?

Mark:

That’s a tough question. I think that “leadership”—there are different answers to that. There were certain people with leadership who were not on board with such a big change. Luckily we got buy-in from the key decision makers, and so continuing the sell—there were people who I would say, if not fought against it, were not an active participant in all of it as far as pushing it forward.

Katie:

Did that make it hard to have opposition?

Mark:

I think it made it hard, but I think we were better for it. It forced us to really hone our message and make sure that we were doing a great job of educating people and helping them understand why we were doing what we were doing, why this was important, and so we weren’t able to just skate by. We had to continually push that message.

Katie:

How was this met by the design team? How did that become part of the entire process and not just the technical build, and was that met with resistance as well?

Mark:

Yeah. I can’t speak for them, but from the outside-in, I think it was probably scariest to them. It was the biggest change for them; the process changes that we were pushing for, getting them more involved throughout the entire process. And so it was less of a, “Here’s a comp, go build it,” and then we were responsible of figuring out how in the heck to make certain designs perform well, how to represent them in all screen sizes, but to really involve them through the entire process and make them true partners in that development.

But I think that for some of them, the scariest part was they really identified with the tools that they used. We saw them as being just as important, if not more important, to this new process. But if we said to them, “Well, you’re not going to be designing in Photoshop anymore,” some of them would be like, “Oh, what do you mean I’m not going to be designing in Photoshop? That’s what I do. My job is Photoshop.” I think maybe in their eyes they thought, “Okay, they’re trying to put me out of a job,” when in fact that was quite the opposite. So, that took some hand-holding and encouragement too—building those bonds between the development team and the design team—because that really was the end goal. “Sit at my desk with me and let’s build this together in a browser.” That was one of the more challenging aspects, but I think where we were successful was also the most rewarding.

Katie:

I think that that’s a pretty universal tough thing for people to get past, is getting the design and development team to come together. We all know that that’s so important to all of these goals, starting with even responsive. So, that’s good to hear that it worked. When you say that they moved out of Photoshop, what did they move into? It sounds like maybe they used prototypes—what did they look like?

Mark:

It depended on the designer and it depended on the project. That was something that the technical team wasn’t necessarily going to prescribe to them, like, “Here’s what you have to use.” But we said, “We don’t want a JPG as a comp.” So, whether it was literally someone sitting with one of the front end developers and building a prototype in HTML, or maybe they would show up with a Moodboard of some kind, or a sketch on the back of a napkin even… Some of them switched to other tools that were vector-based, but that was sort of an experimental time especially. Each designer was certainly different as far as what they were most comfortable with in that transition.

Tim:

I think the prototyping thing has a lot of benefits and I’m curious as to how you use that from the performance perspective. With those early prototypes, how were you testing the performance of them? Did you basically lay them out on a variety of devices and just kind of walk through and see where the hiccups were? What was your process like there?

Mark:

Yes. Especially with Martha Stewart and so many of our clients now, we are very lucky to work with a lot of publishers that have fabulous, beautiful imagery. Whether that’s Martha Stewart, or Emeril Lagasse, or Outside Magazine, one of their greatest assets is their photolibrary. So, page weight is always a concern because they want big, huge, beautiful photos, so when we’re prototyping those types of things, we’re grabbing random photos from the library and placing them on the page, testing them on different devices but looking at page weight and all of those things to really get a feel for what it’s going to mean for the user from the performance perspective to have a certain implementation.

Tim:

Did you have any sort of performance budget in place at all?

Mark:

No. We tend not to think of performance separately from any other part of the development. We don’t put any sort estimate as far as performance. I look at it in the same way as code quality or anything else like that. We have a certain level that we are comfortable with delivering at, I believe it’s quite a high level, and that’s what we’re going to do. Of course it’s sort of built into the overall budget and our estimates and everything like that, and there’s always exceptions, there’s always client demands that change, and of course it’s easy to say it’s always going to be a certain way, but in general it’s just going to be part of every conversation.

Tim:

I’m sorry, I didn’t mean from a monetary perspective. I’m curious if you had a specific target you were setting for performance, and then if you were monitoring that in some way. So, with these heavy imagery sites, maybe you were saying that you wanted all the sites to weigh less than 1.5MB or to load in less than X seconds. Did you have any sort of objective that way? If so, how were you keeping tabs on it?

Mark:

That’s an even better question. [Laughs] The short answer is no. Often times what we’re dealing with when we’re coming in, whether it’s a new client or an existing client, we’re working off of whatever the existing site is. Our goal is to make a significant improvement from that, so it’s variable in that regard. We look at that as a baseline and then we’ll potentially set some internal goals related to that. But we don’t necessarily have a, “We want every site to be X page weight or load in X amount of time.” But it’s an interesting idea. I would be interested in experimenting with that.

Tim:

Did you run into any issues with that? So, without a clearly defined target, and you have designers and developers working alongside each other to try and make something that’s going to look great and perform well, did you run into any hiccups where it was hard to advocate for, say, ditching this carousel in lieu of performance?

Mark:

Yes, 100%. There’s always going to be conflicting interests, whether it’s strictly from a performance perspective or as it relates to usability or anything like that. What we’re always advocating for is the best experience for the user, which we believe is long term going to result in larger, more valuable traffic for the site. There are many times when certain people in the organization might have short term concerns that don’t necessarily align with the performance or usability. Maybe it’s ad sales who want a certain amount of impressions and there’s a certain interaction, or page, or design that they believe is going to help them achieve that.

When it comes to that, it’s really about trying to advocate to them that you understand what their goals and short term needs are, but you’re really working towards the same thing when you scale the timescale out a bit longer. Sometimes compromises have to be made, because they have their jobs to do as well.

Katie:

Coming from Martha Stewart, where you had to internally figure out this new workflow, and then switching to agency-side, what were some of the main positive takeaways of things that you learned at Martha Stewart that now are part of Chromatic? What did you learn switching in-house agency?

Mark:

So much of our work now is influenced by that, and the experiences of our other team members as well. We are very much focused on when we’re working with a client, we’re not just delivering a website. We want to be partners with them and are hopefully delivering a website that they love. But also we want to share our process with them, all that we’ve learned from that. Some clients have a fantastic process and we get to learn from them. Other times, our clients are very interested to improve their process and love having the input from those other experiences.

So it’s been, to be honest with you, not quite as different as you might think. Like I mentioned earlier, in much of my experience at Martha Stewart, there were many times where we were selling different departments on things, just like we’re trying to integrate new tools to our clients now as external vendors.

Katie:

Do you have project or account managers at Chromatic?

Mark:

We do not have dedicated project managers. It’s something we’ve thought about for possibly in the future, and many of our projects are structured differently depending on the needs of the client. Sometimes our developers are just joining an internal team and adding another set of hands and their expertise to a project. Other times, we are running the entire project. In that case, one of our team members would serve as a technical project manager. But no, we don’t have dedicated project managers. We haven’t, to this point.

Katie:

I was just curious as to how the PMs played into maintaining the performance process.

Mark:

Yeah, I think that’s one of the benefits to having someone technical leading that role. They’re able to directly understand the implication of that and drive that discussion.

Tim:

You guys are a Drupal shop, so a lot of your clients have a lot of control over the content that gets placed on the page. So, you can do a lot in terms of optimizing for performance ahead of time, but at the end of the day your clients are going to have a lot of control over what that experience is actually like once they’ve published that content and pushed it. How do you manage that in a way that maintains some of the performance you’ve worked so hard to improve?

Mark:

I’m not sure I understand the question.

Tim:

So, in a lot of editorial situations, and I’m not sure, maybe you have it set up slightly different depending on your clientele, but they may have the option to use slightly different widgets or content depending on how on what page or what time of year it is, or whatever it happens to be that they’re promoting. I’m curious if you’re providing some sort of guidelines inside of the editorial guidelines, something to emphasize the performance of things, or are you just building in a way in which no matter what they put on the site, it’s going to be optimized as much as possible?

Mark:

The latter. We try to give our clients, their editors, as much control as possible while still doing our best to do a great job of building as semantic as possible of a data model and a structure for that content. We’re very focused on not just how the content is going to be rendered to the page, but how it might be used in the future in ways that we’re not currently aware of. Whether it’s exposing that to a third-party via an API, some kind of partner or something like that, or another site of the client’s that might consume it in the future. We often have clients that have multiple sites interacting with internal data.

But when it comes down to it, we don’t want to hamstring them or control the editors to the point where they can’t get their jobs done every day. That’s something we’re super focused on, is the editor experience as well. We want to make them super effective. It’s sort of a balancing act. But yeah, we just try to do the utmost on our side of things to make sure that whatever they put in, it’s going to do well on the web.

Katie:

Does that include image optimization? You said a lot of your clients have this big, beautiful imagery. How do you ensure that when they’re maintain the site, that they’re not adding these super heavy images?

Mark:

We’re resizing images dynamically everywhere. So, we’re always conscious of what size image is going to be served to the page, depending on the display size or the layout. We’re always dynamically resizing images.

Katie:

But if the client takes it and they just hit save and then add this really heavy JPG before reducing the image quality of the JPG, or running it through the things that will make it smaller—do you have guidelines for how they can best make their images small before even putting it in the CMS?

Mark:

This is a good question. I actually didn’t even really think about this, but as you said that I was like, “Oh, okay.” Usually we do our best. Clients are going to do whatever they want, but what we push for is—especially with clients that have tons of images—there’s often quite a bit of metadata and reuse that goes along with these images—image rights, things like that. So images are usually, on our sites, a first-class content type and they are using those images by referencing those images from another piece of content.

So an article or a recipe, for instance, wouldn’t have an image in a WYSIWYG content area or something like that. It would have a reference to an image content item. So we, at that point, have control over which version of the image is going to be used and how it’s resized, and we do all of that programmatically in the rendering. Often times also a certain image will have different crops, and especially for clients that have their own image teams, they can be very particular about what crops get used in which situations and how those crops look. So, we might have one image with one image content item that has three different crops, so three files attached to that one image node. Then programmatically, let’s say we’re rendering a recipe, we know that we want the horizontal crop for the top, and so we generate and render that on our end.

Tim:

Do your sites rely a lot on a variety of widgets that you’re placing within a page? Do your clients have a lot of control over what chunks of content are placed within a single page? Does that differ a lot?

Mark:

Typically not, at least from a perspective of thinking about them as widgets. We certainly love and get excited about allowing the editor to control how a piece of content is displayed, and often times early in the process they’re going to have 18 different ideas about all these different ways a certain piece of content can be displayed. But one of the things that we try to do is focus that down and say, “What are the three most important?” Then that helps us from a number of perspectives. Obviously limiting the initial amount of work to implement those, but also allowing us to focus on a smaller set of iterations from a performance perspective. From that perspective, we can allow the editor to say—while in that approach they can’t necessarily have 100% control of where everything is laid out—they’re able to select layout A, B, or C and then we render the page in such a way based on their selections.

Tim:

Nice, so it sort of protects them from shooting themselves in the foot a little bit by making something obnoxiously heavy by shoving a bunch of widgets all together.

Mark:

Exactly. We try to go for the happy medium. Of course it would make our lives insanely easier if we could say, “Every time you publish an article, it’s going to look exactly the same way.” But from an editorial perspective, that’s not ideal. Who wouldn’t want complete control on an article-by-article basis of how everything is laid out? So we try to find that middle ground, find the most important things for the client to make sure that they’re going to be happy and satisfied with it. And then what I’ve found is that once we’ve done that, then usually there’s at least one implementation that they end up not using so much, a few that they use all the time, and then we can build from there and say, “Okay, well let’s add another one, let’s add two more,” and sort of figure out what works and what doesn’t. Use the knowledge and the learnings of not only what we’ve built on the development side to influence the build going forward but also what they’ve learned from the editorial side—what worked for them building it editorially, what worked for the user as far as metrics, and improve and build from there.

Tim:

That sounds very smart. We’ve also talked a little bit throughout about your testing for performance, but we never really got into the “how.” Do you basically just fire up some sort of dev tools and check things out there, or are you using a tool like YSlow, or PageSpeed, or WebPageTest to keep tabs on things? How are you handling that?

Mark:

We use WebPageTest, YSlow, all the browser developer tools, and I’d say everybody on the team has their own tricks up their sleeve beyond that, their favorite test that they like to run. But yeah, pretty standard tools, to be honest with you. We don’t have anything custom related to that.

Tim:

Most of the time you probably don’t need. There’s a lot of really excellent tools out there.

Mark:

Yeah, we’ve been very happy with the results that we’ve gotten from them.

Katie:

I think we’re getting close to nearing the end of our time. Is there anything really important that we haven’t covered that you feel like you want to share? There’s been so much great stuff hearing, from your agency side and client stuff. I loved everything you had to say. Is there anything else you wanted to add?

Mark:

Just to reiterate and say that if you’re having trouble from that perspective in getting people on board, to me the most important thing was enthusiasm and really getting people to understand that all the goals were aligned, everyone was working towards the same ultimate goal, and that was to build a better website that more people are going to come to. If you have 10 people coming to your website, you want 15. If you have 150,000, you want 200,000. So, getting everyone to recognize and believe that they’re all working towards that same goal was really key.

Tim:

Awesome advice. Mark, is there any way for people, if they want to follow what you’re doing after the podcast, how should they do that?

Mark:

Absolutely. So, ChromaticSites.com, @ChromaticSites on Twitter and I am @MarkDorison on Twitter.

Tim:

Fantastic. Well, thank you sir. Like Katie said, that was fantastic. We really appreciated it.

Katie:

Thank you.

Mark:

Thank you guys for having me.

Tim:

Thank you for listening to episode two of the Path to Performance podcast. You can subscribe to the podcast through iTunes or on our site, pathtoperf.com. You can also follow along on Twitter @pathtoperf. We’d love to hear what you thought, so feel free to drop us a note on Twitter or leave a raving and overly kind review on iTunes. If you’d like to talk about being a guest or sponsoring a future episode, feel free to email us at hello@pathtoperf.com.