[00:00:01.20] SY: Welcome to the CodeNewbie podcast, where we talk to people on their coding journey, in hopes of helping you on yours. I'm your host Saron, and today we're talking about web performance. (Music). So you hear about this amazing show called the CodeNewbie podcast. You go online to check it out, and if you visited the website a few months ago, you would've waited forever for the site to load. It took about 3.4 seconds, which isn't a lot in human years, but in code years, that's a really long time. And even though I made the website, and I know that making the page load faster was the right thing to do, I had no idea where to begin. But I'd heard of this thing called web performance.

[00:00:49.07] LH: So web performance is about taking a look at a website and seeing what it feels like in terms of speed.

[00:00:54.27] SY: That's Lara Hogan.

[00:00:56.20] LH: How fast does the page content load, how fast do you see images, how fast does it feel -

[00:01:00.15] SY: And she literally wrote the book -

[00:01:03.01] LH: Called designing for performance. It was published by O'Reilly and yes, I do have an O'Reilly animal for my book cover.

[00:01:09.22] SY: And she's here to school all of us, mostly me, on how to make your website faster and your users happier. After this. If you're dreaming of a career that gives you a flexible schedule, the chance to work remotely, and tons of jobs security, fulfillment, and freedom - all with a nice big salary - you need tech skills. And that's what Skillcrush.com is for. Their all-access career blueprint is the tech industry's most personal and supportive online learning program. You'll see just how easy and affordable it is to get a head start in tech. Enroll now and get ten percent off your annual blueprint subscription when you use the promo code newbie. See you in class.

[00:01:49.29] If you're building an app, you'll probably have users. And when you have users, you'll have to talk to those users, usually, via email. Which means, as a developer, you'll need to pick an email service provider. Which means you should check out SparkPost. They are the world's most reliable and fastest-growing cloud email service provider, with a robust API to fit right into your app. They're super developer-friendly, they've got free start-up accounts, perfect for solo developers, and sophisticated enterprise options, which is great for teams. So, if you need to send an email, which you probably do, check out SparkPost at pages.sparkpost.com/CodeNewbie. Link is in the show notes.

[00:02:26.13] When I first learned to code, all I wanted was to be a developer. But then I actually learned to code and realized - you don't become a developer. You become a frontend developer, or a Rails developer, or a full-stack engineer, or a backend engineer, or the million other job titles that involve coding. So how do you pick? And once you get that first job, how do you turn it into a career? You can use the Dice Careers mobile app. This is the tool I wish I had when I first started. You pick the tech skills you either have or hope to have in the future, you type in your designer job title, and Dice helps you find other job titles you might also be interested in and maybe didn't know about. But they take it a step further, by telling you what skills these job titles require, how much they pay, and based on your profile, they tell you what skills you might want to learn so you can one day apply for those jobs. They simplify a lot of the chaos of job-hunting, and it's totally free. So check out the Dice Careers mobile app. Go to dice.com/CodeNewbie for more info. That's dice.com/CodeNewbie. (Music).

[00:03:24.29] Web performance I feel like is one of those things that you eventually realize that you need to know about, but isn't as Google-able or as straightforward to research as something like learning React or learning jQuery. So, tell us what web performance is.

[00:03:43.16] LH: So, web performance is about taking a look at a website and seeing what it feels like in terms of speed. So, how fast does the page content load, how fast do you see images, how fast does it feel. There's a bunch of different things you can measure with it, but it's kind of just an overall assessment. How fast does this webpage feel.

[00:04:07.10] SY: How fast should fast be?

[00:04:08.17] LH: Frankly, it's kind of all relative. The best practice that's out there, is your website should load in about two seconds or less. There's all these studies that show that anything above that, tons of users won't even stick around to wait for it to load, or they might just bounce and leave your website immediately. So, two seconds is the general rule of thumb. But I like to say that that's a good thing to keep in mind but may not be realistic, so the other thing you can try to measure is - how fast do your competitors' websites load. That might also be a good rule of thumb.

[00:04:41.09] SY: Ooh, that's a good one. Right, 'cause if there's three of you, and yours is five seconds and everyone else is ten, then hey, you still win.

[00:04:49.01] LH: You're fine, you're fine. Yeah, so the other thing that's more advanced when you're thinking about this stuff is - how fast can a user begin interacting with your page? But that can also mean something different to everybody. So, maybe if I'm running a shopping website, how fast can you see images of the stuff you can shop for? If you're running a dictionary website, how fast can users type in the word that they're looking up? So, yeah, it gets a little hand-wavy and fuzzy once it starts to go past the how fast does it feel, you can totally come up with a good baseline metric for you to try to measure yourself against.

[00:05:22.04] SY: So, when I'm hearing you describe web performance, I'm trying to figure out who's job that is. Because it sounds, when we're talking about loading data, that sounds like a back-end person's role, but then we're talking about images and things that users see, that feels like a front-end role. But then the actual images and graphics were created by the designer. So, whose job is it to think about web performance?

[00:05:44.01] LH: You know, it's funny, when I started giving talks about web performance, I was giving very straightforward, one-oh-one, here's how to make a website fast talk. And then I started to notice that in the audience, after I would give the talk, they would ask a bunch of questions about how to get other people at their organization to care about making websites fast. I started to realize that all of the general advice about this is geared towards usually a full-stack developer, because most of what happens in terms of a website feeling fast, happens on the front-end. A little bit, obviously, can be tweaked all over, but I started to realize - everybody has a different subset of problems. Maybe your design team is designing extremely heavy websites with lots of complex graphics. Or maybe your very important people - your bosses, your higher-ups, just don't care, so they're not going to give you the time of day to work on this stuff. I wish I had a simple, like, this person - this person with this title is the person whose job it is to care about this stuff or to work on this stuff, but genuinely it's really a whole team effort.

[00:06:47.06] SY: So, in a team, I assume if you have a bunch of developers and designers and stuff, there's usually a PM in charge, or a tech lead in charge, kind of overseeing the situation? Overseeing the project? Is it that person who generally starts the conversation, and says, hey, I notice our website is a little bit slow - how do we solve that? Or who kind of initiates that search into web performance?

[00:07:09.29] LH: I have seen it start in so many different places. Sometimes it starts in customer support -

[00:07:16.16] SY: Oh yeah, that's a good point.

[00:07:17.02] LH: People are complaining about it's taking too long to load. I've seen it start with developers, obviously, who might be measuring this stuff. I've seen it start with PMs who maybe have some deliverables. People might be looking at number of dollars that come through the website, or conversion rates, and PMs may learn that performance is a huge factor in whatever it is they're trying to measure and improve for their KPIs, so yeah, it really can start anywhere. I've seen, genuinely, the spectrum. Every once in a while a manager will come in and be like - I saw this talk, we should take a look at this stuff. Yeah, it's funny to me that so many different people can be interested in this stuff, work on it, and ultimately might be responsible for keeping a site fast, and I wish that there was a succinct - ugh, if only I could just blame this one person for not doing this well enough, this would be so much easier!

[00:08:02.17] SY: So it sounds like it's something that we should all generally be thinking about and be mindful of as we build.

[00:08:12.13] LH: Yeah, in an ideal world, from start to finish, the project development process - from the project brief, maybe you can come up with a performance budget, so having a goal at the end, how fast should this page look is one of our goals, through the design stage, making sure designers know what image formats might load fastest, how many fonts they want to include - and be thinking about those, weighing those aesthetics considerations versus performance considerations. Making sure they're coding things in a way that's easier cache-able and repurposes a bunch of design patterns. All the way through to the end - measuring it in your experiment, making sure that you are controlling for page load time. Really, it's front to back, I can see performance being a huge consideration to each step. More often than not, it's really only a consideration at one of those steps. My goal has been to try to convince all of those people that this stuff is important, that it can be kind of a shared consideration.

[00:09:05.14] SY: Yes. Absolutely. And I feel like that's been one of the things that has always made web performance kind of scary, is that I don't trust myself to fully understand each option and to be able to properly analyze the trade-offs. So, how can you begin to do that? Are there tools or tests we can run to help us kind of pinpoint where the issues are?

[00:09:30.14] LH: Yeah, there are so many great tools out there, and they're almost all free. So, the first tool I usually recommend that people take a look at is called web page test. So, web page test is a free service. It uses a bunch of different computers across the world that can simulate a bunch of different browsers, and a bunch of different network conditions. So, how fast can these different computers load all of these different webpages. You type in your URL into the tool, and says - ok, I want it to test this page and its location using this browser. And that tool will both tell you how fast your website is loading, and also help you start to diagnose a bunch of stuff. You really don't have to know much about web performance to get a good, overall view using this tool of where to maybe begin.

[00:10:12.09] SY: That is really helpful.

[00:10:16.11] LH: And, they keep on improving it. It's constantly getting better and better. I can't believe this service is free. Yeah, it's really phenomenal and frankly, more often than not, images are the biggest bloat for your page, they're the thing that slows things down the most. So, even before you get to this webpage test step, if you're curious about these things and just kind of want to play around with it, this is especially good if you're developing some things behind a firewall or just can't be loaded - is in a developer environment and can't be loaded in a web page test. The place I recommend you start learning about this is with images.

[00:10:48.13] SY: So what are some common things that people do wrong when it comes to images? Everything?

[00:10:51.28] LH: (Laughs). So, it's funny, right, there's some classic ones. So, JPEGs, which is what's called a lossy image format. The way that JPEGs work is they collect a bunch of data in your image and they use an algorithm which is kind of like how humans see things - so it's loosely based on our sight perception, and our brains are really good at parsing what's in front of us and kind of discarding unnecessary information. And that's what JPEGs do. So, JPEGs take this algorithm and applies it to an image, and it drops a bunch of information, that's why we call it lossy, to make it a much smaller image. So, JPEGs are really good for photos and other images that have a lot of complex colors in them, because it's good at dropping unnecessary data. They're really bad at the same thing at the same thing that our brains and eyes are bad at, which is high contrast areas, or stuff with a lot, a lot, a lot of detailed information in it. So, yeah. So generally, people naturally export all of their images using JPEGs, when there might be a bunch of different image options out there to choose. Oh, and I forgot to mention the other really obvious part about this - people often don't realize that how big your image is impacts your webpage load time. (Laughs). Your user's computer, and that user has browsed your website, and what happens is that browser goes and fetches all the different things that make up your website, so the images, the fonts, the CSS file, all the stuff that's needed to load that page. If that image is coming over effectively the wire, right, how big that image is - it could take a lot of time for that user to collect all of that data back and render it in the browser. So, definitely thinking about size of images is critical.

[00:12:35.11] SY: Is it that JPEG is generally not a good file format, or is it that it is good in certain situations, but shouldn't be the universal default?

[00:12:46.05] LH: Definitely the latter. So, JPEGs are great for photos and they're great for your average website with a bunch of complex image - you know, lots of colors. There's a couple of other image formats that I like to mention. The first one is gifs - some people pronounce it jif, I pronounce it gif, I'm sorry, I apologize to anybody in advance to anybody who cares -

[00:13:08.14] SY: It's definitely gif. Jif is for peanut butter.

[00:13:11.29] LH: Thank you! So, gifs are really handy for when you've got animations - complex animations. Then there are PNGs - PNGs are another image file format that are usually pretty good if you have very, very few colors in your image, or if you need transparency. And there's a couple of experimental image file formats that are brand new - when I saw, brand new, I mean like seven years old. A lot of these have been around since the 80s and 90s. But things like WebP is a newer file format that Google developed to help make sure we are better at delivering images over the internet. But that's all to say - you can kind of pick and choose which image format that you want based on the kind of image that you have. So, JPEGs are great for photos, gifs are great for complex animations, PNG8's are great for images with very few colors, and PNG24's are really great for images with partial transparency.

[00:14:05.25] SY: So, one thing that I remember having a really hard time appreciating is the difference in file sizes and how that affects load time and how that affects performance. So, if we were to take, let's say, a photo. And let's say the photo was really, really big - let's say it was 3,000 by 3,000 pixels - if I were to compress that and make that the most optimal, the best file type, the most compressed, but still being able to see completely on a website - what is the difference? What are we actually gaining?

[00:14:41.17] LH: Totally. You're just dropping kilobytes left and right. So, if you've got that image, and you run it through compression tools - there are, again, a bunch of free ones out there, ImageOptim is one that works on Macs, it takes a look at your images and tries to figure out how to compress them in a way that doesn't drop any quality. So, you run it through a compression tool, and those compression tools are saying to themselves, ok, there's a bunch of important data that the user at the end of this does not care about. And by dropping all that data from the image, it makes it a smaller file size, which makes it so much faster to be delivered over the internet and then show up on the user's screen.

[00:15:18.18] SY: So, how much faster? If we had that one photo, and we dropped it to the most optimal level, what's the difference for the user?

[00:15:26.10] LH: I wish that most of performance didn't always end up with answers that include "it depends" - that's computers, I guess. It depends a lot on the file format and what kind of information was dropped. I have seen enormous file savings like thirty, forty percent of the file size. I've also seen super tiny tweaks - because maybe something, when you exported it from your image editor, was already pretty clean. So the range is pretty drastic. I think probably the biggest part of it is the overall dimensions for the image. So, if you're trying to serve a three thousand by three thousand pixel image, it's probably going to be large no matter how compressed it is. As in, it's going to be a big, bloated file. But like, a thirty by thirty pixel image will be super fast - it's going to ship so fast over the internet, and it's going to load so fast on the user's computer.

[00:16:15.00] SY: Yeah, that was one thing that I went through with the CodeNewbie website, actually, with the podcast page, because we have over a hundred and fifty episodes at this point, and each one has a photo, and me being a not good web performance person, I just kind of took all the photos that guests gave me, I made them a square size, and that was kind of it, I just uploaded it, and just called it a day. And for a long time, I was like "why is this page so slow?" And if I say that, and it's my baby and my website, I can only imagine how many people gave up on that page. And it's one of those things where when I think about all the other cool ideas I have for CodeNewbie and for the website, improving performance on an existing page just never felt important enough. You know, it never felt urgent. The way I justify it is, if you really cared about the podcast, you would just wait. (Laughs). Which is a terrible way to look at it.

[00:17:07.22] LH: That's fair. A lot of people do stick around and wait for content that they're really excited about. Like, when I was at Etsy, we were trying to optimize the check-out workflow to be a lot faster, and it wasn't really moving the needle on any of the big metrics that we paid attention to, and we started to realize - when people get to the check-out, they already have a high intent for making it through that check-out process. So you're not going to see as much impact on this stuff and it won't make that much of a difference for your users if your users generally really want to get through to the end. But definitely for those first pages, especially when you're - again, I keep on talking about competitors, typically this helps the VIPs in your company care about this stuff - that's really when it counts, on that first landing page.

[00:17:52.25] SY: Yes, absolutely. And that was - I finally decided, ok, let's take a moment and let's evaluate this whole photo situation for the podcast page. And I did go and compress everything and made it - and what I realized is, first of all, oh my goodness, it made a world of a difference. And I have - I use Skylight to track the differences in web performance and such and such, and I don't remember what the actual numbers were, but I remember loading the page after I finished optimizing the images, and just not being angry. That's what I remember.

[00:18:24.17] LH: That's amazing. Hey, that is a great metric of success. (Laughs).

[00:18:29.22] SY: It's actually one of the things I really like about Skylight is they have a metric called "agony" - it goes up to like three exclamation points of agony, and it will say "based on how long it takes for this page to load, this is how much pain your user is feeling." So, I love that metric so much.

[00:18:47.02] LH: Ok, Web Page Test. Another cool thing that it does is it calculates how much data it would take a user in a bunch of different countries to load your page -

[00:18:55.26] SY: I love that.

[00:18:56.11] LH: And how much it costs them. So, in America, we've got really fast internet speeds, and also we don't think a lot about paying per kilobyte, per megabyte, et cetera. But plenty of users in plenty of different countries actually do pay for their data and it's expensive. So, Web Page Test at the end will tell you, with a bunch of dollar signs, how much your website costs to load around the world.

[00:19:18.17] SY: That is awesome. And that's one of the things that, when I think about how scary web performance has always felt to me, I think part of it is feeling how can I possibly include everyone in this. How can I possibly account for all the different variables that make up all these different experiences of how to visit this website? So, my terrible response is, screw it, I'm just going to make sure that it works for me, which is not the answer, which is why we have you to show us differently.

[00:19:49.12] LH: One of the reasons why I got into talking about web performance was I realized how often engineers and designers - especially in America - you know, we're using brand-new devices, we're on extremely fast, strong infrastructure - we're often doing this work over office networks, which are really fast, and we don't have any empathy built up for the users who may not be in the same positions. Not just around the world, but going through a train tunnel, being in a crowded area. We just don't have that empathy built up, we don't notice the performance problems until we're on that airplane, or until we are in that other country. So, what I try to do is talk a lot about this stuff, not just for the audience that I'm speaking to, which is a bunch of probably well-paid engineers and designers, but remember that their users are not them.

[00:20:36.07] SY: Absolutely. That's why I've given up on all recipe websites in general, because the amount of waiting for all of those ridiculous banner ads to load just so I can see how many onions to use is just ridiculous, I just can't deal with it.

[00:20:52.00] LH: I'm just going to keep on singing Web Page Test's praises. One thing you can do is export a video of how fast it looked to load your site over different internet speeds. And that's really compelling for again those very important people who care about user experience and their competitors. I definitely have found value in showing how a website loads over mobile networks and over handheld device's. Again, because we're on those shiny devices on these really fast networks - they don't realize what it actually feels like. My favorite tricks also are to show the same video, compared to the competitor's website. So, I'll have them - you can do this with Web Page Test, you type in multiple URLs, and they will record at the same time, a video of those two websites, or three websites or ten websites loading. Actually, I got to present for the Clinton campaign last January about web page times, and I compared all of the three, basically, competitors at that time to each other, and Hilary's website wasn't yet one of the fastest. And I felt like it was hopefully a compelling message about making that website fast.

[00:21:55.11] SY: Yeah, I was going to say, if someone showed me that, I'd be like, oh my goodness, we have to beat this person. We have to beat this other company. Oh, that's awesome, that's really great.

[00:22:01.17] LH: Yeah, 'cause numbers works really well at convincing engineers about what they can do differently or what they should care about. I've found though that numbers aren't compelling to all disciplines. And certainly for some engineers, they would much rather see the optimization options - the problem-solving options to tackle, rather, but frankly, videos help everybody care about this stuff.

[00:22:25.27] SY: Mm-hm, absolutely. Ok, so we talked about photos as one of the biggest things to look at, one of the biggest potential problems for your website's performance. What are some other categories of things that might be problematic?

[00:22:39.02] LH: So, one of the other things I really loved talking about is web fonts. So, people often don't realize when they're designing and developing really exceptionally beautiful websites that the number of fonts that you have severely impacts page load time. And not just the number of them, but the size of those files - just like with images. So, there was one experiment that we ran at Etsy, we had - the listing pages was the most important page on the website, still is, everybody's landing on that and looking at the cool, new beautiful crocheted hat. So, on that listing page, we had upwards of eight web fonts loading on that page, because we had specific ones for all these different font ___, all these beautiful, light italic ones, really heavy title ones. And it crept up over time and it really bloated the overall size of the page - the page __ of the page, but also having eight different fonts meant that the browser has to go and fetch eight different files. And not all of that can happen at the same time, especially when you're first loading a website. So, we ended up running an experiment where we reduced the total number of fonts used on the website, and we tracked to see if that would change at all engagement metrics - and we tracked and made sure it wasn't really negatively affecting the overall aesthetics of the page. And by the time we were done with it, we had narrowed it down to just two web fonts, and it was a huge success, it was great.

[00:24:01.07] SY: So, web fonts are something that I would never guess would be a problem. And I think it's because when I think about images or graphics, it's an addition, it's like, I'm adding this graphic into this empty space, and I'm adding this photo into the hero, but for a font, I have to have text. However the text looks, I would not think of as an addition to the page, I would think of it as styling to the existing page. How big can a web font really get?

[00:24:32.08] LH: I once did some research on the Google fonts, you can grab a bunch of Google fonts from that site, and the average were something like 35 kilobytes, which is pretty small, it's the size of a pretty normal-size image, for example. But some of the web fonts were upwards of like 200 kilobytes of weight, and really that comes down to character-subsetting. So the idea is that you have a bunch of different characters - you've got capital A and a lowercase a. But then imagine all of the a's with accents, and all of the cyrillic characters, and all of the Greek characters, and all the different kinds of punctuation, and that can add up to an enormous font file, whether or not you ever plan on using those characters on your website. So, often it's an overlooked thing because we're like, oh, it's just a font, let me just include it on the page, without realizing, we can probably optimize this a little bit further.

[00:25:21.28] SY: So, my font loading strategy is to pick a font that I really like, and then download every single version and weight and style of that that I possibly can, and figure out later which one it is that I really want to use. It sounds like that's maybe not the right way to approach it.

[00:25:40.02] LH: That's a great approach, as long as by the time you ship it, you're only down to one or two, maybe tops three, web fonts. I think that's a great - it's good to experiment, right? Frankly, all of web performance is experimentation, because there are definitely good rules of thumb and some best practices, but what works for one website might not be the most optimal for another, and that just comes down to those trade-offs I was mentioning before. So maybe you want to include ten web fonts but no images - that might be a really quickly-loading site. It's important to test it to make sure.

[00:26:10.04] SY: The main thing is treat it like you are loading any other file, because you are. You're loading an image, a font, whatever it is - you're still loading an additional thing, so always keep that in mind.

[00:26:19.21] LH: Totally, and one of the other trends I've seen is to include icons in fonts. It's one great way to troubleshoot loading icons on your website. I would say proceed with caution here. There was one time I was developing for Etsy.com, for the mobile web font, and we were including a bunch of icons for various little tidbits around the design of the site, and I didn't really document well how I had developed these icon font nuances. So, one time someone uploaded a different version of the icon font, where they added a new thing. Well, it turned out that my lack of documentation caused one of the more ridiculous bugs in Etsy's history. Because of the way that this all went down, we had dropped that glyph, that character subsetting thing, for one of the half stars. So, when you visit Etsy, you can see the star rating of your sellers, and we had dropped the half-star icon, which oh man, I can't even begin to tell you. What happened on iPhones, is it chose to substitute what it thought was the next closest thing, which was the horsehead emoji.

[00:27:25.10] SY: (Laughs).

[00:27:27.11] LH: Oh, so we didn't even notice it at first. We started getting bug reports in our forums, saying hey, is this like an April Fool's joke? There's this horsehead showing up in my star rating.

[00:27:44.10] SY: Oh my goodness.

[00:27:44.12] LH: I'm glad that no one thought that the site was like hacked. Our sellers were really good sports about it. They thought it was really funny. So, we did fix it pretty quickly, but yeah, if you end up using icons as part of your web font strategy, definitely write some documentation for it, so anybody doesn't make the same mistake we did.

[00:28:02.08] SY: Absolutely. Yeah. Does it kind of matter what style you pick? Should you generally stay away from the italics and stick with the regular? Like, how do you - are there any differences?

[00:28:12.14] LH: As far as I know, there are no real differences when it comes to the style of the font or the heaviness of the font. It really does come down to, if you just inspect the font file, in whatever editor that you have, just make sure it's not over like 50 or 70 kilobytes. If it is, there's a bunch of tools to help you edit that font and do that character subsetting. Like, Font Squirrel Font Face Generator, which is free, and it only works on non proprietary fonts, so if you end up using a font library like myfonts.com, they'll let you subset it differently, But yeah, just take a look at that overall font file and see what the size of it is, and then you'll know if you really have to troubleshoot it.

[00:28:52.22] SY: Coming up, Lara shares a third and final category of things to look into when you're trying to troubleshoot your app's performance. We also talk about A/B testing and not just what it is, but how do you implement it, what tools do you use, and how do you know when you're done? We also have another edition of our Coding Corner with Joe Burgess, the VP of Education at the Flatiron School, who shares three things that newbies often get wrong when trying to make their apps faster. After this.

One of the most important features of any app is talking to your users, whether it's an email notification, a password reset, a new user welcome, emailing your users is an essential part of the app experience. Which means, you need to pick a reliable email service provider you can count on. SparkPost is the world's most reliable and fastest-growing cloud email provider. They're built on AWS, and trusted by the world's biggest senders to deliver unmatched uptime and resilience. And they're great for developers like you! They've got an amazing resting API to fit right into your app, or you can use plain SMTP. So check out SparkPost, at pages.sparkpost.com/CodeNewbie. Link is in the show notes.

[00:29:59.20] So, you're feeling trapped. You've got a dead-end job, you want to get out, do better, make more money, but you don't know where to start. That's exactly why SkillCrush was created. SkillCrush is designed for total tech beginners to learn digital skills and launch better, higher-paying, and fulfilling careers. And that career comes with real mobility, so you'll never feel trapped in a dead-end job again. Their all-access career blueprint program provides premium tech classes, one-on-one mentoring, and a thriving student community to support your journey from tech newbie, to digital pro. They're offering ten percent off your annual blueprint subscription to CodeNewbie listeners, just use the promo code Newbie. See you in class.

[00:30:40.20] Getting a job is one thing. Building a career is another. With Dice, you can do both. They've been helping tech professionals advance their careers for over twenty years, which means they have a ton of data and tools to help you navigate yours. Looking for a job right now? They've got thousands of positions available, from top companies like AT&T, DreamWorks, Adobe, IBM, and Dell. Wondering what's next in your career? Use their career-pathing tool to find new roles based on your profile and see how much more money you can make. Not sure if you're being paid what you're worth? Use the Dice salary predictor to see real numbers on what your skills are worth. Don't just look for a job - manage your career, with Dice. For more info, go to Dice.com/CodeNewbie. (Music)

[00:31:24.01] The Coding Corner. With Joe Burgess.

[00:31:27.29] JB: I'm the VP of Education at the Flatiron School.

[00:31:29.18] SY: So let's talk about web performance. I feel like the only thing I know about web performance is Google's paid speed insights, which I can barely understand anyway.

[00:31:42.00] JB: Oh yeah. Those are so cool. It's really interesting.

[00:31:44.08] SY: It is, it is. I'm always like oh, here are all the things that are bad about my site, ok, so now what do I do? So, how would you describe performance?

[00:31:51.12] JB: I'd say there's two types of performance. There is real performance, which is how fast is this algorithm, how fast is rendering this page. And then I think there's something that's way more important, I think many people - me included - call perceived performance. Which is how fast does your application feel to the user. My favorite example of this is Instagram. So, when Instagram first came out - remember, this was the bad old days, on terrible internet connections, with terrible iPhones - it took a really long time to upload a picture and to do the filter processing, all that stuff. So, if you paid attention - the thing that was amazing, though, oh my gosh, so fast, how do they do this. There was no magic, they just really focus on perceived performance. So one thing they did that's really cool is if you think of the flow, and it's still the same flow for Instagram, first things first, you take a picture. Then, you choose the filter. Then, you go to the new page, and you're figuring out what your hashtag's gonna be, the location, the description - then you hit submit, and you get that little loading bar that goes really quickly and uploads. So, if you think about the perceived performance, a very naive solution, a very simple solution to this would be they filter it, they then hit submit, when they submit, you then take the image, compress it down a bit smaller, run it through the filter, and then upload and it's good to go. But, what they do instead is you take the picture, can't do anything with it yet, you choose the filter - whoa, you've already taken the picture, you've chosen the picture, they now can do all of the hard work. They can do all the heavy lifting. While you are typing in your hashtags and your location - all of this light stuff - they are compressing the image, running the filter, and they start uploading it, all while you are still doing other things. Then, when you hit submit, the only addition thing they have to upload is some letters, some text, which is super fast. But they want you to perceive that it's really fast, so they show you this loading bar that goes really quickly from left to right, and it feels like it uploaded super fast, everything's good to go.

[00:34:01.03] SY: I feel so lied to.

[00:34:02.07] JB: I know, that case is such a good example of their upload algorithm is probably just the same as yours, their compression algorithm is about the same as the standard stuff, their filtering stuff is about the same as anyone else. But, by changing the flow on when users did what, they're able to increase the perceived performance by the user. I think it's just a really powerful thing to think about is absolute performance in the very nerdy, I did this in two seconds - matters so much less than -

[00:34:33.09] SY: The feeling that you did it in two seconds.

[00:34:33.22] JB: Exactly. It's very hard to actually make your app faster in a real sense, but it's easier to make your app easier in a perceived sense. So, keep that kind of in the back of your head whenever you're thinking about this stuff.

[00:34:45.24] SY: And I feel like with the perceived performance, you can get a lot more people to help you with that too, because if it's really about speeding up the algorithm, that's a really technical thing, but if it's about the user experience, then designers can jump in, ___ people can jump in. I feel like you have more help to see how to make that feel faster.

[00:35:01.21] JB: Definitely, it's great, you can get the whole family involved.

[00:35:05.11] SY: Yeah. That is so cool, I've never heard of that term, perceived performance before, that's very interesting.

[00:35:11.01] JB: Oh yeah, for our students, whenever our students are like, I think my app is slow, I always go first to perceived performance before I go to actual performance.

[00:35:20.00] SY: Ok, so what are some common mistakes - three common mistakes - that newbies make when dealing with performance?

[00:35:26.27] JB: So, everyone is different, so it's different for everyone, but my big three ones are both the three most common and usually pretty easy to fix. The first one is, especially with very modern languages like Ruby, JavaScript has this, Python has a lot of this - is what I call secret loops. So when you're designing I'm going to use the word algorithm, but that is - remember, algorithm is just a fancy word for recipe, directions - A then B then C. When you're designing an algorithm, you may do, you may run through everything, and for every item, check to see if it's in a different array. Right, you call the contains method or the includes methods __, depending on the language. That's secret loop. What you probably didn't realize is that Contains has to run through every element again to see if that thing is in there. And if you then run Contains a hundred times, it's actually really slow and gets really, really scary as you have ten thousand things in there, thirty thousand things in there. And I find that's all over the place - it's in Contains, it's in Find-Bys and searching and you know, re-ordering, inserting to the beginning of an array has to push everything down. Right, you probably don't think about that when you insert something at the zeroth position, they have to go through every single other element in the array and push everything down. I call them secret loops - that's the easiest one to flip through your code and go hey, is there a way I can reduce the number of things I include things. Maybe it's I do it only once at the beginning and save the results and use those results to ___ everything. There's no general solution, it's different for every problem, but that's an important thing to keep at the back of your mind. The other one I find a lot of beginners do is - they go, my app is slow, or I want to increase performance. And they kind of just stare at their code. They kind of look at it, and they go -

[00:37:16.13] SY: It'll pop out at any moment.

[00:37:17.22] JB: It'll pop out, or yeah, it's going to come out of the trees. That function has a lot of lines of code - I bet it's slow! Those are all terrible. The best way to do it is to measure, is to really use these actually really phenomenal tools we have available to us as developers to see where the holes are, and that kind of focuses you down, and it's true, once you get focused out, you're going to have to spend some time staring at your code and thinking about it. But if you look at your entire application, there's too much stuff. Some of my favorite tools - if you're a JavaScript developer, the performance tab on that inspect element thing in Chrome or Firefox is phenomenal. It breaks things down by what's rendering, what's the network load, all these different variables. It'll even bring you down to the function level, or which function is spending the most time. It's really powerful. My favorite thing about it is it'll give you a time - it'll say, look, this is a two second page load. And then you can work and work and work and work and if you work for three days, and you say I made it way better, and you run it again and it still says a two-second page load - you didn't actually accomplish much. So make sure that you're measuring, you're using your __ tools to really focus your work, and you're using it as benchmarks. You're knowing that ok, I was at twenty, I was at two seconds, now I'm at half a second. It's a huge difference. If you never measured beforehand, you'd have no idea how much you accomplished. And in general, for other tools, on the Rails side, New Relic is great, New Relic also does work with Gnome Express. There's a bunch of other tools. Everything really has performance monitoring. And then my last one really is - loading too much data. I find when you do this stuff, you realize - let's say you're running a restful action, and you want to show all of the users events you have coming up. What you'll do is, you'll just run - get me all events, and on the front-end filter it by users - or something like that. Or maybe events has all these dependencies, so events has to pull in data about location information, location pulls in information about opening hours and all this other stuff. One thing I find that a lot of new people do is they load in way more data than they need. And a lot of times where this comes from is something we do advise, which is make it work. So when you're just trying to make it work, you just want to get all the data, and I'll sift through it later. But once you get to the point where you've grabbed all the data and you've sifted it down to just what you need, then it's time to think - do I really need all this stuff? What are the consequences of grabbing this and the dependencies and the other things that brings in? And I find that ends in a lot of slow-downs, is because what happens is they're just bringing too much, and the things they do bring in bring in other things, and it's this cascading effect of performance. So, if you get a chance, you can look and think, ok, if I pull the event information, do I really need all the location information, or do I just need whether it's open or not. I just need whether it's open or not - ok, exchange our ___ on the back-end side to just grab that information. I find that to be a really important one because as I say, when you start off, when you start off, you just want to do whatever you can to make it work, and then you sometimes don't go all the way to the next crossing, which is to pare it down a bit to just getting what you absolutely need.

[00:40:28.04] SY: Very cool. If you want to learn more about the Flatiron School and how to get started learning web and iOS development check out flatironschoolnewbies.com. Link is in the show notes. Ok, so we talked about fonts, we talked about images, let's do one more. What's one more thing, one more category of things, that we should take a look at?

[00:40:47.19] LH: I also am thinking a lot about interactions these days. So, I'll tell one more story that, when I was working at Etsy, we found that there's this term called jank, which means stuttering while you're scrolling through the page. So, you know -

[00:41:03.19] SY: Is that where janky comes from?

[00:41:03.27] LH: Yeah, well, I don't know which one came first, but yes, if a page is janky, it usually means it's stuttering when it's scrolling. Which is a performance issue. We ran an experiment in which we fixed the jankiness - in this case it had to do with the browser doing a lot of work to blend a bunch of shadows which we implemented with CSS. It just took the browser so much thinking that it caused that stuttering when scrolling. And we found that when we removed that stuttering issue, people favorited more often and favorited more items on the site, so think about the overall user experience - it may not be just how fast it loads from start to finish, it may be some of those interaction stuff too.

[00:41:41.20] SY: And I feel like there are so many websites I've seen where the animations, the interactions, the little things look cool, but I'm also like, you don't need this, this is so - this is adding so little to the page anyway. And now that we're having this conversation, it makes me wonder like, how much are they spending in web performance, how much does it cost them in web performance to be cute and be cool and fun, even though it's not really making my experience much better.

[00:42:10.23] LH: That's exactly why I recommend people measure it. Because, at the end of the day, if you run an AB test, and there's one slightly slower loading page than the other, but it's more beautiful, it's entirely possible it'll perform better for whatever metrics you're looking at - favoriting, conversion, whatever the thing is. So be willing to take that risk - just measure it first, prove to yourself that that little sacrifice in page speed ends up netting out a great user experience overall.

[00:42:38.07] SY: So you mentioned A/B testing, and that is one of the things that I understand on a very conceptual level, but when I think about actually implementing an A/B test, I feel like I have no idea where to begin. Can you give us a quick overview of what an AB test is?

[00:42:58.14] LH: Yes! I'm so excited!

[00:42:59.01] SY: I love that you're so excited.

[00:43:01.05] LH: Well, I'm excited because actually when I was first getting into public speaking, talking about A?B testing was my thing. Even before performance, really, so I'd love to talk about A/B testing. So A/B testing is effectively running an experiment in physics class or some science class. I remember we were learning about how to develop a hypothesis, and in science, how do you prove out that hypothesis, and you run an experiment, like a good scientist does. So you run an experiment that basically says, I'm going to have my original version of this page and then some difference. Maybe it's a performance test, where you made it faster. Maybe you're testing different wording on a page to see what impact it has. Maybe, if you're like Google, you want to test a different link color blue, just a shade different to find the best link color blue you can put on your page. So you run this test that compares these two versions - if you want to get really fancy, you can compare multiple versions, but I like to start with two, and you say to yourself, what's my hypothesis? Maybe you want to measure conversion rates, maybe you want to measure how fast the website loads, something else. You run an experiment and you see for a number of visitors, which one wins. And the words wins is kind of like, it's a really dicey word. I would recommend doing a little bit of Googling about things like statistical significance and how to figure out which version one. But by and large you can tell that fifty people see one version and fifty people see another version. In version B, every single person did the thing that you wanted them to do and in version A, zero people did the thing that you wanted them to do, you know that version B won. So at the end of the day, you can make a decision, have some good data to back up whatever your hypothesis was. Although, I will admit, humans are really bad at guessing which one is going to win, which is why people should be experimenting. Computers are way better at figuring stuff out - let's not trust our human instincts about which one is better for our users.

[00:44:55.14] SY: So, the part that I get hung up on when it comes to A/B testing is the winning part, because especially if you have - you're not Google, you're not Etsy, you don't necessarily have tons of traffic, tons of users - you're just starting out, you have a little project, and you want to do A/B testing. How many users is enough - what time period is long enough - to be able to draw helpful conclusions?

[00:45:20.01] LH: The classic A/B testing conundrum. This is really where computers come in handy. So, I can't tell you all the math that backs up how to determine something like statistical significance, but computers totally can. And there's a bunch of calculators online where you can type in the number of visitors to one of your versions of the experiment, hopefully before you started the experiment, you decided what action you wanted to measure, what thing you wanted to make sure could consider winning - maybe that's clicking on a link. So you type into the calculator, how many visitors saw each version, and in each version, how many visitors clicked on that link. And the computers will tell you exactly, whether one of them won, if it's not significant enough yet, it will tell you roughly how much longer you should try to run that experiment for to get that statistical significance - it's really hard to say!

[00:46:16.10] SY: That's awesome!

[00:46:16.18] LH: Yeah, A/B test calculators - they're great.

[00:46:20.16] SY: Very cool. Man, I should've had this conversation years ago. That's really helpful. Ok, so the other part that for me makes A/B testing intimidating is trying to figure out what I'm testing. Because say I pick an action like, I want people to hit the play button on this podcast episode page - there's so many things I can try. I can try optimizing all the images, I can try having similar fonts, I can change the layout, I can change - I mean, there's so many different variables that I could play with. How do you focus, how do you narrow it down to something that is useful?

[00:46:56.21] LH: Humans are really bad at guessing what's going to make an impact. As an aside, there's this website called Which Test Won and basically they show you results of experiments but they make you guess first which version won before you can see the results, and more often than not, I got it wrong. And in fact, when I was giving talks about this, I would show examples from the website and make my audience vote as to which version they thought won - and they were almost always wrong. It was amazing. It's a great example of why you should test things. But determining what stuff you should be tweaking in order to see the results that you want, maybe try to start by talking to a handful of people who might be users. Maybe not full-on user testing, but you know, I'll ask my partner, hey I want to make this link more exciting for people to click on - I want people to click on this more. What do you think I can tweak? And they might say, hey, move it up higher on the page. Or change the color to make it red, or something else, and I'll get a couple of good examples and maybe I'll run a couple of different tests, just to see, first of all, if any of them have any impact whatsoever. Because it's entirely possible that there's nothing that you can do that will change it for the outcome that you're looking for, which is a bummer but at least you know. But yeah, I just try a few different things. So when it comes to things like making sure someone clicks through to the next page and I'm thinking about tweaking performance, I might just try to overall see if there's stuff I can do across the board on the website to make it a faster-loading experience. And I can kind of hope and wish that any of those one things might make it such that I'll see the results that I want at the end.

[00:48:26.29] SY: My go-to customer for my customer interviews is my husband, who is the best and the worst person to ask for advice for design stuff. Because I'll show him something and I won't say is what the goal is, but I'll say what do you think, what's your initial reaction, walk me through what you see and how you experience it. And he'll give the world's most unhelpful answer, he'll just say, this is unreadable. And I'll say, ok, that's, I don't know what means. Can you be more specific. I've gotten to the point where I understand his reactions and what he means by them, so I've been able to translate them into actual code-speak. So the last time that he did this and he said, I can barely read, this hurts my eyes, is what he said. And I said, ok, that means the font size is too small. So then I increased the font size by a couple points, and he's like this website is perfect! There you go. Nailed it. Absolutely nailed it.

[00:49:21.06] LH: Perfect! (Laughs). That's some good user testing.

[00:49:25.06] SY: User testing, exactly. So, if you are a newbie and you build your first website and you realize that your website is slow and you're trying to not only optimize that website, but also just generally learn more about web performance and how to have best practices and good patterns and all that kind of stuff, where's a good place to start learning about this subject?

[00:49:46.02] LH: So, I wrote a book called Designing for Performance, it was published by O'Reilly, and yes I do have an O'Reilly animal for my book cover, and I actually made it free online in its entirety, coded up in HTML and CSS, and you can find that at designingforperformance.com.

[00:50:03.16] SY: I did see that, and I was so excited because when I was doing the photo optimization stuff, I said to myself, ugh, I really want to just read a book about this, and then I think I just remembered that you wrote a book on web performance, and I said, I should read that! But one thing that I was wondering was, for a book on Rails, for example, a new version of Rails came out - Rails 5.0 came out a year ago or two years ago - and so a lot of the Rails 3.0 and 4.0 books are kind of out of date. For web performance, does it go out of date that fast?

[00:50:32.03] LH: Thank goodness, most of it's still holds up today. I wrote in two-thousand thirteen, it was published in two-thousand fourteen, and thank goodness, it's not too embarrassing. I was, of course, immediately worried upon publishing it that it was going to be outdated, instantaneously. Thank goodness most of it holds up. I tried to cover the spectrum of things - images, design choices, fonts, caching, how to get your company culture to care about this. And by and large the things that I wrote there still hold true today, especially some of the stuff about how websites work, how browsers collect that information, what to measure, what kinds of things to watch out for - all those basics definitely hold up today. There's some brand-new stuff like, I really didn't cover JavaScript at all in there, so you'll want to go look up some other book for JavaScript performance stuff, but yeah, hopefully by and large it still is going to be helpful to people today.

[00:51:22.18] SY: Very cool. And that's the end of episode seven of season one, we've got just one more episode left in this season. So let me know what you think. Tweet us @CodeNewbies and send me an email hello@codenewbie.org. If you're in D.C. or Philly, make sure to check out our local CodeNewbie meet-up groups. We've got community coding sessions and awesome events each month, so if you're looking for real-life, human interaction, look us up at meetup.com. For more info on the podcast, check out codenewbie.org/podcast, and join us for our weekly Twitter chat. We've got our Wednesdays chats at 9 PM ET and our weekly coding check-in every Sunday at 2 PM ET. Thanks for listening, see you next week. (Music).