Performance Optimization: A Tale of Two EE Sites

Lea Alcantara: This episode is brought to you by mithra62’s Backup Pro, a complete backup solution for WordPress, ExpressionEngine 2 and 3, Craft, PrestaShop and concrete5. We use this one ourselves for some of our client sites. It’s insanely customizable and includes automated backup integrity, eight built-in storage locations, console routing. Basically, Backup Pro was built to make disaster recovery as painless as possible. Just visit backup-pro.com to get started.

[Music ends]

Emily Lewis: We were originally going to talk to Stephanie Morillo today, but she’s under the weather, so we rescheduled her for September and today it will just be another episode with me and Lea.

Lea Alcantara: Hi.

Emily Lewis: We’re going to talk about website performance.

Lea Alcantara: Yeah. This was actually on our schedule anyway because over the past 18 months we’ve seen a big increase in our clients’ interest in and concern about the speed of their website.

Emily Lewis: [Agrees]

Lea Alcantara: Especially on mobile.

Emily Lewis: Yes.

Lea Alcantara: And when you’re dealing with websites, they rely on CMSs (Content Management Systems), it’s a lot more complicated than just the size of images or fonts or the order of your JavaScript, that kind of stuff.

Emily Lewis: All right, so then let’s define our topic, what is performance?

Lea Alcantara: It’s interesting because we actually had to answer this ourselves recently.

Emily Lewis: [Agrees]

Lea Alcantara: The term “performance” can encompass so many things, but for this particular discussion, I think the simplest way to explain it is how fast your site loads on your screen.

Emily Lewis: Absolutely. I think that’s one of the easier benchmarks for everyone, including clients, who don’t know a whole lot about the technology behind the scenes to connect with because they know what it feels like when the site is loading slow.

Lea Alcantara: [Agrees]

Emily Lewis: But I also think it’s worth noting the performance can also include how stable your site is, your uptime.

Lea Alcantara: Absolutely, absolutely.

Emily Lewis: So let’s talk about those two aspects. What is speed?

Lea Alcantara: So when we’re talking about speed, it can actually be a mix of things. You’ve kind of hinted that in the intro there. It’s how long it takes for the text of a page load, and that’s relative to the images, which is relative to the CSS and scripts and that’s relative to the software running like a CMS.

Emily Lewis: [Agrees]

Lea Alcantara: But a site visitor just perceives this all at once as page loading on their screen.

Emily Lewis: [Agrees]

Lea Alcantara: But for us, web devs, we need to take every single point that I just mentioned apart.

Emily Lewis: To identify where the bottleneck might be.

Lea Alcantara: Exactly, exactly.

Emily Lewis: But for a user, they’re just like, “The page is slow.” [Laughs]

Lea Alcantara: Yeah, exactly.

Emily Lewis: So let’s talk about stability, what’s that?

Lea Alcantara: So stability is really how reliable each of those site pillars I just mentioned are. So when one of them breaks, like a third-party script, a fast site otherwise can be brought to a complete crash or halt.

Emily Lewis: [Agrees]

Lea Alcantara: Stability for most web devs, I think, tends to point towards server and its configuration and hosting, as well as the CMS the site was built on, like how can it handle increased page views and the marketing initiative that brought a ton of traffic.

Emily Lewis: All right, so speed and stability, especially like when we’re talking to a client, I think it’s important to note that these aren’t really fixed measure points.

Lea Alcantara: No, no. Because speed and stability can vary based on a variety of factors, but many of them can really be isolated toward simultaneous site visitors.

Emily Lewis: [Agrees]

Lea Alcantara: So if you had a marketing initiative that brought a ton of traffic, that’s different compared to site visitors that are there on a regular basis.

Emily Lewis: [Agrees]

Lea Alcantara: So even in inefficient site can be fast if there aren’t very many visitors, right?

Emily Lewis: Right. And so with that kind of premise in mind, so a client can be chugging along happy as punch with their site and then some event happens in terms of attracting visitors on their site and it crashes and it’s nothing that anyone foresaw or could have anticipated for because it was doing fine.

Lea Alcantara: Yeah.

Emily Lewis: So it was almost you noticed there’s a problem when you have a problem.

Lea Alcantara: Yeah.

Emily Lewis: It’s not necessarily something you could technically mitigate for a hundred percent.

Lea Alcantara: Right. And it also changes depending on the volume in regards to that, because, say, the first time that happens, you tried to fix it and you think, “Okay, that’s great.” But let’s say you’ve got ten times more the following year, whatever you did to fix, say, two times more is different from ten times more.

Emily Lewis: Exactly. And then you can’t even control some of the factors. Like you mentioned, if you’re using a script from a third-party service, let’s say it’s something that we see a lot that I feel like we’re going to talk about a lot today, but like those tracking scripts that marketing departments want to add to websites for campaigns or whatever they’re tracking.

Lea Alcantara: Right.

Emily Lewis: If one of those is failing, that can trigger a 404 that you don’t actually see that is happening behind the scenes that can send your site to take it down entirely.

Lea Alcantara: Right, or it doesn’t necessarily take it completely down in the way that you get a Pingdom alert because usually Pingdom gives you an idea that your hosting server is down.

Emily Lewis: [Agrees]

Lea Alcantara: But it’s so hard to tell that it’s the hosting versus a third-party script because sometimes when that fails, it just stalls the site so slow so it looks like it’s loading, and then it doesn’t completely finish, and then so that’s another way that speed can be shown where like something is feeling, but like what is it? I don’t know.

Emily Lewis: All the client sees is that their site isn’t working during a critical time.

Lea Alcantara: Right.

Emily Lewis: And so what we’re hoping to share today is the stuff we figured out that will hopefully help you because what sort of prompted our focus on performance, aside from the fact that we really are seeing this come up across all of our clients. But we had a client, their site went down, and it’s one of the clients that we’re going to talk about today, during a critical marketing campaign and it sort of prompted us to take a really focused look at how we approach monitoring performance.

Lea Alcantara: [Agrees]

Emily Lewis: So before we get into some of that though, do you think there’s anything else that should be considered part of performance?

Lea Alcantara: Definitely. So there’s ease of future maintenance.

Emily Lewis: [Agrees]

Lea Alcantara: Once things are a lot more stable, then you don’t have to be scrambling so much. [Laughs]

Emily Lewis: [Agrees]

Lea Alcantara: It will be just easier for admins as well as vendors such as us to find issues or to generally maintain the site.

Emily Lewis: I also think that part of that maintenance is also keeping a system upgraded that makes it easier for future maintenance and that makes it easier for the client. I think something that isn’t talked a lot about, at least in our industry, about performance is sort of your client, your client’s staff, the stuff that is the qualitative experience of dealing with their site, and if it’s hard to manage the CMS, if it’s hard to manage on the server, that’s also part of performance.

It all contributes to their perception of it’s not working for them, and so to a degree, that is also a part of our discussion with our clients because it isn’t just about how the site is handling the front end, in the browser or on the phone, but it’s also about how they have to maintain it and the quality of their life and how long or how painful it takes them to do something.

Lea Alcantara: Yeah, absolutely, and I’m thinking about our one particular client where the bulk of the work of maintenance is on one person, and so not only do we have to fix the site, we have to make sure that our fix doesn’t add further headaches to the staff.

Emily Lewis: [Agrees]

Lea Alcantara: So there has to be discussions in regards to the workflow that works.

Emily Lewis: Yeah.

Lea Alcantara: Because maybe there’s something that could fix and it’s fast or it’s like even the better solution, but if you only have one staff and you don’t have the resources to babysit the site, then you might need to make a compromise over that particular solution so that it’s actually practical and workable for that particular time.

Emily Lewis: Absolutely. So as I mentioned, we’re going to talk about two client projects today. They’re both ExpressionEngine clients and so they have common issues related to their CMS, but also very unique in terms of everything from how their staff works to how we tackled performance for each one of them, and in terms of the problems that we found on their sites, and I think just these two clients really illustrate that performance work is really custom work.

Lea Alcantara: Right.

Emily Lewis: I don’t think there are some, “Oh, buy our 10-point checklist package and we’ll fix your site.” It’s just not that simple.

Lea Alcantara: Yeah.

Emily Lewis: There may be three things you could do to pretty much every site.

Lea Alcantara: Right.

Emily Lewis: But whether those three things have a huge impact on that site’s performance, you may not really been helping if you’re only attacking those common three things and not finding out what the unique custom issues are for a certain site.

Lea Alcantara: Absolutely.

Emily Lewis: So generally speaking, we tackle all of our performance work from two angles, front-end and the CMS’s back-end.

Timestamp: 00:10:00

Lea Alcantara: Yeah.

Emily Lewis: Lea, you’ve done the bulk of our back-end work. Can you talk briefly about how you assess the performance of the EE CMS, the approach you take, tools and documentation?

Lea Alcantara: Sure. So first, let’s talk about what’s already built in, the internal tools.

Emily Lewis: [Agrees]

Lea Alcantara: While we’re talking about ExpressionEngine, all CMSs have some sort of debugging tool built in.

Emily Lewis: [Agrees]

Lea Alcantara: Usually, they’re available in some sort of developer mode or logged-in only type of situation. In our particular client cases, they’re both in ExpressionEngine 2 and there’s the Display Output Profiler and Display Template Debugging, which are ally crucial to figuring out where the bottlenecks are. So the Output Profiler is the overall view of the page because it gives you the benchmark times, like total execution, and a really great number is overall number of queries as well as the memory usage, like how much it takes for the machine to actually build the pages in memory.

Emily Lewis: Can I ask you why the overall number of queries is a good number?

Lea Alcantara: Oh yeah, because really what you’re trying to do whenever you’re building a CMS is for it to display content without having it to hit the database too much.

Emily Lewis: [Agrees]

Lea Alcantara: And a query means it’s hitting that database.

Emily Lewis: [Agrees]

Lea Alcantara: So one query is it talks to the database once, twice, et cetera and so forth. So the more queries is the more times it talks to the database, and the database query takes a lot more time than, say, just loading a .txt text file.

Emily Lewis: [Agrees]

Lea Alcantara: Because there’s no database review in trying to trickle down through different tables, et cetera and so forth.

Emily Lewis: Okay.

Lea Alcantara: So the amount of queries is really important because it’s kind of a multiplier.

Emily Lewis: The more you have, the potentially slower your page is going to be.

Lea Alcantara: Yes, absolutely.

Emily Lewis: Okay.

Lea Alcantara: And the other important thing that ExpressionEngine has is the Display Template Debugging.

Emily Lewis: [Agrees]

Lea Alcantara: So once you’ve got the overall view, when you’re trying to figure out the actual problem within the page, it allows you to drill down to specifics of the page load. So we talked about, okay, total number of queries, now the Template Debugging tells you exactly what queries are the issue.

Emily Lewis: [Agrees]

Lea Alcantara: So to drill down how long each specific query takes to load and how many times a particular query is being asked.

Emily Lewis: [Agrees]

Lea Alcantara: Specifically, let’s say, a particular add-on might be called several times.

Emily Lewis: Okay.

Lea Alcantara: But before we even view those outputs, you kind of have to narrow down what pages to review.

Emily Lewis: Right, right. Sites are hundreds, thousands of pages. [Laughs]

Lea Alcantara: Right, right.

Emily Lewis: You can’t just go to each page and look at the numbers.

Lea Alcantara: Right, right.

Emily Lewis: I mean, I suppose you could, but that would be a crazy budget.

Lea Alcantara: Yeah. And really, it’s not only they’re not practical, but it doesn’t really make sense because most CMSs, let’s say, one page is being rendered through one template.

Emily Lewis: Right.

Lea Alcantara: And that applies to multiple pages.

Emily Lewis: Right.

Lea Alcantara: So in many ways, like when you’re narrowing things down, let’s say, there are two slow pages, but if they’re using the same template, you’re actually fixing more than just those two pages or that one page.

Emily Lewis: Right. So change to a template could affect 50 pages on the site.

Lea Alcantara: Or more.

Emily Lewis: [Agrees]

Lea Alcantara: Yeah, absolutely. So in order to narrow down that page, that’s kind of like an art and a science, right?

Emily Lewis: [Agrees]

Lea Alcantara: And you know how you were talking about how every client is custom because every site is different, et cetera and so forth, so for one particular client, we had to go into their Google Analytics and we narrowed down their most popular pages and Google Analytics showed their load times.

Emily Lewis: [Agrees]

Lea Alcantara: So we then just created a spreadsheet that broke down what pages we felt were important based on the prominence and the slow load time.

Emily Lewis: Right.

Lea Alcantara: Then we spoke to the client to kind of cross reference these findings to verify them and to take into account their anecdotal preferences, because usually they come to us with the anecdotal preference already.

Emily Lewis: Right.

Lea Alcantara: Like, “I think this page is slow.”

Emily Lewis: Right. For this client it was the home page. That was the one they noticed all the time.

Lea Alcantara: Right, right. But sometimes there’s an important page of the site that wasn’t on their radar until we reviewed their Analytics.

Emily Lewis: [Agrees]

Lea Alcantara: And other time, they really want to work on promoting a particular part of their site that may not have bubbled up in the Analytics, let’s say, but it’s important to them because that template runs through pages that affect multiple parts of the site. So maybe the one particular page didn’t show up, but something lower on that list could actually affect most of the site, so it has a larger impact to fix.

Emily Lewis: Right. We did something different though with the other client project that we’re talking about.

Lea Alcantara: [Agrees]

Emily Lewis: So the one you were just talking about, that was a unique approach where they wanted a dedicated focus on their performance. They saw a bad, slow home page, and they wanted us to fix it, and so that’s where we started from, to identify the pages to review, but for the other project, it wasn’t like that.

Lea Alcantara: [Agrees]

Emily Lewis: It was more along the lines of that crash situation. [Laughs]

Lea Alcantara: Yeah, right. Well, this other one was an emergency.

Emily Lewis: Exactly. They didn’t even notice. I think they were kind of okay with some pages running slow until it crashed their site.

Lea Alcantara: Right, right, right.

Emily Lewis: So let’s talk a little a bit about that particular client and how we picked the pages to focus on for performance improvement.

Lea Alcantara: Okay. So for this other project, we were able to configure and install this amazing service called New Relic, which the other client couldn’t install because it was a weird configuration of IIS and PHP, which is incompatible with New Relic.

Emily Lewis: Which we found out after we were counting on it, so make note. If you’re working with IIS, don’t count on New Relic at this point in time.

Lea Alcantara: Right. Unless you’ve got a Windows-specific website, but if it’s like kind of a mix of technologies, IIS and PHP, so it wasn’t able to deal with that.

Emily Lewis: [Agrees]

Lea Alcantara: But if you ever have to do any emergency review of speed issues, I highly recommend this service because it essentially finds slowdowns almost immediately.

Emily Lewis: [Agrees]

Lea Alcantara: Once you’ve set it up, the long and short of it is it will uncover the most problematic pages based on errors and load times based on the application itself, so ExpressionEngine.

Emily Lewis: [Agrees]

Lea Alcantara: So it’s not just a typical WebPageTest.org, New Relic has access to the database in system calls to really narrow down the bottleneck inside ExpressionEngine down to the specific query.

Emily Lewis: [Agrees]

Lea Alcantara: Now, unlike the other client, we didn’t have a spreadsheet of specific pages because this is an emergency situation to target for this particular client.

Emily Lewis: [Agrees]

Lea Alcantara: So instead we used New Relic to find the bottleneck.

Emily Lewis: [Agrees]

Lea Alcantara: And because of this particular situation, there was a lot more client collaboration. So using New Relic, we notified them. When we noticed a particular bottleneck, we get approval to work on it and then they notify us of upcoming campaigns so then we tackle those as a first come first serve kind of basis.

Emily Lewis: [Agrees]

Lea Alcantara: And then we monitor progress on specific dates and times that they tell us a campaign is having. For documentation though for this particular client, we do have a running list of cached templates and any of the upcoming campaigns and specific pages affected by that campaign.

Emily Lewis: Right. So it’s definitely a more ongoing thing versus the other client we were talking about where we identified some key pages and collaboration with them and we just tackled those pages.

Lea Alcantara: Right.

Emily Lewis: With this one, we’re kind of monitoring at all times, and one week we don’t see any issues, the next week they have a new campaign, and then we’re going to focus on that page, and it’s a moving target, I suppose is the best way to put it. But it’s not chaotic, it’s very planned.

Lea Alcantara: Right, right. And I think the difference is where each client was in their – I guess – like project life cycle or their site readiness.

Emily Lewis: Yeah.

Lea Alcantara: Like with one client, they weren’t necessarily, there was no emergency situation. It was just like a long-term slowness situation that they just didn’t have the resources previously to address.

Emily Lewis: Absolutely. And I think it’s also worth mentioning not only are they in different places with their project lifestyle, but their sites were so different. The client for which we’re doing the ongoing monitoring and sort of responding very quickly to needs as they show up each week, their site has been – it definitely needs to be looked at.

Lea Alcantara: Right.

Emily Lewis: It’s kind of more band-aided than anything else.

Lea Alcantara: Right.

Emily Lewis: Because of ongoing staff turnover on their end.

Lea Alcantara: Right.

Emily Lewis: And with different staff come different needs for different workflows. There’s never seems to be the full budget to attack it holistically so we’re addressing things as they come up, whereas the other system wasn’t in that sort of state. It was all updated. Everything is working together in line. We had worked on a previous website with them, they’re on a multiple site manager, EE install, so their environment was just a lot more well integrated as opposed to more bolt-onish, I guess is the best way to put it. [Laughs]

Lea Alcantara: Right, right. Because one client generally have particular developer working on it for several years.

Emily Lewis: [Agrees]

Lea Alcantara: And the other client had multiple developers touching it, so it was a lot harder to discern what any of the issues were so New Relic was really, really important figuring that out.

Timestamp: 00:20:01

Emily Lewis: [Agrees]

Lea Alcantara: And by the way, we do have an episode (Diagnosing Performance Using New Relic) focused on New Relic.

Emily Lewis: [Agrees]

Lea Alcantara: So I won’t go into like detail specifics about that, but between Google Analytics and New Relic and having thorough discussions with your client, you should be able to narrow down exactly what’s going on and what you need to test to have the largest impact.

Emily Lewis: [Agrees]

Lea Alcantara: And I just wanted to talk again a little bit about some of the documentations. Once you have all these tools, it made sense for us, at least from one particular client, we created this spreadsheet outlining all the Output Profiler details, Template Debugger details and Google Analytics details per page to have a clearer before look.

Emily Lewis: [Agrees]

Lea Alcantara: And we’ll talk a lot more later in this episode about why that’s important, but I just wanted to point out like those were the types of things that we made sure that we documented early on.

Emily Lewis: Absolutely. And just mention, Lea, if you don’t mind, for the other client where we’re doing the ongoing work, you do still provide documentation and tracks specific statistics.

Lea Alcantara: Yeah, except instead of Google Analytics and Output Profiler stuff, it’s the graphs and numbers from New Relic.

Emily Lewis: [Agrees]

Lea Alcantara: So week by week we kind of do kind of a bullet point list of, “Here’s what we did this week. Here’s the impact. Why was there performance issue here? It’s because of this, et cetera and so forth.”

Emily Lewis: Yeah.

Lea Alcantara: And we’ve been talking a little bit about ExpressionEngine, but as we mentioned, that’s not just the only pillar of a site speed.

Emily Lewis: [Agrees]

Lea Alcantara: We also have a lot of front-end stuff to think about. So Em, you do the bulk of that particular work. What do you do to evaluate front-end assets?

Emily Lewis: Honestly, at least in my experience, this is the easier aspect of performance work.

Lea Alcantara: Sure.

Emily Lewis: It’s also the aspect, I think, that’s probably the best documented on the web.

Lea Alcantara: Yes.

Emily Lewis: Like if you’re going to look at the web performance article, they’re probably going to talk pretty much all about the front-end. [Laughs]

Lea Alcantara: Sure.

Emily Lewis: So there is a lot of information out there to help you figure out solutions to this stuff. The other thing that makes a front-end performance optimization easi—er [laughs]…

Lea Alcantara: [Laughs]

Emily Lewis: … is that, to a large degree, it tends to be global.

Lea Alcantara: Right.

Emily Lewis: So even though, as Lea was describing for the ExpressionEngine performance testing, you have to identify specific pages to look at. I certainly use those as the ones I test, but most of the time, the front-end assets are being called globally. So the findings I might discover for one page will probably affect all the other pages we’ve identified as well as the rest of the site just because they’re global.

Lea Alcantara: Right.

Emily Lewis: There are always exceptions to that, but that’s sort of the benefit of the front-end, and what makes it a little easier is that so much of it ends up having a global impact.

Lea Alcantara: Right.

Emily Lewis: But I do like to have those initial before statistics.

Lea Alcantara: Right.

Emily Lewis: And so once we know the pages that Lea is looking at from a back-end perspective, I test those same pages in a few different performance tests that I like. The ones I always use are Google PageSpeed, Pingdom, WebPage Test and GT Metrix. I’ve used YSlow in the past, but honestly, everything I get from WebPage Test is almost exactly what I get from YSlow, so I haven’t seen a value to do both. Save yourself five minutes per page for testing. But that said, they all do provide pretty similar information, page load time, page size, requests. A couple of things about what I like is that PageSpeed, I like how it runs tests for mobile and desktop so you can get scores in context.

Lea Alcantara: Right.

Emily Lewis: And that’s really good for discussing these numbers with the client, emphasizing that, “You’re not seeing it on your computer, but look at this test, we’re seeing problems in mobile,” and it sort of extrapolates some of the things that would affect mobile more than it would desktop.

Lea Alcantara: Absolutely.

Emily Lewis: I also think Google PageSpeed connects with clients because Google has name recognition for them.

Lea Alcantara: Absolutely.

Emily Lewis: An importance in their minds, while Pingdom doesn’t mean much to anybody else, WebPage Test doesn’t mean much to our clients, and so I typically talk about Google PageSpeed with the client because it’s instant.

Lea Alcantara: Right.

Emily Lewis: Oh, that’s important to them, but it’s not my only metric partly because Google PageSpeed, interestingly enough, penalizes you for not caching assets, including remote assets.

Lea Alcantara: [Agrees]

Emily Lewis: But you can’t cache remote assets because they’re remote.

Lea Alcantara: Because they’re on their own.

Emily Lewis: Exactly.

Lea Alcantara: Including like Google Analytics. [Laughs]

Emily Lewis: Exactly. [Agrees] So you get dinged by Google PageSpeed for using Google Analytics, but the only way to not get that penalty is to not use remote assets and to cache every local hosted assets, and it’s not possible for most business cases that are relying on Google Analytics or things like Typekit or other services like that, and that’s why I like GT Metrix because that service corrects for that. It doesn’t ding you for remote asset caching, just local asset caching.

The other reason why I have so many, so that’s why I like Google PageSpeed and GT Metrix, they kind of give me one-to-one results, but GT Metrix corrects for what PageSpeed penalizes you for. But what I also like about WebPage Test and Pingdom that PageSpeed doesn’t have is they give you a visual timeline of asset requests, so you use your Time to First Byte (TTFB) and then where all the other assets fall into place so you can see right away if there are some tracking JavaScript code that’s holding things up at a certain point, and I just find that really useful.

Lea Alcantara: Absolutely, and I believe WebPage Test also even shows you a little bit of a video to show you like really as the things fall.

Emily Lewis: [Agrees]

Lea Alcantara: You can actually visually see it happen.

Emily Lewis: Absolutely yeah. So basically, all of those tests and the data that I get from them I add to that spreadsheet that Lea had started that has her back-end performance values.

Lea Alcantara: [Agrees]

Emily Lewis: And again, that sort of is our before picture that we rely on to inform the client about what we’re going to do and have a comparison point for how much we improve things.

Lea Alcantara: Yes, absolutely. So once we have a baseline, we then have to move into the actual work. [Laughs]

Emily Lewis: [Laughs]

Lea Alcantara: But let’s talk first about our clients. Let’s call it Client A whom we’ve been working with for almost five years.

Emily Lewis: Okay.

Lea Alcantara: That was the site that we inherited to provide EE development.

Emily Lewis: Bolt-on Frankensite. [Laughs]

Lea Alcantara: Yeah, yeah, yeah. So over the years we now provide support for everything, not just tiny EE dev here as well as design, et cetera and so forth, but that also means we’re supporting a front-end that we didn’t build.

Emily Lewis: [Agrees]

Lea Alcantara: Which is a good segue to talk about their front-end-related performance challenges. So why don’t you talk about that a bit, Em?

Emily Lewis: Yeah. So this happens whenever you inherit a site, you’re dealing with someone else’s code. This particular site is using a Bootstrap foundation, which if anyone knows me knows that I don’t use frameworks, and I think some of the challenges I encountered that are related to Bootstrap just sort of underscored for me that I’m still making the right decision by not using that for production work.

Lea Alcantara: [Agrees]

Emily Lewis: But anyways, the specific things I found with this Client A, the first thing in front end, images.

Lea Alcantara: Yeah.

Emily Lewis: In fact, for both of our clients. Images were, and frankly still are an issue. The file sizes are simply too big. The solution is part client education, which we’re just kind of constantly reminding them of that you have to start with a well-optimized image. It doesn’t need to be bigger than it’s going to display. [Laughs]

Lea Alcantara: Yeah, right. [Laughs]

Emily Lewis: Like those things just aren’t necessary, but also part of it is modifying content management system workflows to force things like file size limitations, image resizing, and things like that. The other front-end issue I found that was the most problematic after images, because frankly, images was number one across the board because they’re just big files.

Lea Alcantara: Yeah.

Emily Lewis: So that was always what was showing up. But the other thing that is a problem on this client site, we haven’t actually addressed it for this Client A, is that they have a lot of those marketing tracking scripts. Not only are these an additional request on the page, but most, if not all of them are actually redirects, and so with Pingdom, that’s almost a double penalty. You’re getting penalized for the request, and then penalized that it’s a redirect. The solution for this is really to bring it to the client’s attention and have them review what’s there and find out if everything is still needed and get rid of what isn’t.

Lea Alcantara: Right.

Emily Lewis: Because frankly, there are some scripts on the site that were there five years ago with staff that’s no longer there.

Lea Alcantara: [Agrees]

Emily Lewis: And I don’t think those campaigns are still running, and so it needs to be something that has to be looked at. We can’t decide that, but we can give them a list of what we’re seeing and have them say whether they can remove it or not.

Lea Alcantara: Right.

Emily Lewis: And if they can’t remove it, then it’s really a discussion about making sure the client understands that not removing it does place a limitation on our ability to make performance improvements.

Lea Alcantara: Yeah, absolutely.

Emily Lewis: You know, that’s just the bottom line. If they can’t get rid of it, then they have to understand the impact of it.

Lea Alcantara: That’s just the reality of bolt-on sites.

Emily Lewis: [Agrees]

Lea Alcantara: Like when you have so many developers, they just keep adding a bunch of things, and 404s, they’re a nuisance.

Emily Lewis: [Laughs]

Lea Alcantara: They’re a nuisance. They really do affect performance.

Timestamp: 00:29:58

Emily Lewis: Yeah. Another thing that was high on this client’s list of front-end issues was render-blocking scripts. These are scripts, and even sometimes CSS, that literally blocks the page rendering until the files load, and it’s typically because these files are in the document head. There can be other reasons, but that’s the most common reason why it’s a problem, and the solution is to move them out of the head if you can.

Lea Alcantara: [Agrees]

Emily Lewis: You can’t always. Another solution may be to call them asynchronously. There’s an (async) parameter for a JavaScript tag so that tells the browser to call it, “Don’t wait for it to load to load everything else.” But sometimes that will break the functionality on your site, so it’s really a go through, see which ones you can move. [Laughs]

Lea Alcantara: [Agrees]

Emily Lewis: See what breaks. If you can’t move it, see if you can put (async) on it. See if anything breaks, and then if something is still breaking, it stays in the head and you simply accept that that’s what has to happen, because it’s rare that the client will have the budget for you to then figure out a JavaScript solution where you don’t have to call the JavaScript in the head when you’re dealing with performance.

Lea Alcantara: Right.

Emily Lewis: Because it can become a rabbit hole and you have to know when to stop, unless you want to go bankrupt as an agency. [Laughs]

Lea Alcantara: [Laughs] Absolutely.

Emily Lewis: You can certainly do that. Another thing that I spotted on this site was too many requests, too many JavaScript calls, too many CSS calls, and in fact, from what I can gather, not being someone who uses Bootstrap, but so much of this was tied to the Bootstrap framework.

Lea Alcantara: [Agrees]

Emily Lewis: And wanting to pull the modules from the framework and calling every JavaScript and CSS for a module independently, and it was a huge mess, and it also slows things down, and so really the solution for that is you combining your scripts and your CSS files where you can, and if you’re using a compiler or a pre-processor or even like Dan Tello talked about with his build automation tools, that can just happen for you without you doing anything.

Lea Alcantara: Right.

Emily Lewis: You can work with your independent source files, but then they’re all compiled into one, which is just one request. So the challenge though with that is kind of like the challenge I was talking about moving render-blocking scripts out of the head. Sometimes you just can’t. For example, with this client, they have a home page slide show, and it’s very bulky in terms of the assets that it’s relying on, and I know that I’ve used something that’s a lot leaner that we could rely on and I wanted to replace it. Unfortunately, removing the original slide show stuff, because it was so dependent on other modules tied to Bootstrap caused a cascade. It’s an issue that we couldn’t address within the budget, and so we kept the slide show as it was.

Lea Alcantara: Right.

Emily Lewis: And informed the client of why and we said, “We’d love to replace this, but it’s going to take a much bigger effort than you are planning for right now.” I think that’s the hard part of this work.

Lea Alcantara: [Agrees]

Emily Lewis: It’s that you’re finding problems and not all of your solutions are easy and quick and cheap.

Lea Alcantara: Yeah. And at the same time too, like also keeping in mind like is there a bigger scale redesign in the future?

Emily Lewis: Right.

Lea Alcantara: And would the budget be better served to be saved for that as opposed to fixing this one particular issue? I don’t know if that’s going to bring the money in or further their brand or anything like that.

Emily Lewis: [Agrees]

Lea Alcantara: So those are always the types of conversations you have with your client.

Emily Lewis: The last two things weren’t biggies, but they’re pretty much any site can benefit from them.

Lea Alcantara: Absolutely.

Emily Lewis: First of which is gzipping, which is essentially compressing your local assets where you can. For us on this particular client, that’s just managed in their .htaccess file. For our other client, Client B, they’re the ones who are on the IIS-PHP sort of thing. It was a little bit more work, but we collaborated with their IT guy and essentially the same compression was able to be specified in the application host config file.

Lea Alcantara: [Agrees]

Emily Lewis: And then the last thing that I know it was an issue on this Client A site was, that you see in the performance test was recommending to serve your images from a content delivery network.

Lea Alcantara: [Agrees]

Emily Lewis: And the solution is to move stuff to a CDN. The challenge, and this is true for both of our clients, is that this is an additional cost that neither one of them were interested in incurring, and so it’s one of those things that we noticed, but we didn’t address.

Lea Alcantara: Yeah, and for the other client, I want to mention our Client B, we actually tested implementing that with that client.

Emily Lewis: Oh, right.

Lea Alcantara: Not necessarily for the ongoing cost, but remember how earlier in the show, we were talking about administrative cost.

Emily Lewis: [Agrees]

Lea Alcantara: It’s like the staff cost. So when we were testing the CDN for Client B, it saved some time, but it wasn’t dramatic enough that the increase in administrative overhead in terms of having to train them on making sure that they use this new add-on that hooks up to Amazon S3, that hooks up to Cloudfront, that does this, that or the other, and if there’s always ongoing changing, did they understand that they have to rename files, or their cache breaks, and on and on.

Because there are a lot of things that you have to discuss with the client about cache breaking, about uploads, where it’s going, and then you have to, especially for a larger organization, predict the cost of these items, and depending on what the system is, whether it’s like Amazon or some like other thing like CloudFlare or whatever. Some are just ongoing monthly cost with like a max cap and the other ones are per use, and that’s hard to predict too.

Emily Lewis: [Agrees]

Lea Alcantara: And so with all of those particular headaches, we were like, “Well, we can put this in here, but we personally think that this is actually going to add administrative overhead to your stuff, and based on the speed test we did when we did add a temporary CDN to see how the page loaded, the increase in page load wasn’t significant enough for me to say like, ‘Yeah, we need to have this.”’ It just wasn’t.

Emily Lewis: Just it wasn’t worth straight up.

Lea Alcantara: Yeah, exactly. It was cost benefit analysis essentially.

Emily Lewis: Right. Well, okay, so that was all of the front-end stuff for that Client A, the add-on Frankensite. [Laughs]

Lea Alcantara: Yeah.

Emily Lewis: Why don’t you talk about the monitoring that we’re doing using New Relic to keep an eye on EE and how we’re resolving the EE back-end issues we find.

Lea Alcantara: So earlier in the show we were talking about the importance of stability and speed.

Emily Lewis: [Agrees]

Lea Alcantara: So we established earlier there were a lot of issues with site’s performances are related to all the pillars of the site. So for our monitored Client A we wanted to prevent emergencies by keeping on top of any issues that could come up before they even occur, before there’s even a big traffic push.

Emily Lewis: [Agrees]

Lea Alcantara: And also, as our last episode on quality assurance pointed out, a fix can create or uncover a new host of issues.

Emily Lewis: Yeah.

Lea Alcantara: So through monitoring, we try to make sure that site is as stable as it can be.

Emily Lewis: [Agrees]

Lea Alcantara: And being on top of things.

Emily Lewis: And are you checking every day?

Lea Alcantara: No. Basically, once the site is stable, when it was the emergency situation, I think we were checking it essentially like once a day to see what’s going on.

Emily Lewis: [Agrees]

Lea Alcantara: And also because each fix we wanted to see whether it’s continued, et cetera.

Emily Lewis: [Agrees]

Lea Alcantara: But like once the site is stabilized, now that this particular client we’re just checking it once a week.

Emily Lewis: Okay.

Lea Alcantara: Yeah. And as the marketing campaign comes on. So usually once a week, we just do an overall view, kind of a temperature check, and then if the client says, “Okay, on this day, this is going to happen,” then I check what happens, what it looks before and what looks after, and then a few hours after.

Emily Lewis: [Agrees]

Lea Alcantara: Because sometimes you don’t notice the mistakes until more data is on New Relic.

Emily Lewis: Right. You know, it just occurs to me as well, this is less about performance and more about, I guess, a workflow, but anytime we release a new change on the live site, you check New Relic after that just to make sure.

Lea Alcantara: Yeah, right.

Emily Lewis: If something that you know they wanted a landing page feature and we changed the category assignments or something like that in EE, so you’re also checking them.

Lea Alcantara: Right, right, right. To just give you like a real-world example why that’s important is sometimes we push something and we upload the dev .htaccess, which has certain things hidden.

Emily Lewis: Ah.

Lea Alcantara: And then there’s the live .htaccess where those things need to be unhidden, and we had overwritten the wrong thing.

Emily Lewis: [Agrees]

Lea Alcantara: And so the site was working, but then New Relic was like showing like something is slow.

Emily Lewis: [Agrees]

Lea Alcantara: Something is going weird, and because we checked right after was how we were able to figure out like, “Oh, when we were doing the switcheroo, we shouldn’t have overwritten the .htaccess because they were separated the templates.” Yes, but like the .htaccess we had to keep them separated because they had different hidden configurations, depending on what the environment was.

Emily Lewis: [Agrees]

Lea Alcantara: So that was kind of like a must for New Relic essentially, and yeah, the magic of New Relic really is that it really shows you what happens within five minutes of the launch too.

Emily Lewis: [Agrees]

Lea Alcantara: So if you notice that it is slower post-launch, that’s like, “Well, that’s weird.” [Laughs] “That shouldn’t have happened.” So it allows you to dive deeper sooner than your client giving you a phone call saying something is wrong.

Timestamp: 00:40:09

Emily Lewis: Right. So that’s how we’re monitoring and kind of why.

Lea Alcantara: Right.

Emily Lewis: So when you do spot an issue, how are we tackling these problems?

Lea Alcantara: Well, first of all, clients have constraints, which include limited budgets or resources.

Emily Lewis: Right.

Lea Alcantara: In an ideal world, I’m sure every dev will be like, “Let’s rebuild this from scratch using modern techniques.”

Emily Lewis: [Laughs]

Lea Alcantara: Especially because some of the reasons why sites are slow, because how sites were built five years ago are different than they are now.

Emily Lewis: [Agrees]

Lea Alcantara: And on top of that, with Client A, you have multiple vendors going through your site who found new things that were just simply bolted on versus thoughtfully considered just so a page or initiative is pushed through.

Emily Lewis: [Agrees]

Lea Alcantara: So for this particular client, per campaign basis, it’s one piece by piece one. Because they’re very constrained, we’ve just done a lot of caching.

Emily Lewis: [Agrees]

Lea Alcantara: It’s a band aid solution, but it’s a good band aid solution. [Laughs]

Emily Lewis: We will talk about that, because I know that we’re just not doing one type of caching. We’ve got really custom granular caching going on.

Lea Alcantara: Right. And it changed over time. Like for example, last year when we started doing some emergency work and things like that, we just did caching of the navigation item.

Emily Lewis: [Agrees]

Lea Alcantara: For example, the footer and the main navigation because they were all dynamically being generated, so that was step one, and that helped a lot because navigation and footer is in every single page, but as this client has matured and their needs have increased especially, earlier in the show we were talking about how, “Okay, two times visits versus ten times versus twenty times of visits are different.

Emily Lewis: Right.

Lea Alcantara: So last year, just caching the navigation and a few elements per page was enough.

Emily Lewis: [Agrees]

Lea Alcantara: But this year, they were like ten times the speed and again, they were having issues with the site not doing very well.

Emily Lewis: They had just more aggressive marketing this year.

Lea Alcantara: Yeah, yeah.

Emily Lewis: [Agrees]

Lea Alcantara: Way more with way more promos, all that fun stuff, and the fixes that we had last year for the caching stuff, the granular caching, was no longer enough. So with that particular client, we started figuring out which pages needed whole page caching. That means the entire page needs to be cached now, and then the next step after that, which can be static cached.

Emily Lewis: [Agrees]

Lea Alcantara: So that’s the best part. Again, in an ideal world, all the pages are static.

Emily Lewis: [Laughs]

Lea Alcantara: That means there’s no longer touching the database. It’s just literally a flat file, like once it’s been generated, so the caveat is the page needs to be generated, first and foremost, so you still have like the initial speed hit.

Emily Lewis: [Agrees]

Lea Alcantara: But you can address that with workflow issues with your clients that they should be the ones that visits the page first after it’s been made, but as I mentioned, that’s a workflow issue, and so not all pages need to be static cached.

Emily Lewis: Right.

Lea Alcantara: So we had to identify the most important pages that needed to be static cached and the other pages that just need whole page caching and just needs to ping the database that one time.

Emily Lewis: [Agrees]

Lea Alcantara: And because the whole page is cached, it’s not doing multiple queries for that page anymore, but it’s doing the one query to just pull that one page.

Emily Lewis: [Agrees]

Lea Alcantara: So for that particular client, that really helped the speed, especially because they have a constrained budget and they have constrained resources. Ideally, as I mentioned, it would have been to rebuild more of the site so that before caching, the site itself is already performing well.

Emily Lewis: [Agrees]

Lea Alcantara: But if you have limited constraints, first and foremost, cache your page.

Emily Lewis: Yeah. Well, I think that gives a very perfect segue way to talk about Client B where we were, like I said, having a really dedicated performance project and could actually rebuild.

Lea Alcantara: Right, exactly.

Emily Lewis: And I think we talked about it earlier, the whole thing started was their home page was super slow.

Lea Alcantara: Right. And because we weren’t doing any emergency situations, we were able to do a bit of a major rebuild for critical parts of their site and caching.

Emily Lewis: [Agrees]

Lea Alcantara: So that’s really the ideal, is being able to rebuild things based on modern techniques and new features on an upgraded site, et cetera, plus caching that, so that regardless whether a page is cached or a template is cached, it’s going to be fast and it’s going to be even faster if it is cached.

Emily Lewis: [Agrees]

Lea Alcantara: So that is ideal. But you know kind of like I mentioned with Client A, it’s about prioritizing everyone’s expectations about administrative bandwidth and what content needs to be shown.

Emily Lewis: Right, right. Well, let’s talk then a little about this Client B and how we tackled it because it was a lot more planned in the sense of it’s not ongoing and responding to things we see, but we had a defined beginning, a number of pages to tackle, and a defined end.

Lea Alcantara: Right.

Emily Lewis: So just as with Client A, we did take a look at the front end, and when we had our initial discussion with this client about their home page, their IT guy was like, “I’m sure it’s JavaScript. I’m sure there are some…”

Lea Alcantara: Right. [Laughs]

Emily Lewis: And I was agreeing with him. I was like, “I’m sure that this is something tied to the front-end that we can take a look at.” [Laughs]

Lea Alcantara: Right.

Emily Lewis: Lo and behold, after all of the tests that we ran it through, the front end was really not that bad.

Lea Alcantara: No.

Emily Lewis: That probably, if left alone, the front end probably wouldn’t cause any problems. It was mostly EE, which I’ll have you talk about. I will just mention the few front-end issues that we did find where the same ones that we noticed in Client A.

Lea Alcantara: Right.

Emily Lewis: Again, this is the stuff that really does seem to be common. Images were a problem, gzipping, having to add that, moving render-blocking scripts out of the head where we could, and reducing extra requests, and in fact, this client was able to remove some of those tracking scripts that they weren’t using anymore, which also made a big difference. But we could have ignored front end and still had great results with this project because so much of it was tied to EE.

Lea Alcantara: Right.

Emily Lewis: So Lea, why don’t you talk a little bit about the overwhelming EE issues that you saw with this particular Client B build?

Lea Alcantara: Right. So it’s all embeds. [Laughs]

Emily Lewis: Yeah. [Laughs]

Lea Alcantara: Like in this entire show could be summarized in one sentence, “Don’t use embeds unless you need them.”

Emily Lewis: [Agrees]

Lea Alcantara: Embed tags aren’t evil, okay? They are necessary for certain uses.

Emily Lewis: [Agrees]

Lea Alcantara: But excessive use of embed tag is just an awful way to build a site for performance issues. That being said, that was what we used to do five years ago to make a site a lot more DRY (Do not Repeat Yourself).

Emily Lewis: Yeah.

Lea Alcantara: Because then you can segment certain pieces of code and it’s a lot more efficient, but what’s efficient for a developer isn’t necessarily efficient for the site to build.

Emily Lewis: Good point.

Lea Alcantara: And again, maybe back then, they didn’t have as much traffic so they weren’t as much issues.

Emily Lewis: And five years ago, they probably weren’t as concerned about mobile five years ago, you know?

Lea Alcantara: Yeah, exactly.

Emily Lewis: People’s expectations were so different as users.

Lea Alcantara: Right. And the reason why an embed is an issue is that we mentioned the queries. Each embed can have multiple queries because it’s essentially like inserting another template within a template within a template and then so it’s kind of…

Emily Lewis: Inception.

Lea Alcantara: Yeah, exactly.

Emily Lewis: [Laughs]

Lea Alcantara: It’s literally inception. So for example, one page had 14 embeds and none was necessary.

Emily Lewis: [Agrees]

Lea Alcantara: Like once we reviewed it, it was like zero, none of this needed to be an embed. It didn’t need the features that an embed had. So trying to figure out how we can replace that with more elegant solutions, usually just moving them to Low Variables or just copy pasting it directly into the template was a better solution already.

Emily Lewis: [Agrees]

Lea Alcantara: Now, some of the other templates were using PHP to output.

Emily Lewis: [Agrees]

Lea Alcantara: Now, earlier in the show, you mentioned upgrades.

Emily Lewis: [Agrees]

Lea Alcantara: Upgrading to the latest version often solves a lot of problems because if you’re using a five-year-old system, there are new things that you can do now that you weren’t able to do before. So certain templates probably had custom PHP because those add-ons didn’t exist, that functionality didn’t exist five years ago, so they had to custom code it, but that makes an issue when rendering a page.

Emily Lewis: [Agrees]

Lea Alcantara: So we tried to remove as much custom PHP as possible that was not necessary and then we use native functionality. It was a lot more efficient, and that saved a lot of time.

Emily Lewis: [Agrees]

Lea Alcantara: Lack of proper caching in general. There was no caching really in the page. It was like they turned on the default template caching for 60 minutes.

Emily Lewis: [Agrees]

Lea Alcantara: That really isn’t that efficient. In regards to it, there are like new ways to do caching. Specifically, we use Stash on both our clients to good use. I do know that CE Cache is really popular as well, but the experience we’ve had with Stash has been fantastic with both clients.

Emily Lewis: And I think that’s because of Mustash, right?

Timestamp: 00:49:56

Lea Alcantara: Right. So Mustash is the commercial add-on to Stash. Stash itself is the one that caches the pages and actually does the bulk of the work, and Mustash is the administrative add-on that allows you to do automatic clearing based on action, which is really fantastic for admins and a clear way to show what has been cached, like whether a page has been cached or whether just a part of the page has been cached, and then you can, instead of clearing the entire cache, you can granularly delete, say, a page cache or just an app or this or that or the other, and then you can set up rules where, “Well, if we update this entry, then this page cache will completely be cleared or deleted, or a cascade of several pages will be deleted because this module affects all these pages.”

Emily Lewis: [Agrees]

Lea Alcantara: So Mustash is really useful for that.

Emily Lewis: And specifically for the client.

Lea Alcantara: Yeah.

Emily Lewis: I mean, it’s useful for you and me.

Lea Alcantara: Right.

Emily Lewis: But because performance is so critical to both of these projects and the client is on board with that, you are introducing new things to their workflow.

Lea Alcantara: Absolutely.

Emily Lewis: And the first and foremost one is having to understand what caching is and how to clear it, and having this Mustash dashboard in ExpressionEngine gives them a view.

Lea Alcantara: Right.

Emily Lewis: We give them training and we give them documentation, but they also have this control panel view that makes it pretty clear what’s been cached, how you could clear a given cache, et cetera.

Lea Alcantara: Right. And you can drill down to even see what’s inside that cache template if you’re troubleshooting and trying to figure out what’s going on here, if that needs to be deleted, et cetera and so forth.

Emily Lewis: [Agrees]

Lea Alcantara: Like Stash in and of itself again, is by itself is great, but unless you’re someone like me and Emily, like before both clients had the budget to really tackle caching properly, I would go into Sequel Pro and go into their actual database, find the Stash table, find the row and manually delete it, so I wouldn’t clear the entire cache.

Emily Lewis: [Agrees]

Lea Alcantara: So that’s pretty freaking technical [laughs] to understand exactly how to do that without bringing the entire site down, right?

Emily Lewis: Right.

Lea Alcantara: So investing in Mustash is I think a must if you decide to use Stash as your caching tool, and I will just also plug Mark Croxton, a fantastic developer, with great response time to any questions, et cetera and so forth.

Emily Lewis: Yeah, a good guy.

Lea Alcantara: Yeah. And then finally, in terms of other EE stuff, so we talked about embeds, we talked PHP and we talked about lack of proper caching, resource-intensive add-ons.

Emily Lewis: Yeah.

Lea Alcantara: So that was a major issue. Try to build your site as natively as possible. Add-ons can add so many more queries that aren’t even necessary to every page, even if it isn’t being called.

Emily Lewis: [Agrees]

Lea Alcantara: That’s the crazy thing, right?

Emily Lewis: Yeah. What is the one?

Lea Alcantara: Better Workflow.

Emily Lewis: Oh, Better Workflow.

Lea Alcantara: Yeah.

Emily Lewis: We’re not even using it on some pages, but it’s still being called.

Lea Alcantara: Right, right, yes.

Emily Lewis: [Laughs]

Lea Alcantara: So for example, with Better Workflow, you can set it up so that it only works for specific channels, but regardless of what page you’re viewing, it will load Better Workflow. [Laughs] It will load it. Another thing that was intensive, and I guess this is the discussion we have with the client, it’s like in terms of workflow, they had CE Image installed because they wanted to create multiple images on the fly so they can have like responsive hero images on all pages just created as the page loads.

Emily Lewis: [Agrees]

Lea Alcantara: As the page loads…

Emily Lewis: Oh.

Lea Alcantara: So what that means is that client uploads this giant 2,000 pixel image and then the first time this hero image generates the multiple images for responsive devices is when a visitor/user/your client/customer visits the page…

Emily Lewis: It’s insane.

Lea Alcantara: And then so the database needs to be called, then the FTP/server has to talk and those images need to be generated. Well, in concept, it’s great, like wow, so then the client doesn’t have to manually create these multiple images. All these images are on the fly, but it’s so resource-intensive to the database and server.

Emily Lewis: [Agrees]

Lea Alcantara: And also largely necessary now because natively EE can create multiple images on the upload side as opposed to the page load side.

Emily Lewis: Yeah.

Lea Alcantara: So if you upload something using the file manager in EE or just like a file field, you can set it up so that it can also generate different hero sizes once you’ve uploaded it.

Emily Lewis: [Agrees]

Lea Alcantara: And then through the template, you just mention, “Okay, if using your queries or whatever, if it’s this size, serve the smaller image or serve this bigger image, et cetera.”

Emily Lewis: [Agrees]

Lea Alcantara: So getting rid of that and using the native functionality really, really helped.

Emily Lewis: So we’re already almost at the hour mark. I do want you to talk a little bit about actually what we did. So you found out what the main EE issues are, so let’s talk a little bit about how we tackled them, and I think the first thing to mention is planning it, prioritizing all of this stuff. So all the front end and all the EE, how do you decide what happens when and what’s most important?

Lea Alcantara: Right. So I feel like the first thing is narrowing down the issues that’s page specific and what’s global.

Emily Lewis: [Agrees]

Lea Alcantara: Like what’s something that only that page is dealing with and what can be dealt with that has a bigger impact, and then once we narrow down those particular workflow issues or like the multiple things, page specific and global, you figure out which is the easiest to be hammered out and implement them right away. So the stuff that like, “Okay, so we can just delete this, fine, delete it.” And then what affects the database is really the most important thing. So like once you’ve had that list of pages and like, say, global elements like navigation that you list that you’re looking for, if you’re making a change, does that need version control? Does that need some sort of content redundancy on the client’s part and discussion over where hand-overs happen? Right?

Emily Lewis: Yeah. In fact, I think that was a big part of this project that was really successful.

Lea Alcantara: Absolutely.

Emily Lewis: Because we prioritized the changes we were going to make to tackle all the ones that we could do locally without them having to put a content hold on their live system.

Lea Alcantara: Right.

Emily Lewis: Or doing content redundancy procedures where they’re tracking content live, that they can later enter into the new development system.

Lea Alcantara: Right.

Emily Lewis: So we tackled a bunch of stuff before we even had to ask them to do that.

Lea Alcantara: Yeah.

Emily Lewis: Which is good because their perception of their inconvenience was smaller than if we were like, “You know what, this is going to take us a month. You’ve got to be out of your system for a month.”

Lea Alcantara: Right.

Emily Lewis: That’s unreasonable.

Lea Alcantara: It was important to us that we prioritize what we could tackle without any issue for them.

Emily Lewis: [Agrees]

Lea Alcantara: And then we listed off the order of all the EE improvements from essentially the easiest, just like the stuff that we said like, “What can we tackle right away and delete?” And then we tried to figure out, “Okay, so what’s the easiest?” Optimizing queries, for example, like adding dynamic=“no” or the entry ID to a single entry page, that’s very simple. That’s just doing that to all the affected templates, and then we go down the list to more all-encompassing changes like replacing the embeds with alternatives or copy-pasting the code, and then even bigger changes. So with embeds being the old school way of EE development, we still wanted to make things DRY because, okay, it’s easy to copy paste the old template code just into the template, but that is hard to maintain for anybody.

Emily Lewis: [Agrees]

Lea Alcantara: So in the newer versions of EE, EE Layouts exists. So that’s a major way of making code snippets way more efficient without having to use embeds anymore. So we use a mix of EE Layouts and Low Variables to replace all the previous embeds, so all the code snippets were still quite maintainable, but it’s a lot more efficient.

Emily Lewis: [Agrees]

Lea Alcantara: And then finally, we put together a caching plan that would allow the most flexibility for admins while keeping the site as fast and nimble as possible.

Emily Lewis: I think what’s just really interesting is that we’re essentially able to achieve the same goals for both of these clients because we’ve made significant improvements in their page speeds.

Lea Alcantara: Right.

Emily Lewis: But with totally different approaches.

Lea Alcantara: Right, absolutely.

Emily Lewis: I mean, not just in the fixes, but having a dedicated project was really fun because it’s so controlled, but it’s also really fun to have to anticipate what’s going to happen this week because there’s a new campaign.

Lea Alcantara: Right. And the thing about speed and performance to testing is that there’s very clear before and afters.

Emily Lewis: Yes. I think that’s the part we haven’t quite mentioned yet, and I want to make sure we do before we finish up. For this particular client that Lea was describing, this Client B, once we finished all the changes and we then ran all the pages through all of the same performance tests in the beginning and gathered the numbers for an after picture, and then we compiled a really detailed report that used charts and graphs to really show the improvement in page speed and other benchmarks, and no joke, what did he say? “I’m beyond thrilled” or something like that. [Laughs]

Lea Alcantara: Yeah, yeah, I know. Well, actually, what made me laugh as he said this, he started to jump around. [Laughs]

Emily Lewis: [Laughs]

Lea Alcantara: I was like, “That is the most satisfying response from a client ever.” [Laughs]

Timestamp: 01:00:01

Emily Lewis: And so it’s worth in your projects to factor in this extra time to do this post-analysis and testing.

Lea Alcantara: Absolutely.

Emily Lewis: Because it really underscores the value you brought to the project.

Lea Alcantara: Absolutely.

Emily Lewis: And with this project, we’ve really only tackled a handful of key templates on their site. It affected several hundred pages on their site.

Lea Alcantara: Right.

Emily Lewis: But there are still other pages that should be looked at, and so that before-and-after analysis also serves as “ammunition” for the IT director to go ask for budget spend for next year.

Lea Alcantara: True.

Emily Lewis: So there’s value in that. It’s budget spend that they will hopefully spend with us. [Laughs]

Lea Alcantara: Absolutely.

Emily Lewis: It’s a sales tool.

Lea Alcantara: As well, vagueness doesn’t help the sales process or client satisfaction after the project is done.

Emily Lewis: Right.

Lea Alcantara: So making sure you set clear parameters to what you’re testing and what the expectations are after the fixes were done is really important.

Emily Lewis: [Agrees]

Lea Alcantara: That’s why a before and after is super important. Something that we also did was we kind of undersold what the after might be as well for, one, to cover our ass. [Laughs]

Emily Lewis: Yes.

Lea Alcantara: And for the other, if we go above and beyond that, you get that thrilled reaction from your client.

Emily Lewis: [Agrees]

Lea Alcantara: Now, the other thing too is like whenever you do before and after, you really, and this is like you as a professional have to listen to a client’s needs and that means the entire team, so when you are setting these parameters and setting these expectations, sometimes somebody in the team doesn’t think a particular page or a particular optimization wasn’t even all that important.

Emily Lewis: [Agrees]

Lea Alcantara: But I’m thinking about this particular client, when we showed them the after, the team’s director specifically called out the page that was dismissed earlier.

Emily Lewis: [Agrees]

Lea Alcantara: Because everyone was so focused on the home page, right?

Emily Lewis: Yeah.

Lea Alcantara: And that’s important obviously, but because we listened to the client and we took into account the entire team’s feedback, we really put in a lot of effort on all the pages, and we didn’t dismiss any of the ones that’s less important than the other, like we gave it the same amount of effort.

Emily Lewis: [Agrees]

Lea Alcantara: The home page the same amount of effort as the other pages as well, and then that gave an overall improvement throughout the entire site.

Emily Lewis: So as we wrap up… Lea, what are your lessons learned about ExpressionEngine and performance that you think everyone should know?

Lea Alcantara: So really, be careful with your queries and how you build your site in the first place. [Laughs]

Emily Lewis: [Laughs]

Lea Alcantara: I feel like this is almost ExpressionEngine 101, use native EE functionality.

Emily Lewis: [Laughs]

Lea Alcantara: Because there are a lot of built-in features and sometimes, add-ons may seem convenient, but it can add a lot to the load time. Caching is a great band aid solution that you should use, but you shouldn’t stop there. The site itself should be built properly and anything else you do makes it even better as opposed to a fix.

Emily Lewis: [Agrees]

Lea Alcantara: And there are situations where a page cannot be cached, like if you’ve got log-in situations, right, like if you’ve got membership stuff or if you’ve got search, anything that needs to be dynamic, so an entire page cannot be cached or not caching completely.

Emily Lewis: [Agrees]

Lea Alcantara: So if you build the rest of the page well, then the page and the site overall will be faster.

Emily Lewis: Right.

Lea Alcantara: So yeah, I really want to emphasize that, because I’m like, “Yeah, just cache the page.” Well, depending on your site. You can’t…

Emily Lewis: [Agrees]

Lea Alcantara: You might not be allowed to. You might not be able to because of those dynamic elements.

Emily Lewis: [Agrees]

Lea Alcantara: So Emily, we spoke a lot about EE. What are your final front-end lessons?

Emily Lewis: Well, interestingly enough, it just goes back to EE.

Lea Alcantara: Oh.

Emily Lewis: Like I said earlier, don’t assume it’s all front end.

Lea Alcantara: [Laughs] Right.

Emily Lewis: Within our industry, you really do see all of the talks about performance are very focused on the front end, and as I described, there are a lot you can do to improve, and the bonus, most of the time it happens globally, but like we saw with our Client B, the front end was really negligible compared to the impact the CMS had, and though we focused on two of our EE clients in this episode, this is not an EE issue, this is a CMS issue, CMSs that rely on a database.

Lea Alcantara: Right.

Emily Lewis: As Lea was describing, every time you’re clearing the database, that’s a back and forth conversation that slows things down. WordPress themes and plugins can severely compromise speed.

Lea Alcantara: [Agrees]

Emily Lewis: Drupal is actually known to not be performance friendly and requires a lot of customization to get things speedy, and same with Joomla. So this is one of those things that if you’re building sites on any CMS and your client cares about performance and nowadays, I think you’re going to start seeing this, you need to know how to make your CMS output as efficiently as possible.

Lea Alcantara: Right.

Emily Lewis: And if you don’t want to deal with that, then you need to work with a flat file solution like Kirby or Statamic or something. [Laughs]

Lea Alcantara: [Laughs]

Emily Lewis: Without a database, you’re going to have far fewer bottlenecks.

Lea Alcantara: Yeah, absolutely, absolutely.

Emily Lewis: I did have a couple sort of other thoughts that aren’t really EE or front end that I did want to mention before we finish up, and I think the first one is that I don’t believe perfection is possible with this kind of work.

Lea Alcantara: Absolutely.

Emily Lewis: For front end, there are business or display reasons why you have a render-blocking script in the head or tracking script that has to be in place, so those are going to be penalized in a test, but you have to have them from a bigger, including EE, perspective. There are a budget and timing reasons why something can’t be addressed, and so a lot of performance isn’t just production work, but it’s also focusing on educating the client about why you can or cannot address something.

Lea Alcantara: [Agrees]

Emily Lewis: And also having the experience to know when it’s okay that you fail the test. It’s kind of like Lewis (Francis) was talking about in our Quality Assurance episode. Sometimes failing a test is just fine. You know the client, the budget and the environment, and so you have to balance your performance test results with the reality.

Lea Alcantara: Yeah, absolutely. I just also wanted to point out with the EE back end in terms of perspective, about budget and timing reasons, there are administrative reasons. Part of the reasons why a page or an entry might be slow is because a client really demands and needs to have all this customizations.

Emily Lewis: [Agrees]

Lea Alcantara: It needs to have all the fields. Well, if that’s the reality, that’s just going to take time, right?

Emily Lewis: Yeah.

Lea Alcantara: So that’s hard to change unless they really decided, “I’m not going to customize a much.”

Emily Lewis: Well, I think that is a good place to start. It’s a pretty deep topic.

Lea Alcantara: [Agrees]

Emily Lewis: And there are a lot you can do to make the process smoother and make client collaboration better, but these are the basics that we’ve learned and will hopefully help anyone else who’s working with a performance project, especially EE, but I really do think all of these lessons can be applied to any CMS.

Lea Alcantara: Yeah, absolutely. Man, and we didn’t cover enough. [Laughs] But…

Emily Lewis: No. I mean, we totally has skipped over huge chunks of notes. [Laughs]

Lea Alcantara: Yeah, absolutely, but we should end now with our Rapid Fire Ten Questions.

Emily Lewis: Yeah.

Lea Alcantara: But since both Em and I have answered our set of questions for this year, we’re going to answer a few questions that do make the cut this year. Who knows? Maybe they’ll be on next year’s list. Are you ready?

Emily Lewis: Yeah, okay.

Lea Alcantara: What is one of your pet peeves?

Emily Lewis: Okay, I have this one at the tip of my tongue because I think it every morning on my walk.

Lea Alcantara: [Agrees]

Emily Lewis: Dog owners who don’t leash their dogs in community spaces.

Lea Alcantara: [Agrees]

Emily Lewis: I cannot stand it and I say something about it every time. [Laughs]

Lea Alcantara: Yeah, that’s not cool. I mean, like you can think that your dog is perfectly fine, but they’re still an animal, and I love animals and I love dogs. Leash your pets please.

Emily Lewis: There are so many reasons for it. I won’t even go into them all, but there are so many reasons, and it drives me insane every morning. [Laughs]

Lea Alcantara: Umm…

Emily Lewis: How about you, what’s one of your pet peeves?

Lea Alcantara: Oh, people who post weird memes on Facebook that’s clearly bonk like, “What is this holistic kind of weirdness that you’re just…” Come on now. No, please no.

Emily Lewis: [Laughs] All right, how about how many stupid domains do you own?

Lea Alcantara: I don’t really own that many stupid domains. I think at one point, I had like a ton of different like self-branding ones. [Laughs]

Emily Lewis: [Laughs]

Lea Alcantara: And then afterwards, it’s just… no, I feel like it’s just down to lealea.net.

Emily Lewis: Yeah, same here. I think in my early to mid-30s, I was like collecting domain names, and every time Jason and I would have some internal joke where we’re like, “That’s a great domain name, let’s buy it.” It’s absolutely ridiculous.

Lea Alcantara: [Agrees]

Emily Lewis: But I’ve pared it down to just business-related domains.

Lea Alcantara: Okay. So are you into comics?

Emily Lewis: Eeh.

Lea Alcantara: Oh, all right.

Emily Lewis: [Laughs]

Lea Alcantara: Hold on. Do you have any skin in the game for Marvel versus DC?

Emily Lewis: Only from the movies.

Lea Alcantara: [Agrees]

Emily Lewis: And I don’t know if that’s a fair response to true comic lovers, but I prefer Marvel.

Lea Alcantara: Oh. Oh.

Emily Lewis: But it’s because the movies for DC have really disappointed me.

Lea Alcantara: Yeah, ditto, ditto. I feel like, “Ah.”

Emily Lewis: Ben Affleck was a bad decision.

Lea Alcantara: Ben Affleck, no, uh.

Emily Lewis: [Laughs]

Lea Alcantara: Yeah, yeah. For me, I feel like, uh… I mean, I’m into comics, but I don’t know if I want to say like, “Oh, I prefer one versus the other,” because both have had like good and bad, like I prefer the Nolanverse of Batman with DC kind of thing in the movies.

Emily Lewis: [Agrees]

Lea Alcantara: But I used to love the X-Men and all those kinds of things, which I believe is Marvel, although that’s owned by…

Timestamp: 01:10:00

Emily Lewis: So you’re on the fence?

Lea Alcantara: Yeah. I mean, I feel like Marvel is more fun, especially like in the movies and things like that.

Emily Lewis: [Agrees]

Lea Alcantara: But meh…

Emily Lewis: Yeah, I think DC Comics has that history of tackling social issues.

Lea Alcantara: Right. Well, Marvel too, like except like through the mutants and Spiderman and all those kinds of things.

Emily Lewis: [Agrees]

Lea Alcantara: But eh… I feel like I’m getting… I used to love them, but like there are just so much that you’re just kind of getting tired, yeah.

Emily Lewis: Yeah, exhaustion. All right, well, let’s see if you’re on the sense about this one, hotdogs or hamburgers?

Lea Alcantara: Hamburgers.

Emily Lewis: Yeah. I’m with you. I love a good hotdog, but I will never pass up a hamburger.

Lea Alcantara: Yeah, like Seattle hamburgers, like these hamburgers are so good. Here’s a plug to 8oz (Burger & Co). That’s my favorite burger place in Seattle.

Emily Lewis: [Laughs]

Lea Alcantara: It’s so great.

Emily Lewis: We don’t have a good burger joint here.

Lea Alcantara: So sad.

Emily Lewis: I know. Well, it’s Albuquerque, we don’t have much good food here. [Laughs]

Lea Alcantara: [Laughs]

Emily Lewis: All right, what’s your favorite season?

Lea Alcantara: Autumn.

Emily Lewis: Yeah, me too.

Lea Alcantara: Because it’s kind of like my birthday season because I was born in September, so that’s part of it.

Emily Lewis: [Agrees]

Lea Alcantara: But the other part is it’s like I love the turning colors and I love that it’s warm and starting to get cool, but it’s not too warm enough or too cold, yeah.

Emily Lewis: Yeah. I’m with you on all of that. I love the smell in the air.

Lea Alcantara: [Agrees]

Emily Lewis: And here in Albuquerque, anyone who’s from New Mexico knows what I’m talking about, right about now, there’s a crispness in the mornings, and then you smell the smell of roasting chili because that’s all starting right now. All right, last question.

Lea Alcantara: [Agrees]

Emily Lewis: I think this one is kind of hard and I don’t even know what my answer is, but how about you? What’s the best piece of professional advice you have received?

Lea Alcantara: Best piece of professional advice? Gosh, I feel this is so, so hard because I don’t know. Like it feels like it’s an overall thing that I’ve heard from a lot of people versus like one specific person that do this.

Emily Lewis: [Agrees]

Lea Alcantara: It’s to kind of really plan for your success, if that makes any sense.

Emily Lewis: [Agrees]

Lea Alcantara: Because thinking about just my career and all those kinds of things, when there’s momentum, like sometimes I’d drop the ball. Do you know what I mean?

Emily Lewis: [Agrees]

Lea Alcantara: And now, like especially we’re thinking about our own business and like how we’re dealing with things, it’s kind of like, “How do I pick up that momentum again?” Right?

Emily Lewis: [Agrees]

Lea Alcantara: So I feel like if you are on a high, just keep pushing. Don’t stop because you’re on a high. You have to keep hustling.

Emily Lewis: Right.

Lea Alcantara: How about you, what’s your best piece of professional advice?

Emily Lewis: I don’t know who told me this, it’s probably like you, it’s something I’ve just heard through the years, but it’s been one of those things that’s really helped me in running this business. It’s focus on yourself, run your own race because it does not matter what someone else is doing.

Lea Alcantara: Right, absolutely.

Emily Lewis: It doesn’t matter if you think they’re great, they’re not you, and if you are worried about trying to do what they’re doing or emulated in some way, you’re missing out on figuring out what you do that’s unique, and yeah.

Lea Alcantara: Yeah.

Emily Lewis: So whenever I start getting worried because I see someone is doing well and I’m comparing Bright Umbrella to where they are and I start getting bummed out, I just stop and say, “But wait, compare me to where I was three years ago.

Lea Alcantara: Yeah, right.

Emily Lewis: “Or five year ago.”

Lea Alcantara: Right.

Emily Lewis: “Compare me to me.” Yeah, that’s it.

Lea Alcantara: Yeah, that’s fantastic advice, I think.

Emily Lewis: And that brings us to the end of today’s episode. If you want to know more about performance, be sure to check out our show notes. We’ll have some links in there as well as a blog post we recently wrote about how performance affects marketing campaigns.

[Music starts]

And so it should be good resources for you.

Lea Alcantara: CTRL+CLICK is produced by Bright Umbrella, a web services agency obsessed with happy clients. Today’s podcast would not be possible without the support of this episode’s sponsor! Thank you, Backup Pro!

Emily Lewis: We’d also like to thank our partners: Arcustech and Devot:ee.

Lea Alcantara: And thanks to our listeners for tuning in! If you want to know more about CTRL+CLICK, make sure you follow us on Twitter @ctrlclickcast or visit our website, ctrlclickcast.com. And if you liked this episode, please give us a review on iTunes, Stitcher or both! And if you really liked this episode, consider donating to the show. Links are in our show notes and on our site.

Emily Lewis: Don’t forget to tune in to our next episode when we’ll talk to J. Cornelius about discovery-only projects. Be sure to check out our schedule on ctrlclickcast.com/schedule for more upcoming topics.

Lea Alcantara: This is Lea Alcantara …

Emily Lewis: And Emily Lewis …

Lea Alcantara: Signing off for CTRL+CLICK CAST. See you next time!

Emily Lewis: Cheers!

[Music stops]

Timestamp: 01:14:24