This course has been updated! We now recommend you take the Introduction to Gatsby, v2 course.
Transcript from the "Fast Websites by Default" Lesson
[00:00:00]
>> Jason Lengstorf: The ultimate goal here is that we wanna give you good defaults so that, right out of the gate, you will create a Gatsby site and publish it with no changes, and you're gonna score straight hundreds on performance audits. You're going to deliver an experience that loads in under a second, or under two seconds, for people on mobile phones.
[00:00:20] And these are the types of things that make a huge difference. We're not talking about strict performance in this workshop. But there have been a ton of studies about how much it affects conversion rates and revenue to have a web site load faster. Over three seconds you start losing about 50% of your traffic.
[00:00:38] That's a really high bounce rate. And so you wanna make sure that you're getting under that. So under the hood we set a bunch of good defaults. We follow the purple pattern, which if you've ever listened to he talks about this a lot. I'm not going into what that is today, but this is a great thing to Google later if you're interested.
[00:00:55] If you're not interested, don't worry about it. Gatsby does it for you. We also do other performance best practices, code splitting, and pre-fetching in the background and all this stuff. We generate only static assets so we're not gonna make you stand up a node server in production. We're not gonna make you worry about whether or not your database is highly available.
[00:01:14] It doesn't matter because you only need your server and your database to be available during build, and then after that the site can't really go down unless the CDN fails and so that gives you security benefits. There is no database access so you can't get your database hacked through your website.
[00:01:31] It's a static site. They can deface it, but then you just like reupload the files and it's gone. They have no server access. They have no database access. You also optimized and lazy-load your assets. So your images are gonna get automatically scaled down and we generate the right sizes for different resolutions.
[00:01:49] We do a lazy-loading solution that's going to kind of blur in the full size image so that you don't get jank as the images load. But also it doesn't block the page from loading. We normalize third-party data. We talked about this with the content mesh. Again, the reason this is valuable in setting right defaults, making the right thing the easy thing, is if you're running an agency, if you're working as a freelancer, your clients are gonna have different systems that they use where one's gonna wanna use this CMS.
[00:02:19] One's gonna wanna use that CMS. And the overhead of switching between those projects can be really high. But if you're using Gatsby, because it's normalizing that data, your team now has a lot of transferability because the overall structure of working on a Gatsby site is really familiar, no matter where the data comes from, because it's just reacting GraphQL queries.
[00:02:41] So you get a lot more crossover between teams, a lot more ability to quickly collaborate, without a lot of context switching.
>> Jason Lengstorf: But importantly, we wanna make sure that developers don't lose control. One of the things that's really challenging about zero-config solutions is that they set good defaults.
[00:03:00] But then when you find yourself wanting to leave those defaults, you end up ejecting the entire app. You have to maintain everything. So we wanted to make it so that if you need to add a new web pack loader, if you wanna change up your babble config and use type script or reason or whatever as your build layer for your Gatsby site, you can do that.
[00:03:19] You can modify this config. But you only have to customize what you need. If you change your web pack config, that doesn't mean that you have to completely give up all of Gatsby's defaults and then suddenly manage them yourselves. You're able to just customize the thing that you want to customize and then we'll compose that together so that you are only ejecting the piece that you need.
[00:03:40] We call this progressive disclosure of complexity. If you are interested in the kinda learning theory behind why we do that and what we're after I've got a blog post on it and we talk about it kind of frequently. It's a little beyond what we want to talk about today.