Full Transcript
Josh: Hi everyone. Welcome to KickoffLabs on growth. This week is going to be a founder chat where Scott and I talk about performance. We recently had a push to optimize the page speed and load times on the KickoffLabs' marketing site, application and the landing pages KickoffLabs generates for its customers. We learned a lot, and I wanted to share this information with you because it's going to help you build better landing pages with higher conversion rates, online stores that people want to shop at, and apps that people enjoy using because it just feels snappier. This is episode four, and I hope you enjoy it.
Josh: There's a note here to talk about what's new and I added that so I'll just start. In the last week, I started playing baseball again for the first time in three years. I am now extremely sore after playing one game on Sunday. So, I don't know if you have any advice for that, Scott.
Scott: Just motivation. Watching the Yankees really got you excited to get back into baseball?
Josh: Yeah, they do have team spirit. I'll give them that.
Scott: Now that I told you, I played basketball for the last couple of years, and then I think recently retired because kept getting injured and had no idea how I was getting injured. So, my recommendation is probably don't do it.
Josh: I'm going to see if I can avoid getting injured. Right now I'm just feeling the pain of doing something I hadn't done in a long time. So like I said, today we're going to talk to you about a performance. I want to talk about a little bit about why that's important to think about. And when I talk about performance, specifically in this episode, we're talking about a site speed, how long it takes a website or an app to load.
One of the reasons we looked at performance is a good 40% of our landing page views were coming from mobile devices. Especially people we were advertising to on Facebook.
Josh: And so, in this case, one of the reasons we looked at it is a good 40% of our landing page views of people coming to our marketing site were from mobile devices. And that was especially true for places that we advertise. So in ads, on Facebook and Twitter, people are coming over from mobile devices because while they're browsing those things, and that's where they're clicking the ads, and they may later come back and sign up on a desktop.
I want their first experience to be something that feels fast because I think that plays a lot into customer perception.
Josh: But I want their first experience to be something that feels fast because I think that plays a lot into customer perception. If something comes up slow, they're going to have a slow perception of your whole site, app, or your store. And that's based on some research. I used to work ages ago at Microsoft. I remember seeing the research that basically said, "If the application started slow, people thought the whole thing was slow." It didn't matter how fast that things actually were. But if this started slow, the perception is your whole thing was just not worth waiting for.
Josh: SEO is another good reason, Search Engine Optimization. Google does now start want ... They want to reward faster pages. And the last one is just consider that you as a founder, marketer on the Internet somewhere, you probably have a decently fast Internet connection. I know I do. What we see on the Internet, isn't necessarily the experience of a lot of your potential customers when they look at your store, or your app, or your landing pages there.
Scott: Or even your hardware performance, right? You probably, as someone who's starting a company, especially a web company, you probably have a newer computer. Like you said, a better bigger monitor, and those kinds of things. A better video card, or maybe you have a video card, and all those things can make your app seem quick, and seem fast and speedy. But to your typical end users, it's not.
Josh: Yeah, absolutely. That's a good note especially the thing about the hardware is I think both of us are unfairly recent high end Mac book pros, and that's probably not the case for a lot of people out there. So my first note, and this comes from looking at a lot of our own customer pages, and their landing pages, and what they're attempting to do is called, I say right size your images, big images equal a big download time.
Josh: I think what this comes from, or where I see it a lot with our customers is people go and they look for a stock photo of something to use. And these stock photo sites have started offering extremely large versions of the photo. I mean, versions of the photo you could print and put on a 25 foot tall billboard outside of Times Square when what you are using the photo for is maybe like a head shot on your landing page, or your website somewhere.
Josh: And that headshot is maybe 500 pixels, maybe thinking about it, looking at a website like an inch wide, and you're using a photo that's made to be 25 inches, or on a 32-inch monitor blown up and looked at. And that causes a lot of bandwidth, and the browser just stops, and it starts downloading these large images, and it causes people's pages to look slow. The images don't load, and then if there's text in front of the image, then that doesn't look right. That was my first big note.
Josh: Also, just introduce the first tool to help people check these things out. If you Google online, you just Google for the Google page speed analyzer. That's just a really simple tool. You can just enter in a website and it'll pull up a report that shows you a bunch of these other things we'll talk about, but also one of the top things it shows is images that are probably too big, and are taking up a lot of download time.
Animated GIFs are increasingly getting more complicated, and they're getting bigger (to put on pages).
Scott: The other images that ... I guess, somewhat more recent trends for images is the ... This might even be our first ... I can't even think of the way to say it. Our first decisive point or whatever is a GIF or GIF. Yeah, it would be the animate I say GIF. But animated GIFs, they are increasingly getting more complicated, and they're getting bigger. I think we had one customer. We were just trying analyzing our own logs, and then we just saw a big huge uptake in traffic, and it's just because someone had uploaded a massive GIF that they were using on their pages, and it was just eating a lot of bandwidth. I got to imagine that was a large file to be downloaded, and a slow file will be downloaded for a lot of end users.
Josh: Yeah, absolutely. And the tools to generate the GIFs definitely vary in terms of what kind of quality and spies they produce. I used a default tool. I use Droplr as a tool for taking screenshots. And started using that at first for some GIFs who were using for support, and then realized that it was doing such a high frame rate and resolution. Even short five-second little animated GIF was huge until I ... And I had to end up getting Camtasia, a much more larger tool, mostly for video editing.
Josh: But they had the control over the export of a GIF that would let me say, "I wanted it to be less than this size." It would say, "Okay. Well, you're going to have to reduce the resolution by this much, and reduced the frame rate by this much." But it helped me find a happy medium for the image that I wanted to help people with support.
Scott: Yeah. The website, Giphy, has a really nice site cause for a Mac app that has a lot of stuff like that. But even the same thing by default, the files it generates are huge, but there is control, if I remember correctly, to tune that into something much more realistic.
Josh: Onto you for our second point.
Performance optimization combines art and science.
Scott: So our second point we have listed is performances, art versus science. I think part of that what I was getting at is that, and you had mentioned this in your intro, is that a lot of it is just a perception of speed. So a couple of years ago we started using a tool on our main applications like TurboLinks. It just gives us a perception of pages loading quicker because you're not loading everything with the page. You're only loading essentially the middle part that changes. But then customers don't have to wait for the JavaScript files, and CSS and everything to be re-downloaded and parsed.
Scott: And so, nothing is really happening quicker on our servers. It's just quicker in a browser, and it gives that big performance our perception of performance. The other one was kind of like a walk back in time. We've been doing this now for about eight years. I remember when we first started making deployments to our main app, we were new. We were deploying all the times throughout the day. I remember I was trying to optimize on when to do deployments because it would take time for ... We used Rails behind the scenes. It would take time for our app to load, and we wanted it.
Scott: It's nothing we wee doing slow, but it's just every time we did a deployment, the whole app needed to restart, and it just made the pages feel like they were kind of dragging on. And that Heroku, who also we host on our app, had a feature that came out a while ago and now it's pretty standard. But it's called Preboot. That was the idea of we did a deployment, and Heroku would spin up our app on the side. And once it was ready to go, they would kind of then switch it out. And so for our end users, the app never slowed down. Everything kept going. It gave us the option to keep deploying throughout the day, and not having to think about, "Is now a good time to deploy? Or do we want to wait until five o'clock East Coast Time? Or we're going to deploy at five o'clock West Coast Time? Or overnight?" All those things that just make for a miserable experience.
Josh: It's interesting. As you press on the journey, there are different things you learned about how people, move through your app, and use your app, and where you've got the bottlenecks. And you'll come across areas ... I mean, we've come across a bunch where it's like, "Oh, I didn't know this would be a bottleneck." And then of course it is, and you optimize it, and make that part faster and find the next piece to keep that perception higher performance.
Josh: So, my next note was cut JavaScripts and styles. That would be the CSS on websites that you aren't using, and consider cutting ones that you think ... even the ones that you think are required. And so, it's kind of two notes here. We had recently, we moved our marketing site for kickofflabs.com off of WordPress to a static site. One of the reasons we did that, I mean, we'd had a WordPress site forever and the journey. I think we were on now our second and a half overwritten WordPress theme. So it was a WordPress theme on top of a WordPress theme, probably on top of some custom styles.
The reality was when we started looking at this using some tools that analyze the CSS is, and the script, is we weren't using most of it.
Josh: The reality was when we started looking at this using some tools that analyze the CSS is, and the script, is we weren't using most of it. The second piece I'll talk about is a little bit of the complexity of having WordPress. But the reality is when we went through and removed the scripts that we weren't using on the site, so we basically started from scratch again almost on a new site, new marketing site, and only including the things that we were actually needed and used on the page to verify an email address, or the scripts to run a credit card. We did want to use Google analytics to keep getting some basic marketing data on the site.
Josh: We went from a score of around 40% in a page analyzer to around 98% on the key pages on our marketing site. And that was a huge difference in terms of how quickly the site comes up, like I said, in the beginning on mobile phones. It comes up much faster. It feels quicker. When I say things you think are required, I find a lot of time customers include things on their sites and pages to do things like rotating a video image, and they use these massive libraries. And I don't think people realize how big some of the JavaScripts they include on their pages are. But when they include jQuery, and then all of these other JavaScript plugins on top of plugins, just to do a really simple task, their first question to ask is, "Do you even really need the image rotator, or that script?" And the second question is, and you'll get too in a bit, is, "Are there simpler ways to do to do that kind of thing on your site?"
Josh: We found a bunch of places where we just had simpler ways of doing something, simpler ways of conveying the message on the marketing site. And in the end, it also just makes it easier for us to maintain.
It just gets simpler for you when you have less moving pieces, when you're not relying on someone else's code like that at runtime, and it just makes life easier for you.
Scott: I think that's the key too, especially when you're talking about moving from WordPress to something else. That's just the long term maintenance of the entire process and project. I just think it just gets simpler for you when you have less moving pieces, when you're not relying on someone else's code like that at runtime, and it just makes life easier for you. One of the ways we really help the marketing site is we use a library called Purge CSS, because we're using Bootstrap, and it goes through and cuts out ... I don't remember what the numbers were, but it was something like 70 or 80% or more. Bootstrap's a great framework. There's a lot of websites built with it. There's a lot you can do with it.
Scott: But at the end of the day, most people don't need all Bootstrap. You might be using the grid. You might be using some buttons. You just need a fraction of it. And so Purge CSS goes through and then removes all ... Looks at all the CSS you're using, and what you're not using, and cuts it out. One of the good things we did recently is we finally we moved to ... We upgraded to Rails 5.2, which has a support for webpack. And so, one of the things we're working on now is bringing those same changes that we did to leverage Purge CSS and some stuff like that, and bringing it into our main app.
at the end of the day, most people don't need all Bootstrap. You might be using the grid. You might be using some buttons. You just need a fraction of it.
Scott: Today, we only get the benefit on a marketing site. But going forward in the coming weeks, we should be able to do ... Have similar changes that we can make on our main app, and then be able to push those changes out as well.
Josh: Yeah. And then you have the next note as well.
Scott: We're going to on these transitions.
Josh: Yeah.
Scott: From a pure app perspective, one of the things we did, and again this is 70 years ago, it wasn't as common as it is today, but I was using background workers. So we do everything humanly possible within our app. We push to the background. And so, for even a small company, and small team like ourselves, we're still doing millions of these just micro little task in the background. But again, it gives us the ability to keep the app from the end user's perspective moving rather quickly, and enables us to capture signups quickly on our customer landing pages. Because again, we do the bare minimum we have to when someone signs up. We capture the data, we put it in the database, and then label to just throw off a whole bunch of jobs as far as validating the user, and sending emails out, scoring to users, tracking points. All of those things happen in the background.
Scott: Again, it just makes it much easier for us to manage, and the perception of it being quick is there. Because we do something like 20 or 30 individual. Just looking at from when our customers capture a lead, there's like 20 or 30 things that happen every time. We capture lead, but we don't need to make someone signing up wait for us to go through and dot all those Is and cross all those Ts. We can get back to them quickly.
Josh: Moving on to the ... Back to a customer the very front-facing side of things, are the fonts that people see. From my perspective, and we'll probably do a whole 'nother podcast on design of landing pages and fonts. When I see a landing page with not just multiple fonts, but just straight transitions between even if you only have two or three fonts on the page, but you've got one of them giant, one of the medium, then another one giant, and then some Italics, and some red, and some yellow. And people do this all the time. It's just visually disconcerting.
Josh: It would just look much better if people, if you stuck to more of a traditional gist. There's a headline, and there's a paragraph text, and there's a font that you use for both of those things. I read that 67% of websites now use some sort of custom font, which are web font, which means that it's not something that's on your customer's computer to begin with. That would be a web save font.
Josh: And so, you have to download these things. And so, the more fonts you put on a page, the more different web fonts you put on the page, the more people have to download, and the more often if you ever see loading a website and you see this blank page where there should be texts, it's they're not loading a safe font for those fonts, and it's waiting to download the larger font before it shows up.
If people can't quickly read about what you're trying to sell them, then they can't buy what you're trying to sell them.
Josh: If people can't read what you're trying to sell them, then they can't buy what you're trying to sell them. It creates this perception, again, of performance. And so, my recommendation is just to ... We're not going to unring the bell of people using a downloading fonts if it's at 67% of the web is using a custom font. But to consider, instead of using three maybe you only need to load one custom font on the page, or instead of using five, go down to two on the page. That little bit of reduction can make a difference.
Josh: You can also now in modern browsers, you can tell them to preload the fonts and move it up higher on the page stack so it's loading first. That does come at a cost, because then it won't load the content until later. And so, it's a little bit of a trade-off, but you can do pre-loading on fonts as well.
Scott: I'll throw in too things like Font Awesome. It looks like this great way of getting a whole bunch of icons on the screen, but you pay a price for that. And then I've seen now people are using multiple ... I guess, different versions of font. Not different versions of fonts also, but just other icon fonts, and all these things come at a cost. One of the neat things is you've mentioned in the beginning about people using a font for just the headline is ... I know Google does this for their fines, and I don't know of any of the other hosting providers do it.
Scott: But they'll let you to kind of speed things up a little bit more until you can tell it, "Hey, I want to use this font." And you can pass into the query string. Like the phrase you're going to use, right? If we're just using it for just one particular headline, and they'll optimize it. So that way that font you download is a version and it just contains those five letters. Or if you're using one for your logo, you can tell it, "Here's the four unique characters for my logo," or five or whatever it is. And it'll optimize a font just for that. You're still making a request and still paying the price, but at least you're minimizing it, and you're slimming it down a bit more.
Josh: Yeah, that's a really good really good it advice. I saw that advice on fonts. It's not just picking smaller fonts, but that you can request in most services now that subset of the characters. So If you only need a few of the characters, you can be a much smaller download for people.
Scott: Especially for headlines and logos, and that kind of stuff where you have a lot of control over it.
Josh: Yeah. And you mentioned Font Awesome. It was funny. We went through that on the marketing site. I was saying, "How do I shave this extra half second off the load?" And I was looking at it being Font Awesome. I looked at the market and said, "So what are we using Font Awesome for?" It turned out we were only using it in the footer to link to the KickoffLabs Twitter and Facebook pages. I said, "Well, that's an easy thing to cut." So we cut the icons out and now it just says Twitter and Facebook at the bottom, which in some ways, I think is actually more usable. And we were able to cut the whole dependency and the marketing site having Font Awesome.
Scott: Yeah, on my own personal blog, I did made a similar decision. I just wanted like inline SVGs, and then you get all the same benefit, and it's kind of right in line. Probably out of context with those two, but Font Awesome too just to look at the usability and accessibility of things I get to. It doesn't always come through the way you'd expect it to on screen readers and smaller devices.
Josh: Yes. I can't remember what we were going to talk about next, Scott.
Scott: Oh, well, we have a list right in front of us, so we'll keep scrolling through. So I had four. My next one was memory monitoring, or just monitoring in general. Maybe this is one we could have started with. But one of the hard things to do when you're performance monitoring is knowing when something went wrong. Was it with the deployment? Was it something that happened recently? Was it a change in dependency? I always say I kicked myself because we didn't really do enough of this monitoring. We're just getting started.
Get a performance monitoring app going from day one.it will make it easier to follow the changes you made, what improvements you made, if you've done something.
Scott: And when you look at memory graphs, and CPU usage, and those kinds of things, it's hard to know if we've gone back, if we've made a lot of improvement where things changed because we don't have a great starting point for when we started using these tools. So I guess this kind of just as a tip for any app when you're just getting started. We use an app today called Scout that watches all this stuff for us. And just to have that up and running from the beginning. Yeah, you at least know where you are from day one, and make it will make it easier to follow the changes you made, what improvements you made, if you've done something.
Scott: Again, the big thing is did you deploy something, or did you make an underlying change out of your control? And that adversely affects your performance in some way. So for our case, it would be, a gem dependency that we use, a different version of Rails, a different version of Ruby, and those types of things.
Josh: Yeah, we do need to work on these transitions, because I don't know how to start. Sorry. Did you like my memory introduction, though? That was good, right?
Scott: Yes. We'll get better people. We'll get better. I promise. I'm overly trying not to step on your lines. We're going to work on it.
Josh: All right. I mentioned this earlier. We migrated our marketing site off of WordPress to a static site, which means one where the pages are just all written out to disk ahead of time. There's no database involved in our marketing site anymore, and our landing pages. The landing pages are up. The KickoffLabs we generate are all basically static pages as well that are published in advance.
Josh: There were a lot of reasons to do this. The performance of that database lookup and WordPress is one of them. We were paying, much probably still are paying for a couple more months a lot for WordPress hosting. It felt like we would still see these outages from time to time that were out of our control because something went wrong with the database and the database server. It removed one more thing that could go wrong from our process, or marketing site, whatever you want to call it.
Josh: And I think removing that one dependency. Had a lot to do with ... It makes it simpler to maintain. It's less error prone, and for all the reasons we've talked about before, the pages are just going to be faster loading for people. And so, it might not make sense for everybody out there to do that. There's certainly some downsides. WordPress has a ton of publishing and workflow tools around it. Although my personal opinion is the latest WordPress editor, and the latest version of WordPress was a huge step backwards. I know I'm not alone in thinking that.
Josh: But there are a lot of publishing tools that people are used to, and you kind of miss out a little bit on those on those workflows. But I think the benefit going forward of having less overhead is clearly worth it, which leads right into your next topic.
Scott: Awesome. Less overhead. Only use what you need. Yeah, I guess this one's pretty obvious as well. But to really think about dependencies you should take. I'm talking more, I guess, from the ad perspective. But it could relate to the marketing side as well, right? Because you can pull in different JavaScript frameworks and that kind of stuff. But it's very easy when you're getting started to just grab everything. I said we use Ruby and Rails for our main app.
Scott: But I just remember when we first got started coming from our backgrounds that we both have backgrounds in the .NET World and the Microsoft world, which has changed a lot in the last eight years or so since we were there as well. But you come into this Ruby world where there's just Gems galore. There's, pre-written pieces of code that I've done, everything that you want to do and you're happy. It seems really easy to just go out and just grab these things, and patch it all together, and just kind of stitching it, connecting the dots, as you will.
Scott: But over time, we started to realize that for a lot of these gems, we're only using 20/30 lines of code from it. I think this is most apparent on things like rappers around like the MailChimp API, and SendGrid's API, and stuff like that where to their credit MailChimp is built as great big API. And either they or third parties have built Jim rappers around that API. But the end of the day, we were only using a really tiny part of it, and we were paying the price both in memory for having to gem load it, complexity and having another dependency. What else? And just the risk of having someone else's code running within our product where we're only using this tiny, small fraction of it.
Scott: One of the things we've been doing for the last couple of years is wherever possible is just extracting the pieces that we may need from those gems, or running our own pieces, our own code that mimics a lot with the API, and then just getting rid of that dependency. And that just gives us all a lot less to manage longterm.
Josh: Yeah. It makes it a lot easier to see where problems are coming from for probably doing it that way. And there's definitely a desire, I think, especially whether you're starting a new feature or a new product to say, "Well, I might need to use all these things one day," and you pull it in. And then before you know, you've pulled in a bunch of large things. I see customers do that with their own websites too, whether it's like Shopify stores, or WordPress plugins. They'll look for the biggest plugin they can find to do something, and they're trying to really solve a small problem.
Josh: And so, even if you're just going through a WordPress plugin directory and you're looking for something that solves a problem, try and stay focused on the very small problem that you have rather than trying to pull in huge solution that you're only going to use a little bit of. Something to be wary of if you're using like these plugins that we noticed on our marketing site is, because I'm not going to convince everybody to get off of WordPress, but a lot of the plugins in WordPress will pull in a whole bunch of things that you just don't realize they're pulling in, whether they're loading different marketing scripts from different locations, or whether they're loading a CSS library that you've already loaded in your location, and they're just loading a different version of it.
Josh: I've seen websites with three to four different versions of Bootstrap being loaded because there's a different plugin using a different version of Bootstrap. In reality, they could probably just consolidate around just using one version of it. And the same thing with WordPress themes as well as. Just to check, make sure you're only loading and using what you need.
Josh: The last thing, speaking of loading and using what you need, this came from another recent customer support ticket at KickoffLabs. This person had a landing page. And part of their landing page, they had a grid of a 10 embedded videos on the page, all loading from YouTube. He was emailing me, "My landing page is really slow. Is there something you guys can do to speed it up?" I had to look at it and say, "Well, there's not much we can do to speed it up, but there's a lot you can do to speed up this landing page." The biggest one being those 10 videos, each one of them requests out to YouTube were just slowing down and blocking the page. I got him down to one video, which was just his main explainer video on the page.
Josh: I don't know if he actually went through the recommendation. If you do feel like you need to link to multiple videos is just consider just linking to see also text on the videos, or just linking a with preview images of the videos. So you could still have a 10 by 10 grid, but if it's 10 small thumbnail images, at least it's going to be, as long as they're right sized images, it's going to be a lot faster than these 10 embedded videos that would be on the landing page. And just instantly his page loaded much faster when he just went down to one embedded video on the page, and the rest of it wasn't blocking everything else.
Josh: My bonus note about this, and this isn't really about conversion optimization is that I wouldn't be too dependent on the video if you're building a landing page for conversions. A lot of people, the videos are a nice secondary thing, but the texts and images you have on the page, the video should just be complimentary. You should be able to get the gist of the page without the video. Imagine if there's something wrong with the YouTube player, or it doesn't work on their mobile device, or they're at work and they can't listen to it because they don't have headphones.
Josh: I see a lot of people with landing pages so I just have to make this note where the landing page text doesn't really say much, and it just says, "Watch the video." A lot of people will, but there's a lot of people who aren't going to watch the video, and they just want to scan the page, and text and get the gist of what you're trying to market to them, what you're trying to sell to them for them to make a decision, and just realize that the video is not an excuse to not have good copy and text on the landing page. And that I know has less to do with performance, but if you got rid of even that one video, the page would load even faster. Although I do understand the videos can be helpful to sell especially a certain markets and segments.
Scott: Yeah. I think there's too many videos. I might be old. I rarely come across a website for the first time and click the play video. Usually scan to see what's going on.
Josh: Yeah, I don't think that's uncommon. I think people scan to see what's going on a site, and then decide if they want to get more information and watch a video. So you can't have the page without the scanning info. So that's the last performance note that we had. What do you think of this episode, Scott?
Scott: Yeah, forty some minutes. I think we'll have to work on our speed going forward as well. We'll improve the performance next time. Awesome.
Josh: All right. And with that, we'll stop the recording. If you have any feedback, feel free to email Josh@kickofflabs.com, or Scott@kickofflabs.com about this episode. I have to throw in the obligatory, please subscribe and rate in your podcast app of your choice. Thanks for listening. Bye.
Scott: Thanks everyone. Bye.
