---
title: Website Optimization and Speed
date: 2021-04-13T05:00:00-04:00
author: Sean Smith
canonical_url: "https://website101podcast.com/episodes/season-04/episode-9/website-optimization-and-speed/"
section: Podcast
---
<!\[CDATA\[YII-BLOCK-BODY-BEGIN\]\]>[Skip to main content](#main-content)Guest Andrew Welch
After a stint running a software company for a couple of decades, Andrew is now immersing himself in doing consulting to help businesses use technology effectively.
[ ](https://twitter.com/nystudio107)
Season 04 Episode 9 – Apr 13, 2021
1:03:57 [Show Notes](#show-notes)
## Website Optimization and Speed
0:00
0:00
1.0x
0.75x1.0x1.25x1.5x2x
[](//dts.podtrac.com/redirect.mp3/website101podcast.com/uploads/mp3/season-04/s04-e09-website-optimization.mp3)
Website optimization expert Andrew Welch discusses optimizing your website performance and speed.
### Show Notes
Site speed is a ranking signal for google. Ensuring your website is fast and efficient can give you a boost in your SEO results.
We also discuss:
- How optimizing your site can improve your bounce rate
- Contributing factors to a slow website\\
- What you can do to improve your site without touching code
- Limit the number of tracking scripts
- lazy loading images / maps
- Web hosting - shared vs VPS
- Caching & Minifying
- Image Optimization / Responsive Images
Google [image srcset peas](https://www.google.com/search?q=image+srcset+peas) to find the article by Eric Portis that Andrew Mentions.
### Show Links
- [Andrew's dotall conference talk](http://dotall.com/sessions/making-a-craft-cms-website-that-flies)
- [Google PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights/)
- [WebPageTest](https://webpagetest.org/)
- [Tags Gone Wild! Managing Tag Managers](https://nystudio107.com/blog/tags-gone-wild)
- [Servd](https://servd.host/)
- [Fastly](https://www.fastly.com/)
- [CloudFront](https://www.amazonaws.cn/en/cloudfront/)
- [Responsive Breakpoints](https://www.responsivebreakpoints.com/)
- [Scrset and Sizes](https://ericportis.com/posts/2014/srcset-sizes/)
- [Andrew's Blog](https://nystudio107.com/blog)
- [Sean's Blog](https://caffeinecreations.ca/blog)
Powered Transcript Accuracy of transcript is dependant on AI technology.
**\[00:00\]** Hello, I'm Mike Mella. That's Sean Smith. This is the website 101 podcast. Welcome back. And today we have an excellent episode. We have a special guest, Andrew Welch, from NY Studio 107. He's a web developer. He's a podcaster. And we're thrilled to have him on the show to talk about website optimization. Sean, how are you doing? I'm doing great. I'm really looking forward to talking with Andrew. He's one of my favorite people in the craft community,
**\[00:30\]** an educator, and a true leader. Yeah, it's going to be awesome. And I'm sure everyone is going to learn, including us, a lot about website optimization and what you should be doing to make your website run as efficiently as possible. Welcome aboard, Andrew. How are you doing today? So, and Mike, thanks for having me on. I'm doing great. And I'm hoping to learn from you as well. So let's do it. All right. So Andrew, picture yourself aboard the Starship Enterprise, the Enterprise D with the entire crew of the next generation. Picard assigns you to an away mission with Riker,
**\[01:05\]** Troy, Wesley, and two other crew members. You realize you and the other two crew members are the only ones wearing red shirts. Oh god. You start to feel easy, uneasy about the mission. After an hour, your team is ambushed. The other two red shirts have already been killed. And suddenly the entity knowing as Q appears, snaps his fingers and stops time. He says, you can live if you tell me what website optimization is and why it's important. What do you say?
**\[01:35\]** First, I would compliment him because I know he's a very vain individual. I would pay him some compliments. And then what I would say is website optimization is all about courtesy. It's about making the experience for the visitors that visit your site to be a pleasant one. Regardless of the device that they're on, the connection that they're on, et cetera, et cetera. It's sort of like if you had a shop, you want to make it as inviting as possible for everyone
**\[02:06\]** to come in. You wouldn't want to have it to be inaccessible. You wouldn't want it to have it to be no parking out front. really that's kind of what you're trying to do when you're optimizing a website is you're just trying to make sure that the experience that people have is a good one. And the other person, person in quotes that you want to think about are bots when they are crawling your site, you also want to make sure that it is performant when they are crawling the site because they'll have a crawl budget and the quicker that they can do all their thing, the better.
**\[02:38\]** Yeah, and I guess a lot of that would involve, you know, the elephant in the room, I suppose, is like Google indexing your site and how efficient does Google think your website is because now we hear all these things about, you know, Google is punishing sites that are not optimized for mobile use and things like that. So, that's another, I guess, reason why everyone should be really mindful of this kind of thing, eh? Yes, it is what's called a ranking signal and there are lots of ranking signals. So I don't want to overstate it, even though I care a whole lot about web
**\[03:13\]** performance. It's not like it's suddenly Google is not going to show your page anymore. Like if you're Justin Timberlake and you have your own Justin Timberlake.com or whatever it is and it is the most inefficient piece of garbage website on the planet, you're still going to rank when someone searches for it. So it's one of many factors. However, the web is super competitive. So if you have other people in your space, similar name, similar industries, whatever, any advantage that you can get over them
**\[03:46\]** is going to be important from a ranking point of view. And it definitely is a ranking signal that will potentially affect that in terms of the Google page performance performance in terms of mobile and a bunch of other ranking signals, but the other thing to keep in mind is not just the search engine results, but when someone actually does click through, are they on their phone staring at a white screen for three minutes when they're trying to get into a taxi cab somewhere? Or does the page load quickly? Because they'll just bounce, man. People will just navigate away if the experience
**\[04:19\]** is poor. Or they'll just have a not great customer experience. So I mean, something to think about is not necessarily just is it a ranking factor, but what is it like for the person when the person actually does end up clicking through and getting to my page? I don't know how many times I've been frustrated trying to log into the CRA website. That's the Canada revenue agency. It is slow and clunky. It's like the IRS for Canada. It's a government website. It's slow,
**\[04:54\]** it's frustrating and basically I feel what you just described. Well, there they cannot care, right? Because if you have to log in to the CRA or whatever it is, then you have to. And there's no other choice or place you can go to. But if you actually, I go there once a quarter and that's it. I never go back. But it wants to get them, you're money. That's all they're interested in. Yeah. And again, if you're in some kind of a niche where you're the only game in town, then you can just happily, if you're insensitive, you cannot care about
**\[05:27\]** web performance, but if you're in a competitive market, which most people are, then you really do have to think about that and a whole bunch of other things as opposed to just the fact that the site exists, that you have to think about, is it a good site? And performance is one of those things that, in my opinion, determines whether it's good or not. I do it too, man. It's amazing.
make fun of people, you know, those young whipper snappers and so impatient, but I do it too, man, like, I'll Google something and I'll tap the result. And if that thing doesn't load in a certain amount of time, back button next result, like I do that all
**\[06:01\]** the time. I do too. Yeah, that's true. One of the, just to go back to something you were saying earlier about, you know, SEO and all that, I'm always saying to my clients that SEO ends when they reach your site, you know, like sure they, they search and they do that and they find you on the page one and and that's all great. But when they click on that link, suddenly they're in your hands, and Google's not gonna help you do anything. So if your site is a disaster at that point, it can still negatively affect your brand,
**\[06:32\]** even if you're at the top of the Google results for your... It's gonna increase your bounce rate. It's at a minimum if your site is unfriendly and slow. Yeah. For sure. Yeah, and the only part of S.E. Quote is sort of S.E.O. that continues on after that I think would be if they decide to share a link with the site, and then you wanna have the social sharing and all that kind of good stuff. But yeah, for sure, for sure. You can imagine again, like a real-world analog. You did some advertising or you've got a great signpost
**\[07:04\]** or someone pulled into your store, but you don't want it to be a dumpster fire when they walk in, where you know, they gotta walk over trash and, you know what I mean? And it's the same thing. Right, so Andrew, for our listeners are generally less technically savvy, you know, do it yourselfers or small business owners whether focused on their business, what are some of the contributing factors to a slow website that they may be unaware of? There are any number of contributing factors and what I would say is the best thing that
**\[07:38\]** you can do is be data driven in terms of what are we going to do to fix this site or to make this site better and to use any number of existing tools that are out there that will give you some metrics and tell you these are things that you could improve and they will even give you links to pages that will tell you how you can improve these things. And the reason that's important is, as much as I'm a fan of critical CSS, for instance, I don't think it's something that you should just jump in and add to your site unless it's
**\[08:11\]** part of your build process, and we'll get into that later, but part of my spiel is that it's not that much harder to build a performance site as it is to build one that's slow. You just have to up front set the expectations and the framework so that you are building something that ends up being performant. You start with the chassis of a race car, not the chassis of a Chevy Nova, and then you both, everything else on top of it. You used that exact metaphor in your dot all talk that I just watched this morning might
**\[08:42\]** have been a different, might have been a different car. That's funny. Well, that just shows you that I'm not very original. We did the same thing. We're always, the analogy we always say here is managing a website is like managing a garden not building a house. It's not like it's built and it's done. You always have to maintain it. We've said that a billion times on this. Mike uses that one. I use this like owning a car. So it's a flip on which one we're gonna talk about. Yeah. But, you know, the best thing you can do, I think,
**\[09:12\]** you know, we can go down a bullet point list of, you know, common things that you need to do, but the best thing that you can do is be data driven. So use Google PageSpeed Insights, run it on your site, and it will give you a list of things that it thinks are wrong, and it will rank them in order of importance, and you can attack them in order of importance. going to include a link to the Google page speed insights in the show notes. It's free service, you pop in your link and it tells you various things that are good or bad about your site at mobile
**\[09:43\]** as well as desktop and gives you tips on how to improve it. I use it all the time on every site I build. Yeah, Google page speed insights is great and also Lighthouse is great. It's something that is built into your browser. The only thing to keep in mind when you're using Lighthouse in Chrome, I should have said, it's built into Chrome, not whatever browser you might happen to be using. The only thing to keep in mind is that if you're running it there, it's testing the connection from your computer on your internet to your website's host. And that's what it's testing.
**\[10:16\]** If you use one of these cloud tools, lots of them will test for multiple locations or will it you pick from multiple locations and test the website. So I'm not saying don't use Lighthouse because is Google PageSpeed Insights actually incorporates Lighthouse into its results. All I'm saying is if you are testing locally, be aware that you're testing your connection from your computer and you're probably very high-speed computer, very high-speed internet to your website. And you may not be doing a realistic test.
**\[10:48\]** Yeah. But the other test that I do is webpagestest.org is a great website for doing testing. And I'm recommending that you do the tests first because you got to figure out what's wrong, right? And we also only have so much time to put into the optimization or maybe only so much budget, you know, depending on what the client wants. So let's get an idea what's wrong before we try to fix it. And another analogy that I use to discuss this is you wouldn't just go to your neighbor's medicine cabinet,
**\[11:20\]** you know, pull out whatever prescription meds they have and start taking them, right? because they may have a condition totally different than what you're suffering from. So why are you gonna do that? You gotta go, you gotta go to a doctor, you gotta get a diagnosis, figure out what's wrong, and then fix what's wrong with that specific site, you know? Right, right, that makes a lot of sense. So do what your software has maybe got a WordPress site or a square space site, some sort of page builder. What are some things that they could do
**\[11:52\]** to improve performance without actually touching the code. Without actually touching the code, what they probably could do is make sure that their images are optimal. Usually on any web pages, a large amount of the stuff that ends up getting downloaded are images. So they can make sure that they are sized properly, for instance, like you're not uploading a 5,000 pixel wide image that's displayed at 100 pixels across, you know. And these are things that those tools that I mentioned will pick out. you'll see immediately. It will tell you, Google page speed insights will tell you that these
**\[12:27\]** images are too big. But that is something you can definitely do is make sure that the images resize them in whatever tool that you want. There are lots of free tools that will even do it. And you can just resize them from there and make sure that the images are small because that's going to be one of the biggest things that gets downloaded. The other thing that a do-it-yourself offer can do or marketing types can do or whatever is don't go crazy with all of these tracking scripts that are on your on your website in terms of the marketing. Uh oh, Sean
**\[13:00\]** let out you let out a sigh. What's the matter. You mentioned is bread and butter. There's a reason I always do my page speed test before the site goes live because as soon as it goes live I knew marketing is going to touch it and add in like 25 different tracking scripts. And instead of getting in the 90s for Google page speed, it'll be down in the 60s. Yeah. Yeah. Well, and here's the thing to understand about that though, is as a developer, I share your frustration.
**\[13:33\]** But the people that are adding these tags are doing their job, right? They're like, I want to track this stuff, you know? Oh, I agree with it. It's just, do you need to add 5, 10, 20 different tracking services instead of only say two or three right well and what I'm suggesting is that they're not programmers so maybe you need to explain to them that there is a cost involved in adding these tags you know right and because I've done that I've gone in and I've worked with
**\[14:04\]** marketing departments and I've said hey did you know that this thing that you call a tag this is actually JavaScript that's added to the page. And here's the cost of that JavaScript. Not only does it have to be downloaded from somewhere, and it's going to download any number of other things that are coming down, but that also JavaScript is much heavier than an image. Like a megabyte of JavaScript is way more costly in a browser than a megabyte of an image. And the reason is that it's not just the download cost. It's that the browser
**\[14:36\]** then has to parse that JavaScript. It then has to execute that JavaScript. It may have to reflow the document. JavaScript can be very expensive.
And when you explain to them that this is something that they need to keep in mind when they're adding them, that can make it a little bit better. Like you let them know up front. This is what education goes a long way. Yeah.
And I do have an article on that that I'll link to you. Then we can put in the show notes for it, where it kind of talks about that, but try to limit the amount of tracking that you're doing. And not just that, like, have a plan because one of the things
**\[15:10\]** that I, especially people that are inexperienced with doing this type of thing, is they say, well, what trackers should we have? Well, let's just add every tracker that we possibly could have, because I don't know, like, you know, we might need it at some point, which is, they're all free. They're all free. Like, why not just add them, you know? And, yeah, I mean, we're, He does not mean without cost. That's a very good point. We're sitting here as developers going, oh my god, like, Facebook, please don't do this. But it kind of makes sense from their point of view,
**\[15:40\]** which is that they don't know what they're gonna need. Maybe they're not really sure, makes sense to kind of start capturing that stuff anyway. But it really, I've seen it so many times that they will add every tracker under the sun and will be investigating what they're actually doing with that data and they're not doing anything with it. You know, they don't have a plan of actionable things that they're gonna do with the data that they're then capturing. And we set up systems where a person,
**\[16:11\]** like a physical person would be responsible for every tag that was added, that would be attached. Their name would be branded to that tag that's added to the website, as well as a justification for what it was there for and what it did. And in larger organizations, especially, it was actually really useful because they could go back in and audit that. And they could revisit with the person and say, do we still need this? Are we doing anything with this, et cetera, et cetera? That's a great idea. So what do you do? You put it as a comment in your code or there's like a shared document
**\[16:42\]** with everybody in the company? Yeah, they have a shared or whatever system they're using. You know, if they're using juror, you know, whatever organizational system that they're using. But the real thing there was ownership because I can't tell you how many companies that I've gone into and they're asking me to fix stuff, and I'll be looking at it, and I'll be like, okay, do we need this tag?
And they'll be like, I don't know. Yeah. Why is that even there? Not sure.
Who put that in? I don't know. What are we using it for? I don't know.
And so this was designed to kind of solve that problem as well as help mitigate the problem
**\[17:15\]** of it affecting the front end performance. Right. Right. And what you said earlier about related to this, the JavaScript and how, you know, and load intensive job script is, I had a situation like that just yesterday with a client site where I did one of the speed tests on the site and one of the highest, I think it was like over two seconds of load time or something. Something was slowing it down and I was like, what? And God's name is this and I looked through the, because it does, as you said, give you
**\[17:47\]** you know actual examples of what the problem is. And it turns out it was a commenting, the popular commenting service called Discuss, where you can sort of plug in this thing and let people comment on your articles, which is very good at block spam, and it's good for a bunch of other reasons, but it also fires up its own whole set of JavaScript, and it said that that particular one, at least on that day, at that time, was causing all kinds of speed delays. And I remember having this problem on a previous site where I dealt with it by instead of just having it appear
**\[18:19\]** on the page, you'd scroll to the bottom of the article, and there's a button that says post a comment. And when you click on the button, then it loads because you've already decided to engage in commenting. So only then do you wait for this thing to load, and it doesn't slow down the page beforehand. So things like that are MailChimp was another where there's a MailChimp form to sign up for newsletter.
That loads a bunch of JavaScript in order to verify that it's a working email address and all that. So all these kind of things can weigh down your site. And there's things like hot jar and full story and all kinds of tracking stuff that adds scripts
**\[18:55\]** And just going back to what Andrew was talking about tags and stuff He shared with us in the chat a link to one of his blog articles tags gone wild. We will include that in the show notes as well Yeah, and you guys mentioned it. That's just something we see all the time right in terms of the marketing tags that are everywhere so and I really do think that that these people are professionals, they wanna do a good job at what they're doing. They just don't know that there's a cost to adding these things. So they're hedging their bets and they're just adding everything.
**\[19:26\]** And I do think that a little bit of education goes a long way in terms of just letting them know, hey, you know, you have conflicting goals here. You're telling me that you wanna convert customers but you're adding so many tags that you're causing customers to bounce because they don't wanna deal with the slow load times and the jank and the, they're either their fans turning on or their phone locking up. And if you explain to them that it's a competing goal that performance is directly related to bounce rates and you don't want the observer effect happening
**\[19:58\]** where you're adding so much stuff to observe them and see what they're doing that you're changing their behavior. You know, and I think that's a big problem. That is a good point. Addict orderly, I used to have a full story and hot jar on my site at the same time, just because I wanted to try it out. Sure. And after a few months, I realized that I was never using it or looking at it. Right. So I did a page speed test, and then I removed it, and I did another page speed test, and my score increased by like seven or eight points.
**\[20:31\]** Yeah. And it's out of 100, so that's like a seven or eight percent. That is a significant gain. Huge gain, huge gain. I mean, the best, the most performant code in the world is the code that never executes, right? So if we're talking about optimizing something, if you can just get rid of stuff, then that is the best optimization that you can make typically. And Mike, you made a great point about discuss and not loading that until you click a post comment button or whatever, something that I've also done
**\[21:02\]** is you can use a scroll API to know when that particular thing scrolls into view And then you can just lazy load it then. And it will just like magically appear. So think about it. Oh, that's the intersectional observer. Yeah, yeah, the intersection observer API. And what you basically do is it's the same thing with response, or sorry, with lazy loaded images. Where what's the point in loading images that the person can't see ahead of time, you know?
**\[21:32\]** And Google Chrome has added this to their browser and other browsers are following suit that you can add and attribute to your images, which is loading equals lazy, right? And the idea is that any image that is not above the fold and above the fold is whatever they can see when they first open their browser without scrolling. And so trivia here, which one of you folks knows why it's called above the fold? Oh, we're all, we're not, we're all here.
**\[22:03\]** Okay. Yeah, we're all old. We remember newspapers being folded up the newspaper machine and it's above the fold what the main headline is of the day exactly what you can see when you're walk by the newsstand or whatever and that's and that's where it comes from and the idea is that well there's no point in loading all of these images until we know if the users ever even as scroll them into view and that becomes especially important on mobile devices right because first of all the amount of stuff that they can see versus how much stuff there is is usually a lot smaller, and then also their connection is usually not nearly as good, and often is
**\[22:38\]** metered. Where they're being charged per gigabyte that they download or whatever, it's not unusual for people to have plans like that. So why load stuff until you know that they need it? So the idea with loading equals lazy is images don't load in until they scroll into view. Well, we're talking about doing the same thing with the discuss comments. I load all that JavaScript until they actually get down to where they could post a comment. And you're touching on one of my pet peeves, which is every freaking website in the world
**\[23:12\]** has a contact page with a map on it, right? Yeah. And nine times out of 10, they're loading all of the Google APIs to just draw this one stupid map that's just sitting there. And it drives me insane, okay, so first of all, number one, number one, don't load any of that stuff until you scroll down to it. Like you can lazy load that stuff. If you search like lazy load Google Maps, like you'll find it, it's no problem. The other thing you can do is why are you even loading all of these Google APIs to display this interactive map
**\[23:42\]** that people don't need to be interactive? Like just take a screenshot of the map and stick it on the page. Or if you really want to, Google has APIs for getting a static image, right? You can have the static image. And then if someone interacts with that map by clicking on it, well then you could lazy load the map APIs and let them interact with it if you really wanted to. But the real thing to think about here is when you're sitting there as a developer and you're building this thing, think about the other person
**\[24:13\]** that is sitting on the other end and what they're doing. They're probably on their phone. They may be in the middle of getting onto the tube or a subway, connection may be terrible. Think about them and only load what you need to load. Imagine that you're going camping, and you only really want to pack the few things that you're really going to need. You don't want to absolutely pack everything. And I think if we approach it from that point of view, thinking about different people in different scenarios that are going to be visiting the page, then we can start thinking about,
**\[24:43\]** okay, how can we make this better for everyone? Which is, again, in my view, that's what web optimization is about, is it making a better experience? Right, it's kind of in line with accessibility. And for users that say, well, everybody in the city has high speed internet and good connections and stuff. Well, they're not the only people visiting your site. What about people in rural areas that maybe they want to drive down to your site to use the Google Maps. If they have that image, they could just print the image
**\[25:14\]** or look at the image. They don't have to waste all of their valuable internet, which is usually metered out in the countryside and also slower. So it's not just people in the city, you have to think about all users. Yeah, and the other thing you can do is, you can just have a static image there. And this is a cheap way to do it. You can have a static map, right? Optimize, of course, like fit to size, do all that kind of good stuff. Lazy loaded, probably, because they're usually at the bottom of the page. You know, just add loading equals lazy. You don't need a, so I'm just gonna mention it real quick.
**\[25:46\]** You don't need any JavaScript, you don't need a polyfill. You can just add loading equals lazy. And if browsers don't support it, will just ignore it. You don't have to do any kind of feature detections, nothing you got to do. It eventually will be supported. You'll be making it better for a percentage of people. So why not? Just add the tech. Anyway, so I have a lazy loaded map image that's down at the bottom. And then if they click on it, have the URL be the URL to Google Maps that opens it up in a new tab with an interactive map. That's a quick, easy, no JavaScript way
**\[26:17\]** that you can add the interactivity and still have decent performance. And I also, I really like that as well, because if they click that on their mobile phone, it will open up the Maps app. And so they could start using that to navigate if you're in their car or whatever. Yeah.
Yeah, that's right. Because those little iframes of the map on a website often are a nightmare to use when you're on a phone because it's like, use two fingers to scroll the map and there's all this kind of special instruction. Sometimes it's better to just have it fire up the map. Yeah.
It's the worst. Like, I don't, I don't get why so many people are putting these interactive maps on.
**\[26:50\]** I don't know. Granted, some websites need it. You know, there may be a map based functionality that they have. And that's fine. But if it's just a store locator or something like that. Yeah. Or it could be any number of things like that. But if it's if it's literally a map to where your office is located or where your store is located, just make it a static map, make it a link to the actual Google, you know, link. So we'll open in whatever map that you're using. Just do that, you know. Mm hmm. Hi, hope you're enjoying this episode. We're always looking for topic suggestions.
**\[27:23\]** So if there's anything you'd like us to discuss on the show, please let us know. We're also looking for guests. If you have a guest that you think would be great for a podcast, please let us know. If there's a guest that you would love to come back, let us know. You can do that by visiting website 101podcast.com slash contact. So just let's take a little step back here. just before the sort of actual website optimization. I wanted to get your thoughts on hosting. So the vast majority of our audience probably has their site
**\[27:56\]** hosted on what's called a shared host. Can you tell us a little bit about what a shared host is versus say a VPS host and do you have an opinion about you know whether or not that is going to significantly affect the performance of a website? So real quick a shared host is kind of like living in an apartment. So you're in a smaller space and you are going to notice your neighbors more. You know, if you've got a kid next door to you or you've got neighbors next door to you that've got kids that are banging on the walls, it's going to infect you. If you've got neighbors upstairs
**\[28:27\]** that are doing marching band practice, you're going to hear it. So shared hosting is kind of like that in that you have resources that you're sharing with other people that are on the same host. If you have a VPS, then you are guaranteed a certain amount of CPU performance that you will always get, and it is yours and yours alone. At some point, it's all, as my friend Patrick likes to say, it's turtles all the way down, so even VPSs are shared at some point in terms of shared resources, but the key is that
**\[29:00\]** you're guaranteed an amount of compute cycles, whereas with shared hosting, whoever comes first gets it. you know, in the battle days, you used to see it all the time where there'd be like there'd be one site that's on the shared host that suddenly gets a lot of traffic and then everyone else's site doesn't even work. Yeah, I've had that happen twice in the past, yeah. Yeah, or they're on a website that gets hacked because of some bad code or plug-in and it takes down the entire server of 150 other websites that had nothing to do with it. Yeah, exactly. And a VPS is a little bit more
**\[29:36\]** abstracted out, again, it has guarantees in terms of how this will affect performance other than what you mentioned in terms of the, if something negative happens, it affects everybody. I think that you probably won't notice a huge difference in performance until you start getting up to scale where there's lots of people visiting the site. I mean, I in general recommend some kind of hosting where you are guaranteed a certain amount of something.
**\[30:06\]** You know, whether that's using Matt Gray's Served.host where he takes care of all the fancy framework for you or whether that means you have a VPS through ArchesTech or Fort Rabbit or any number of other sites that's fine or a VPS that you spin up and manage on your own via Forge or Play. I think what's important is that you have some kind of guarantee guarantee of what kind of compute cycles you're going to get out of that host. I think that's what matters more than anything else.
**\[30:37\]** If you're sitting up a new site and it's on some kind of shared hosting, just take a minute to think about it because there are so many solutions out there that will let you get away from the negatives of shared hosting and still have a very easy to use managed host. Right. So shared hostings, things that listeners would be familiar with would be things like goDaddy, Bluehost, HostGator, and you can hear Andrew groaning and I would be groaning
**\[31:11\]** if someone else was talking. So I'm with them 100%. So shared host like that, you're not going to get any sort of guarantee. And these are the hosts that you're going to get those repercussions that I mentioned earlier about your site getting taken down if somebody's hacked or maybe they get on the front page of Reddit or whatever. And people like those hosts because they're super, super cheap and affordable. But honestly, with a little bit more budget, you can get VPS hosting, managed VPS hosting for
**\[31:44\]** maybe $15, $20 a month. If you want to do it yourself a little bit more using something like like Laravelle Forge and digital ocean, you can do that for like 10 bucks a month. Even five. Even five. Yeah. It requires a little bit more savvy and knowledge, but you know, 15, 20 bucks. Like you mentioned, Archistak or served. I've got one client site on served and took me a little bit to get used to it because they have a different approach. But the support that Matt provides on there is top notch.
**\[32:18\]** Yeah. Yeah, I mean, I call it mccosting, you know, so yeah, absolutely. You know, if you have five bucks to spend, you know, you can get a big Mac or whatever. And if you have six or seven bucks to spend, you can get like an actual good burger somewhere. You know what I mean? I mean, it's not right. I don't know. You can go to the burger king. Yeah. Well. I don't know. Maybe. Maybe. Yeah. Um, so Andrew, uh, what's your thoughts on caching? Is this caching and minifying resources, which are other things that can help with optimizing code or optimizing your websites for?
**\[32:58\]** So the two things I have to say about that is, again, if you are a web developer, get familiar with what the best practices are for performance and build that into the way that you make sites. And I think you will find that you're not going to be really spending a whole lot of time, additional time, building sites that are performant versus building just sites the way you used to build them. There is a little bit of extra work in some areas, but in general, I think that if you start with a scaffolding that says performance matters,
**\[33:31\]** then you're going to end up with a site that by default is going to be pretty good, you know. It's not going to be terrible about it. If you are auditing an existing site, I would not get into any of this stuff. I wouldn't get into minifying resources, I wouldn't get into caching, I would measure what's wrong, and then I would address what's wrong and hit it from the top. A lot of times, minifying resources is not going to be at the top of a list of stuff that could be potentially better. It could be, again, it depends on the site and how bad and what's wrong with it.
**\[34:06\]** The idea with minifying resources is just especially on mobile devices. We only have a certain amount of bandwidth, and there's higher latency on mobile devices as well, which is the back and forth time, essentially. So let's make the stuff that we're downloading as small as possible. So if it can be compressed, compress it, if it can be minified, which is just removing the white space, then let's minify it as part of a built step. That can definitely be helpful. Clashing is basically just not doing the same work again.
**\[34:38\]** Imagine if you went to go brush your teeth in the morning and what you did is you went in and you opened up the cabinet, you took out your toothbrush, you shut the cabinet. Then you opened up the cabinet again and you took your toothpaste out and you shut the cabinet. Then you put the toothpaste on your toothbrush and then you opened the cabinet and you put the toothpaste back in. You know, and I mean, like you want to do all this stuff all at once, you know, and let's see idea with cashing too, is you also don't want to do the same thing
**\[35:09\]** over and over again. If anyone has kids, there's nothing more annoying than having to tell your kid, do this. They don't do it. Do this. I ask you to do this. Do this. You don't want to keep repeating yourself and doing it again and again and again, right? And that's really all cashing is. So cashing is some work was done. I'm gonna save this work. The next time someone asks for this work, I'm just gonna return the work that was already done. That's all that caching is. And in every computer at dozens,
**\[35:39\]** maybe even hundreds of different places, there is caching all the way down the stack in terms of stuff that is going on. Right. So caching is definitely something that can help you with what's called concurrency. So it's how many simultaneous requests, for instance, that you can handle. But really, if whatever you're returning doesn't need to be dynamic, then why are you dynamically figuring it out every time? Figure it out once and then return it. I mean, that's what caching is fundamentally.
**\[36:09\]** So basically caching the first time, the computer does the work, saves that information somewhere. The next time somebody wants to visit that page, just goes, oh, I have this over here in File Cabinet A and throws it at you. Boom. I've been doing all the calculating and processing and slow work. Yeah. You may think about it. You may build a website in craft or WordPress or whatever, and you may be like, whoa, but there's dynamic stuff in there. But is there really? Like I understand that it's computed dynamically, but are you returning the same thing to every
**\[36:43\]** person? And a lot of times you are. And if you are, then it doesn't matter how dynamically it was computed. What matters is the result is the same. So we don't need to do this every time. We can just do it once and then return the cache, you know? Yeah, I'm going through a situation like this right now with a client where I have, there's, there's article pages where they have, you know, the title of the body and all this. But then it also relates, every article relates to one or more authors, which is in a separate sort of part of the database.
**\[37:14\]** So then it has to pull their author name, their headshot, some of their bio, and it puts that at the bottom of the article, oh, and then it also has five images that are associated with this article and it has to go and get those. And then there's this caching plugin that I'm testing out right now where, once it does all that, as you said, it's almost like it takes a picture of the results, it's not literally a picture of course, but it just saves it as one flat file. So the next time someone comes and asks for the same thing, which as you said, if it's the same article, it's gonna be the same author, it's gonna be the same images,
**\[37:45\]** just serve up that picture. And then you don't have to ask the database for all this stuff. Yeah. Andrew, what about people who don't know how to set up caching? Maybe they've got a WordPress site? Is there something that they could do? Maybe install a plugin or use a third-party service or something? What WordPress plugin do you use? Andrew. So there's a WP total cache. There I think Jetpack has some caching stuff in it. I have not built or used a WordPress site
**\[38:17\]** in a very long time. So my knowledge is outdated, but I do know that there are a number of them. And do what you do with any system and any plugins, you search on what you're looking for. Look at the ratings, look at how many people are using them. Pick one that seems reasonable in a way you go. Right. Are there any third-party services that could help with site caching? There definitely are third-party services that you can be using. It may be a little bit difficult to get into it So there's a fastly, for instance,
**\[38:49\]** as a service that you can use. You can also use Cloud Front. And what Cloud Front essentially will do is, you can tell it any request for anything I want you to just serve it from a cache. And it will cache those pages. It will even put them on what are called edge locations. So if there's a server physically near you, it will serve it from there. The reason I kind of hesitated is that If you didn't design the site to be full page statically cache from the beginning,
**\[39:20\]** you could run into complications trying to implement that. Oh, okay. The reason is, okay, so let's say it's something simple like I've got a web page and it has a login. And then after you're logged in, it says hello Andrew, you know, or whatever, you can't use full page static caching for those pages because it's gonna be different for each person that's visiting your site, you know? If it's full page cache and Brian visits the site,
**\[39:52\]** it'll say hi, Andrew. Yeah, exactly, exactly. Now, a lot of sites are, that's not the case though. A lot of sites are just marketing brochure sites. There's no login. Nothing is different per person. Those 100%, you can just set up with Cloudfront and you just configure it to also cache all of the HTML responses that are coming out of there. And then you're good. And the only thing you have to deal with is making sure that the caches get cleared appropriately when you change content.
**\[40:23\]** All right, that's cool. All right, so let's get into image optimization a little bit if we can. I know that you have a lot to say you've written some plugins having to do with image optimization. What can you tell us about? We mentioned earlier, if you're taking pictures straight out of your smartphone and they're at 10 megabytes, do something before you upload them, make them smaller first or whatever, but what else can happen as far as optimizing images for a website? I'd like to interject for just one second. Last week, I had a client that I built their site
**\[40:55\]** with for a long time. And one of the staff came to me and said, I can't upload this image to XYZ page. Well, I opened up the image. It was a 5,000 by 3,000 pixel image, 15 megabytes. So the server doesn't allow you to upload that large of a file. I've just considered it like that. And, you know, the field instruction said, you know, put it at maximum 2000 pixels because it was for a hero image. It needs to be a little bit wide.
**\[41:26\]** It just couldn't upload. But it makes sense though, because a lot of people's phones, iPhones, like the default settings, if you don't change them, the images are incredibly big. So if they are, I have clients where, you know, their staff are abroad, elsewhere in the world, and they use their own phones to take pictures of their volunteers and things. So it makes a lot of sense that you might have a photo that's enormous. You know, it's not out of the realm of possibility. Just imagine if a visitor to your website goes to the site and you've got this 15 megabyte image
**\[42:01\]** that's displayed at 200 pixels by 300 pixels. That'll slow it down. Well, this is a case where I would say that, first of all, we should never be shaming or making fun of people that don't know that these images from your phone are huge, because it's very reasonable for a very smart person to not know that, right? It makes sense. Why would they know that, you know? Just because you know a particular sphere of knowledge doesn't make you, you know,
**\[42:32\]** any more or less intelligent than anyone else. Any anyone can fall victim to this, right? no matter what industry you're in, your developer, your someone that does audio, you're an artist, you know, whatever it is, the stuff we know, we think our assumptions that everyone should know this, you know what I mean? But you gotta think about it, your job is to make sure that they don't have to worry about that, right? So one of my number one rules is never display an image that the client uploads. If the client is able to upload it, never display that image.
**\[43:02\]** It is always something that you should be transforming into a size that is reasonable to fit and be displayed on the website. And I think that's on you as a developer to make sure that that is what ends up happening. Yeah. And I do that as well, but my point earlier was that to illustrate that clients or even owners of a website might not be thinking about how large the images that they're uploading. So even when that user resized it to say 2,000 pixels
**\[43:35\]** a lower megabytes, the actual final website is still going to be resizing and optimizing it using an image plugin or image server on the service on the server. Right. Yeah. And here's a way that I would couch it for everyone out there who's listening, who's a developer, maybe you have kids. If you leave a whole bunch of knives laying around on the floor of your house and your toddler comes over and hurts themselves. Who's fault is it? Who's fault is it that happened?
**\[44:08\]** Now, I'm not equating clients to toddlers, okay? But my point really is that it's your job to childproof your house. And it's also your job to clientproof the site so that perfectly reasonable things that someone might do are not going to cause a technical problem. And I think that's on you as a developer to do. Right. So let's talk a little bit about responsive images. I think our listeners have all probably heard the term responsive recently and you know generally
**\[44:38\]** it has to do with the site adapts to whatever screen you're using. So if you're using a small screen like a smartphone it sort of collapses into one column or whatever and you can still read the text that's not all tiny you don't have to zoom in. But how does that affect image optimization? What can you know what should they be mindful of? What should they make sure their website is able to do in the image realm as far as optimizing things for different platforms in that. So if you think about it, when a website is being designed, a designer will be using a full-screen browser,
**\[45:11\]** and they'll have this beautiful hero image that maybe it's even hand-drawn art that they created. And they just think this thing is the most amazing thing in the world, or maybe it's a brand image from the company that you're working for, and they're using this large browser window and they want it to look amazing as they're designing it. So they've got a 3000 pixel wide image, right? To make sure that it looks good on their high resolution screen, right? If that's all we ever do,
**\[45:42\]** then someone who's browsing your website on a smartphone from 2010 is gonna download that same 3,000 pixel wide image to display on a 300 pixel wide screen. This is a terrible situation. And it's terrible for a number of ways. So let's go all the way down the chain and look at why this is terrible. So number one, the most obvious one, probably, is that if they're on an older phone,
**\[46:14\]** they're probably on an older network. So it's gonna take a long time to download this image. Even if they're on a modern 5G network, it's still going to take longer to download it than it will on your high speed broadband internet, okay? Then the image needs to be somehow displayed. While the phone is either going to have a GPU built into it, which is dedicated for manipulating images or it's going to have to use its built-in CPU to resize this image into something that can actually be displayed on the screen.
**\[46:46\]** That actually is a pretty intensive thing to ask this little mobile computer to do. So it's got to physically resize this thing so that it can be displayed properly on the screen. And that takes up a whole lot of energy on their end to do that and then multiply that by any number of images that you have on the page. And let's go even further. So let's talk about the energy that is wasted from your phone trying to do this. Like your phone is now heating up. It's now become a hand warmer because it's trying to do all of this work
**\[47:18\]** to transform these images. And the cell towers are doing more work in terms of transmitting more data back and forth, like there's a cascade of harbleness that comes along with this. If you only give stuff, the biggest that it could possibly be. It's like if you went to a restaurant and the portion size that you got was for the biggest person that would ever visit that restaurant. So you get like five plates of food stuffed in front of you and people are there watching you going,
**\[47:48\]** okay, finish it, you know what I mean? It's like, I just wanted a small salad. It's not a good situation. So what the web standards have come up with is the idea of a source set, which is basically just a set. It's the same image, but it's resized to a bunch of different sizes. And then the browser can then pick, okay, based on the device that I'm displaying on, this is the image that I want. And it will be only that image will then be downloaded and then displayed.
**\[48:18\]** And there's a great website for getting insight into this. There's a responsive breakpoints. And you guys can put that in the show notes if you want. It's from CloudNary. They have a vested interest because they run an image transform service. But it's still a really nice website that will give you a feel for what it's like to generate a source set and what it looks like. Yeah, I opened up the site. It lets you upload an image. And then there's a bunch of sliders that you can move around to generate the image that you want.
**\[48:51\]** And there's another website that's one of my favorite things that, so I'll be honest with you, the doing responsive images right is actually kind of difficult to do. It really is. It is kind of a, it'll melt your brain a little bit when you're trying to figure out exactly what you should be doing and I don't know how deep you want it to get into it. It is complicated, it really is. but it doesn't mean you can't at least do the basics, and at least have made people's lives somewhat better. There's a difference between making people's lives perfect
**\[49:22\]** and making it better, right? And if we can do a little bit of work and make it better, that's, you know, you don't have to go all the way and make it 100% perfect. You can if you want, like I would encourage that, that's my personality, I would say, definitely do that. But it's better that you at least try to improve things a little bit, you know, the Camper's motto, leave things better than you found them, than it is to do nothing.
right. So I just don't want people to get discouraged and say, oh, this is so complicated. No, at least do the basics, at least provide a source set. So at least, you know, a smaller
**\[49:53\]** images can be picked. And what I do is, I always forget where this article is. But what I do is I Google image source set, SRC, SCT, and then P's P E A S like the P's, the vegetable. And I know it's crazy, but you'll find the article I'm talking about. It's from Eric Portis. I'll give you that when I when I'm writing up the short notes, I'll do that exact Google and you should you should just put that Google search in the show notes. Don't link to
**\[50:23\]** the site. Just put that piece. You should. I will. I will. I will. So, you know, this has been a really great conversation. And it might let Andrew just said it might feel overwhelming to have all of these things that you need to do. But the key is to do at least some of it make improvements because the returns will be that you're going to lower your bounce rate, you're going to improve the experience for your website visitors. And that should theoretically
**\[50:55\]** give you a better return on your investment. You'll get more conversions, more sales, more contact Forms filled out whatever the goals are for your website and the other thing that I would say and this is key for developers that are out there listening, not necessarily do it yourselfers, but developers that are listening is take a snapshot of the current clients, Google page speed insights before you do any work and then after you have done the optimizations
**\[51:25\]** take another one and show them the difference and the reason that matters is they're not not going to understand all the stuff that you did, and that's fine, they don't need to. But they will understand that Google says this was bad before, and Google this brand that I know and trust now says, this is good after, that'll make a big difference, and that will allow you to charge a little bit more for the work that you're doing because you are doing demonstratively better work. Right. And I do that regularly when I'm pitching the client
**\[51:57\]** or providing a quote, I'll take a screenshot of the page speed insight score of the current site. And I'll say, look, you've scored 60 or 40 or 20 or whatever it is. And this is my target for when I finish your website that it will be above 90. And that's always my target. I mean, I try for 100, but it's not always possible. But as long as I'm over 90, I personally satisfying. And when they can see an improvement from 40 to 90, wow. Yeah.
**\[52:29\]** Yeah. Yeah. And that's the two pronged approach that I take with it. So one is that if you invested a little bit in yourself to learn some of these things, then producing a performance site isn't usually that much more work than producing one that is not. And then on the other hand, if you are actually producing sites that are better performing, you can absolutely charge more for your services because you are delivering something that is demonstratively better. And when you combine those two things, one, that it's not going to add a whole lot of time
**\[53:01\]** to each project, yes, there will be some upfront learning, yes, but you'll be forced to grow a little bit. But I think ultimately people enjoy getting better at what they do for a living, you know. And then on the other hand, you are going to be producing work that is better than the average person. Can you use that as a selling point to your clients? Absolutely, it pays dividends. Anything that I've learned about website optimization, whether it's from Andrew or from other developers, has already paid for itself in my ability
**\[53:33\]** to deliver a website. The last website that I launched, I wasn't consciously thinking about optimization until just before the end, because I was crazy busy at that time. When did the page speed score? and I got 95, and I didn't actually do anything. I was just, because I had already knew all the best practices subconsciously. I was just building a site, got 95. So it's put the time in, it's worth it, and it makes it easier and better for your clients.
**\[54:07\]** That's exactly it, and that's why in, you know, master builders, that's why their rates are so much higher, right? They exist are really good at what they do, you know? I still remember vividly that we had some work done in our bathroom and we put in a new shower and it was these big pieces of glass that end up being joined together by silicone essentially. That's like the only thing that holds them together to give that nice clean look or whatever. The guy comes in to do it and he's like the man, like everyone gets out of his way,
**\[54:39\]** he walks in, he's got his silicone gun, he's up there and I remember him saying to me, he's like, if you could do a bead like this, you could charge $500 an hour or two. And then he proceeded to go up there and just, like, put out the most amazing, precise, all the way down and then he would just out. And I'm just like, you know what? That's an allegory for it. Like get really good at what you're doing and you can charge more. Jonathan Stark says all the time in his business-related podcast. You niche down on the specialist and you are the master.
**\[55:09\]** Yeah, yeah. Right. And to our listeners, anyone who's, you know, who is feeling overwhelmed or whatever or it's a little more DIY than what we're talking about. Feel free to reach out to someone like any of us and we'll be happy to help you with doing any kind of small optimization that needs doing, you know. Well, and that's the other thing. So a lot of, and I'm not pimping my services at all, but that is another thing that I do a lot of is developer training. And if you want a, if you're listening
**\[55:40\]** and you're a developer and you wanna get better at something, you can hire someone to train you how to do it and just cut your way through the learning curve or you can go to videos or you can go to articles. There's lots of stuff that you can do to make yourself better at what you do. Right, 100%. I have paid somebody to help me learn one key thing that I was struggling with. Sure. It had a difference. I've also bought courses from WestBoss or Udemy or whatever attend conferences.
**\[56:12\]** Another really great way to learn and improve is to write a blog post. I have a blog, Andrew has an amazing blog, but I also have a blog, not as good as his. But I am writing my blog post to future me. And as I write it, I learn it better because you're explaining it to other people. It helps you improve. That's 100% true. And first of all, thank you for the compliment, but I don't think that I would call my blog
**\[56:43\]** amazing, but the thing about it is, when you're writing, not only are you writing for somebody else, but I have found that I improved my code immensely when I do that. For two reasons. One, I'm like, well, I don't want to show anyone like this crap short cut that I took. Terrible. Why would I? You don't want to teach best practices, right? You tell your kids the best thing that they could be doing, even though you might not always do it yourself, right? And that kind of thing. But then also you think about it more deeply like it's going to rubber duck in.
**\[57:19\]** Well, yeah, what's what might someone not understand or in the process of explaining it, you actually figure out the problem better and then you can refactor the code to be better. And I agree with the the 100% going through the process of writing this out is super, super important. And for listeners who don't know what rubber ducking is, it's basically the ideas that you have a rubber duck or any sort of object, and you talk to that object about your problem and talking through the problem, you find the solution.
**\[57:51\]** So Andrew, thank you so much for coming out. Where can our listeners find you online if they want to find you? They can find me at nystudio107.com, where there are some articles and also at nystudio107 on Twitter. Awesome. Yeah, thank you so much, Andrew, for coming on the show. Really appreciate it. I say this all the time that everyone's going to learn a lot from this episode, but this time, it's really, really true. This time, it's for real!
**\[58:25\]** The website 101 Podcast is hosted by me, Sean Smith. You can find me on LinkedIn, my username is caffeine creations, or on Twitter, where my username is caffeine creation, C-A-F-F-E-I-M-E-C-R-E-E-8-I-O-M, or at my website, caffeinecreations.ca. And by me, Mike Mella, you can reach me online at BLikeWater.ca and also on Twitter and LinkedIn where my username is Mike Melon, that's M-I-K-E-E-M-E-L-L-A.
**\[59:02\]** Can I speak Canadian to you two for a second? Well, we're very Canadian. Can you, what is the word that you say when you're apologizing to someone? Sorry. Sorry. Thank you. So one of the things that my wife and our huge fans of Kims convenience, right, which is a Canadian set. I walk past the store, it's an actual store, it's not a set. Yeah, it's just, we absolutely love it. We think it's amazing. And one of the things we know it, and my wife pointed out to me actually, is that everyone was saying,
**\[59:32\]** sorry, sorry, sorry, sorry. And I was like, yeah, you know, I've noticed that a lot of Canadians say that. And then I thought about it. And I'm like, you know what? I think the Canadians are right as a matter of fact, because we say sorry, right? But it's not S-A-R, it's S-O-R. So it really should be, sorry. or re, yeah, sore, re, sore, S-O-R-R-Y. Well, okay, so I'm gonna put my linguistic training here. I have a master's in linguistics and this, I'll teach you.
**\[60:03\]** There is no right way to say a word, language drifts over time. Sure. And, all right, but it was, that's where accents and stuff come in. That's why the British sound different than we do. Or even in the United States, for example, you'll have the Boston accent or the five burrows of New York. I'll have different accents. I believe I kind of a standard Midwest accent because I came from Winnipeg, but like Newfoundlanders will say, sorry, different as differently as well.
**\[60:34\]** So there's really no right way. And that's why I'm a descriptivist, whereas there's prescriptivists with language. And that's kind of where you said, oh, the right way to say it is the Canadian way. That's kind of prescriptive. Well, far be it for me to argue with someone that has studied this, but I'm gonna do it anyway, because I don't care, because I'm gonna argue it anyway. If you have rules for a language, right? If you say that this vowel makes these sounds, and this consonant makes these sounds,
**\[61:04\]** I think you can arguably say that there is a right way to pronounce it. As an example, so when I grew up my grandmother used to say washing machine, put it in the washer. And I'm like, when I got old enough, I'm like, Grandma, there's no R in that word. There is no R there. I want to say that my grandmother was demonstrably wrong. Like I understand it changes over time, but if we have rules for this letter sounds like this, this consonant sounds like this, you know, I don't know. Yeah, I couldn't agree more and actually,
**\[61:37\]** I don't know if this particular one's gonna make it in the show because it's a little high level, but I want to ask you, how do you pronounce the web-related term that spelled R-E-G-E-X. You know what I mean? For regular expression. How do you pronounce that term? I say, I wanna know a bit too. I say reg X. Yes, reg X, regular expression. I say, I say rejects. He says rejects, and I know someone who says reg X. Reg X are things you don't want anymore.
**\[62:07\]** It's two words combined, reg X, reg X is the accurate way. the accurate way. I'm prescriptivist about that. That's for sure. Yeah. No, and Sean, like to your point, like I understand, it makes sense that language changes over time. The meanings of words change. I'm on board with that. I'm on board with the meaning of a word can totally change over time. There are words that we could use before. Can't use now or words we used to use that used to mean one thing. Now they mean it totally. I understand. Language is totally fluid. It's whatever we make of it. But if we're going to lay down the rules for this
**\[62:39\]** This vowel makes this sound. This consonant makes this sound. I think we can arrive at, this is a correct way to say it. There has to be an incorrect way to say a word, right? Well, yeah. So if they're sorry, if they're sorry, right? I say sorry, you say sorry. If I said, Viel's a bug. You would tell me that's the wrong way to pronounce that word, right? Like that would be demonstrably wrong, right? Right. I want to say that there is a correct way to pronounce a word in time, at a specific time
**\[63:11\]** and a specific location. At this specific time. Oh, does not make an art sound, it doesn't make an a sound. So it shouldn't be sorry. It should be Google sorry. Google the great vowel shift, that's all I'm gonna say. In your spare time, Google the great vowel shift took place in the 1400s to 1500s. I'm afraid to. I'm afraid I'm gonna get lost in YouTube for days. Old English is pretty much incomprehensible
**\[63:42\]** to modern speakers. Right. Yeah. That's true. I have heard that, yeah. Well, and there have been answers. We've gone way off. Yeah, okay. I'm sorry. I don't know if we should cut this or not. It's kind of fun though. Maybe some. Whatever you want. You would put an extra to the end or something.
Close Transcript
Have a question for Sean, Mike, and Amanda? [Send us an email](/contact).
[](https://www.google.com/podcasts?feed=aHR0cHM6Ly93ZWJzaXRlMTAxcG9kY2FzdC5jb20vZmVlZC5yc3M%3D)[](https://itunes.apple.com/ca/podcast/website-101-podcast/id1449510012)[](https://open.spotify.com/show/3rmSM1R9t6q1U8DmYWJRSO?si=NrYPMgDaRV6Dd56PjEaPow)### Season 04
- 1 [ 'Click Here' Hurts Your SEO and UX: Why It's Time to Change](https://website101podcast.com/episodes/season-04/episode-1/click-here/)
- 2 [ How to Talk to Your Web Developer: Communication Tips for Clients](https://website101podcast.com/episodes/season-04/episode-2/how-to-talk-to-your-web-developer/)
- 3 [ Red Flags](https://website101podcast.com/episodes/season-04/episode-3/red-flags/)
- 4 [ Content Strategy](https://website101podcast.com/episodes/season-04/episode-4/content-strategy/)
- 5 [ Accessibility](https://website101podcast.com/episodes/season-04/episode-5/accessibility/)
- 6 [ Improving Your Website Without a Redesign: Content Audit, Usability Testing & More](https://website101podcast.com/episodes/season-04/episode-6/how-to-improve-your-website-without-doing-a-full-redesign/)
- 7 [ Content Marketing](https://website101podcast.com/episodes/season-04/episode-7/content-marketing/)
- 8 [ Alternatives to Google Analytics](https://website101podcast.com/episodes/season-04/episode-8/alternatives-to-google-analytics/)
- Bonus[ Listener Survey - What Topics do you Want to Hear More of?](https://website101podcast.com/episodes/season-04/episode-/listener-survey-what-topics-do-you-want-to-hear-more-of/)
- 9 [ Website Optimization and Speed](https://website101podcast.com/episodes/season-04/episode-9/website-optimization-and-speed/)
- 10 [ Exploring WordPress Website Development with Laura Bailey](https://website101podcast.com/episodes/season-04/episode-10/wordpress/)
- 11 [ From Novice to Bootcamp Instructor](https://website101podcast.com/episodes/season-04/episode-11/from-novice-to-bootcamp-instructor/)
- 12 [ Pimp Your Typography](https://website101podcast.com/episodes/season-04/episode-12/pimp-your-typography/)
### All Seasons
- [Season 01](https://website101podcast.com/season/01/)
- [Season 02](https://website101podcast.com/season/02/)
- [Season 03](https://website101podcast.com/season/03/)
- [Season 04](https://website101podcast.com/season/04/)
- [Season 05](https://website101podcast.com/season/05/)
- [Season 06](https://website101podcast.com/season/06/)
- [Season 07](https://website101podcast.com/season/07/)
- [Season 08](https://website101podcast.com/season/08/)
- [Season 09](https://website101podcast.com/season/09/)
<!\[CDATA\[YII-BLOCK-BODY-END\]\]>