Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I am Dave--what's going on in this world?--Rupert and with me is Chris Coyier. Hey, Chris. How are you?

Chris Coyier: Yeah, it's a hell of a week to be doing this. I feel like we couldn't stop talking -- everybody couldn't stop talking about damn COVID-19 and all the lives that it's taking and now, all of a sudden, we have George Floyd getting murdered in Minnesota, and the world is in a bad place because of that.

I would just say that we're going to do this show and we're going to talk about Web technology. If you're just not up for it and you're just not ready to hear about Web stuff--and I said this in the CSS-Tricks newsletter, too--just don't listen to it then. It's okay to, like, mute us. Move on. Delete. Unsubscribe. Get this away from you if you can't stomach it right now. That's understandable.

I know I've been trying to research the best things I can do and it's very gut-wrenching because I don't know how best to use what little I have, but I've been finding organizations to donate to. I found one about police reform that I thought spoke to me well that was, like, this is good. They have a plan. They really understand what's happening here and know how to use the money that I'm about to give them and I'm happy to do that, so I did that and I've been listening to the ones that other people suggest that are definitely way smarter than me about who needs it right now and trying to donate to those as well. That's been my strategy.

Dave: Yeah. I think I'm in the same boat. I'm very must listening. This social justice or just even the dignity of human beings is very much something I believe in and care about. When I see rioting, big protests, and things like that, I know there is a human instinct in some people to be like, "They're doing a bad," but I think you have to look at the underlying subtext of what went wrong. This doesn't just happen out of anywhere, what went wrong, and try to listen to the right voices who are experts in this and that's what I've been trying to do. I'm giving my money where I can to, like you said, organizations who kind of have been in it for a while and are trying to figure it out.

I think we should say here on ShopTalk, we do believe that black lives matter. You may be like, "Oh, this is a political podcast now," and I feel like it's a very apolitical statement. I feel like you're just saying that people matter, people of color matter, and I don't think that that should be a controversial statement. If you disagree with that--

Chris: Oh, my god. I had to go on Twitter today--

Dave: Yeah.

Chris: --and all the trending hashtags were all these -- I don't even want to mention them because I've heard people say that even mentioning the names of these stupid movements is harmful in itself. Even when they're subverted and taken over by people just trying to shut them down, the name of the moments is then still up in your face.

Dave: Mm-hmm.

Chris: I don't even want to say it, but anyway--

Dave: Yeah.

Chris: Did you read Barack's Medium article? I can't believe he posts on Medium, but yeah.

Dave: Well, yeah. He needs his own blog. Let's be honest. But it was nice that--

Chris: I will make Barack Obama's….

Dave: --the President blogged. It was very nice to have a president….

Chris: We'll put together a diverse staff of developers to build your blog, Barack Obama. I will--

Dave: [Stuttered]

[Both stuttered]

Dave: Blog Obama.

Chris: That's the best.

Dave: Okay.

Chris: I like what he had to say here. He said, "On the other hand, a small minority of folks who resorted to violence in various forms, whether out of genuine anger or mere optimism, are putting innocent people at risk, compounding the destruction of neighborhoods that are already short on services and investment, and detracting from the larger cause. I saw an elderly black woman be interviewed today in tears because the only grocery store in her neighborhood had been trashed. If history is any guide, that store may take years to come back. So, let's not excuse violence or rationalize it or participate in it. If we want our criminal justice system and American society at large to operate on a higher ethical code, then we have to model that code ourselves."

I always like how he speaks in that way about, it's action that matters. You have to do the thing that you want other people to do.

Dave: Yeah. I agree. Maybe we just leave it there because, you know what, we're not experts in this.

Chris: No.

Dave: You can even look at ShopTalk. The guests we've had on are majority white, probably the majority male, and so that is, you know, we're in some ways part of the problem. We work hard to not be that and we are conscious of it but, yeah, even still. Anyway, we're trying to get better and we actively do work on this stuff.

Chris: Yeah, for sure.

Dave: Just know that we are working on that.

Chris: We'll do better. I'm going to put an HR element into the show at the moment.

Dave: Mm-hmm.

Chris: I'm sure Chris Enns will put an actual timestamp or something here and we'll now talk about technology, the focus of this program. We have some questions from guests that would be fun to get into, all kinds of good ones coming in lately. I'd encourage you. I think maybe the redesign of the site so far has encouraged that because there's a big Ask Us link in the header, like there should be. That brings up a form and, of course, we love it when you have questions for us.

You can feel free to just submit topics, too, just things that you just think are interesting happening in the world of building websites that you just could imagine weighing in on or hearing Dave and I talk about. That's kind of a fine thing, too. It doesn't necessarily have to end in a question mark character. You know what I'm saying?

Dave: You can ask us about banjo.

Chris: Sure.

Dave: It doesn't even have to be tech, to be honest. I don't care. [Laughter]

Chris: I bought a new one.

Dave: Hey, I did too, but it's getting built. It got shut down by COVID. I told you that, though.

Chris: Oh, yeah.

Dave: I told everyone here that.

Chris: But is that the Deering or no?

Dave: The Deering, long neck, yep.

Chris: Do they do custom? I always think of Deering as like a big manufacturer.

Dave: They are, but I don't think they keep a lot of long neck banjos on the rack.

Chris: I bet not. Yeah.

Dave: I think they have the shell. They have the neck. They need to bolt them together and then send it.

Chris: I've never even touched a long neck. Is it in a different key then or is it so long that it's just an octave down?

Dave: Your standard banjo is in a G key.

Chris: Yeah.

Dave: Welcome to Banjo Time. [Laughter] I'm Dave.

Chris: Oh, it's an E, it looks like.

Dave: It goes to E, and so if you want to play in G, you capo 3, just like a guitar would, you know.

Chris: Ooh. Yeah.

Dave: Yeah, and so you can drop down to E to play with maybe somebody who is playing a guitar or something like that, a little easier because playing E--

Chris: Yeah, but then if you're going to do that all the time, why did you buy a long neck?

Dave: Well, you get two, three, or four keys, like drop C or whatever on a banjo.

Chris: Sure. Yeah.

Dave: So, you could drop it and get into drop D, I guess, would be--

Chris: Yeah, it's more built for that.

Dave: Yeah, it's a little more versatile and I think it was a Pete Seeger kind of invention.

Chris: Yeah. Yeah. Yeah.

Dave: Yeah.

Chris: Oh, my god. These conspiracy theorist Twitter accounts tried to hammer me the other day that were--

Dave: Oh, really?

Chris: I thought of him because Pete Seeger had "This Machine Kills Fascists" on his guitar and I always thought that was fucking awesome.

Dave: That was Woody Guthrie.

Chris: Oh, it was Woody Guthrie. But you know what? There is some crossover there.

Dave: Yeah, because Woody--

Chris: I think Pete Seeger--

Dave: Woody and Pete Seeger were buddies, a lot.

Chris: Yeah.

Dave: They maybe even, like, traveled on railcars together. But Pete Seeger's banjo said, "This Machine Surrounds Hate and Forces It to Surrender," I think. "Surrounds Hate with Love." Hold on.

Here. It is -- I'll find it here. It's Pete Seeger banjo. Yeah, "This Machine Surrounds Hate and Forces It to Surrender," and it has a peace sign on it. He hand-drew on his little banjo, but it was very much, like, in the--

Chris: The spirit of Woody Guthrie's thing.

Dave: Of "This Machine Kills Fascists," yeah.

Chris: Yeah. Yeah.

Dave: Yeah, it was very similar.

Chris: I had it as a decal, which I just bought online and put on my laptop, and so there are a lot of pictures with me with that laptop open, like at conferences and stuff.

Dave: Yeah.

Chris: If you crop them just right, it's my face and the word "fascists." This guy spent a lot of time making sure that he had these photos all set up.

Dave: Trying to zing ya.

Chris: Yeah.

Dave: Trying to just -- whoof! Yeah.

Chris: Which, like, it's in the same font as the Woody Guthrie one. It doesn't take a genius journalist to figure out what that stick was -- what was happening there.

Dave: [Laughter]

Chris: I'll tell you, though. E, I can't -- E cord. That's wild. As I play a lot of old-time music, I'd say there's an awful lot of them in A, an awful lot in D, and G, of course, is kind of the standard tuning. Once in a hot minute you'll play a C tune because, in D, you capo up to 2. It's like that same tune un-capoed, but never once would an old-timer do an E. That's just old-time.

Dave: Well, yeah.

Chris: There's plenty of folk and blues is heavy on E.

Dave: I think that's it. Yeah, I think it's sort of like if you wanted to play like Lead Belly or something like that.

Chris: Hell, yeah. Hell, yeah.

Dave: Now you just get down to there, so I don't know. It's just something I've been fascinated with. For most of its life, it will be a capo 3, just a regular banjo in G, but you know.

Chris: It's also just striking looking.

Dave: Striking! That's right. It's cool. It's big. It's a big boy banjo.

[Laughter]

Dave: For a big boy like me.

Chris: Do you have a service worker in production anywhere?

Dave: Oh, yeah. Heck, yeah. DaveRupert.com.

Chris: Really?

Dave: Yeah.

Chris: Is it for offline or what does it do?

Dave: It does offline stuff and then caches assets. I think my big thing is--

Chris: Really? Asset caching.

Dave: I'm big on network first for documents, like your HTML is network first.

Chris: Yeah.

Dave: But your assets would all be service worker first. Does that make sense?

Chris: Yeah.

Dave: It sort of falls apart when you actually get into single-page apps. I've had it go very bad. [Laughter]

Chris: Hmm.

Dave: You almost want to network first on single-page apps just because I don't know what it was, but I was getting flash pop in Firefox and stuff like that. I don't think it was Firefox. I think it just was the service worker was delivering the JavaScript before something. It just was happening too fast or something, and so it just created a glitch. I kind of had to back out of--

Chris: Really? Just spasticity is what hurt you. Hmm.

Dave: I think just because your whole thing is a JavaScript file, and that's the sort of thing too. If I get a stale JavaScript file, that can be bad in a single-page app.

Chris: Yeah. I see you got CloudFront in front of your assets, too. It's service worker first, then CDN? That's nice.

Dave: Yeah, well, that's Netlify doing that for me.

Chris: Oh, it is. Okay.

Dave: Yeah, and so yeah.

Chris: Netlify uses CloudFront? Really?

Dave: That's really surprising.

Chris: Isn't it? At least to not even obscure the URL?

Dave: I don't know. Yeah.

Chris: Weird.

Dave: Oh, maybe some -- like certain assets. No, that's what it looks like. It's rewriting it. [Laughter] CloudFront.

Chris: What if you want to -- your little warrior barred guy here--

Dave: Yeah.

Chris: You want to put a backward hat on him.

Dave: Use hammer.

Chris: [Laughter] Sorry.

Dave: Yes. He's defender of news websites, Chris. He's the lord of news websites and he will bring them back to justice and performance and content.

Chris: Yeah. He's the Michael Donahoe of WebP.

Dave: He's news hammer. He will bring news back to its rightful place in the world.

Chris: Oh, that's great. Is your setup such that you could just put a new WebP in your localhost, ship it, and it just updates or do you have to manually update a Web worker that says, "Ooh, I changed this graphic. I'm going to ship a new version of my service worker because it has a new URL for this asset"?

Dave: Good question. I would usually try to add it to the service worker if I feel like it's a critical asset. I used to have it, when it was very big, I used to make sure it was in the service worker just because I wanted second hits to be as fast as possible to the homepage. That asset is not going to change that often. I just wanted it to be as fast as possible the next time….

Chris: Is the service worker even better than browser cache? The second hit, you'd think browser cache would have it and then that's that.

Dave: Yeah, browser cache would have it but it's more like a -- this kind of gets into that recent WebKit change in the service worker.

Chris: Oh, it'll have it for a week [laughter] or whatever.

Dave: Until somebody decides, whatever, until the garbage man or the street sweeper comes by and makes you move your car or whatever. Yeah, because it would do a one-week cleanup or something like that.

I think the idea is, it's in a bit more of a cold storage on the device, on the client. It could be readily accessed, and so that's what I would do. Some people go overboard. I don't think there's a limit right now, or 40 megabytes is the limit before it even says anything. I think that's something.

There are things I've been considering doing like you go to my homepage. You get five article lists, I think, on the homepage, or something like that. I doubt anyone is going to click through all five articles but I could programmatically do caches.add or whatever it is and add those five posts to the cache instantly, so they're already there preloaded, basically, the HTML at least, before you even get there. That's something I've been--

Chris: Oh, yeah. That's pretty cool. That's where my mind -- you know that's a huge use case of service workers is this offline stuff, like how incredible that is. But I think, all along, the messaging was pretty good by the creators. It's just a lower-level API. You can do all kinds of stuff with this and it gives you this powerful kind of middleman layer to manipulate things.

Dave: Mm-hmm.

Chris: Another thing that you could -- it's not just for cache. You could also pluck it out of cache and run a query selector statement, "Find the H1 on your page and 50/50 it with another, different H1."

Dave: Mm-hmm.

Chris: You could do that. You could do that.

Dave: Yeah.

Chris: You could implement your CDN with a service worker. You could say, "Find all the URL requests that are this URL and then, instead of sending it to doing a fetch for its normal location, just change out the hostname to where the CDN is instead. You just have this middleman, which is just so cool.

Andy Bell, just this morning, I think he's probably going to do a post on this--showed me how he uses a service worker to intercept the URL to either serve the logged out kind of presale page that's like, "Hey, you could have access to this content if you paid for it, but you haven't, so here's the sales page." Then if you're logged in and authenticated, which it knows via kind of like a token that it has storage of, well, the service worker then replaces that content with the logged-in version of it. How rad is that?

Dave: Yeah.

Chris: Because it has a different environment variable it can latch onto. How powerful is that? It has nothing to do with caching. It has to do with manipulating the HTML before it gets shown in the browser.

Dave: No, I mean it's kind of cool. The limitation is you have to load the site first. The site has to load and then the service worker gets registered. It's always a second hit technology, if that makes sense. It's a second visit technology.

That said, it's really powerful. You could do a cloud to but and rewrite every instance of the word "cloud" to "but" on your website just through a service worker. It's very cool. You can manipulate responses.

I had one, not on this site, but on Daytrip, I think it was, which was very cool because it was a site that was designed to go out into the woods, right? The chances of you running out of network connectivity was very, very high. We would cache everything we could, but then if we didn't get a response, like the fetch request failed, we would send back an SVG with an X in it as, like, "Couldn't find the image." Instead of broken image placeholder or something like that, you got an SVG offline or something. You could make it say whatever you want in the SVG. It's like three lines of code to serve back an SVG instead of a broken image. How cool is that?

Chris: That's extremely, very, super cool. [Laughter]

Dave: Then even there, if we knew -- let's say you had some favorite spots, we could cache all your favorite spots in the thing or in the cache through some query and those would always be loaded for you. You'd always have access, even in the woods, to your favorite spots. If you needed information, tips, or whatever, that app is kind of atrophied on the vine as we've started working on something else. It was very cool to experiment with that technology in that context because it was designed just for it.

Chris: Yeah. Yeah.

Dave: I remember driving across Iowa with my parents one time while we were making it. I was just checking it and I just couldn't get anything. I just was like, "I need a service worker," because I just was getting white screens while it was waiting to load.

Chris: Right.

Dave: That's why I come back to it'd be….

Chris: That's an area where they're like -- because what I wanted to get to was kind of comparing them to Cloudflare workers or Netlify has some Edge stuff, these services that can do similar things but they do it instead of you doing it, a service worker.

Dave: Yeah, so it happens at your CDN or your server.

Chris: Right.

Dave: In front of your server.

Chris: But they can't do the offline stuff because that needs to happen at the browser level, you know.

Chris: Yeah. Yeah.

Chris: But it's these other things that you might need to do, they can almost do better because, for one thing, a service worker needs to get installed, so it has to be on the network once. Where, as in these cases, they don't. This executes on the very first request, you know.

Dave: Mm-hmm.

Chris: Which is kind of rad. And they have access to data store stuff too, so it's like holy crap. How cool is that?

We've started using it at CodePen. I think there was an episode about this. It's like we can do this thing. We have a URL for the screenshot of an image. This has evolved five times throughout the history of CodePen, but now it can just be a URL.

We don't have to set up a whole queueing service that takes these screenshots and puts them in a bucket and has this URL resolve to that location. Just the URL itself can do it. The URL itself can hit a worker first and the worker can do the work it needs to do to generate the screenshot, put it in a bucket, and cache it.

It caches it with a key-value store, like, "I have got this one. Don't try to regenerate it again." That way, the very first time that image is ever requested, it can generate the screenshot on the fly, put it in a bucket, and now it's just got it.

Dave: Hmm. Yeah.

Chris: We know it's got it through the key-value store that it has it. It's kind of an example of how powerful that can be.

While you're at it, you can be like, "Well, let me manipulate the headers along the way and make sure it's got cores headers too because we could have just full control over the request. What if you had key value-stores that just had all your users' pro status in them?

Dave: Mm-hmm.

Chris: What tier are you? Any request, before it even hits your server, you can be manipulating things and having that power. It's just so cool.

Dave: I think about it a lot in the A/B testing stuff. I think JEL posted on this originally. Any A/B testing technology, like Optimized Layer, Google Optimize, or Maximizer, just to name a few that I've worked with, you have to add 300 kilobytes of blocking JavaScript or whatever they have with your A-variant and B-variant. You have to block the whole page load to load this JavaScript so it doesn't flash on the page. Then it does it. Wouldn't it be cool if you did it at the Edge and it was all tracked on the Edge?

Chris: Yeah, totally performance neutral testing, right?

Dave: Performance neutral testing, which is a big deal. I don't know if you're familiar with the observer effect in physics. Are you familiar with that?

Chris: Or in any kind of -- right?

Dave: Yeah.

Chris: The fact that Jane Goodall was observing the gorillas made it so that the gorillas' behavior changed. It was not unbiased observation.

Dave: Right. Right, and so that plays a part in A/B testing because, you know, unless you've got your big science going, and I guarantee your managers don't give you the time for that, there's a chance that your default variant ships with nothing. I think this is how maximizer works.

Your A-variant goes and fetches the A package and comes back with all the HTML, CSS, and JavaScript that needs to do the A package, and so the A test is always slower than the default test. We know from whatever Google studies; slower stuff converts worse. If conversion is your metric you're optimizing for, not like clicks or something like that, we already know it's slower. We know it's going to be worse. You've inserted yourself into the test. The tools themselves are creating bad data. That's not to say -- whatever. Measure what you can measure, I think, in general, or experiment would be more my mantra, like prototyping-prototyping. Experiment a lot.

Sorry. I'm going in tangents, but my brain is firing, so I'm going for it.

Chris: [Laughter]

Dave: I read this thing on the history of the Legend of Zelda on Gamepedia or whatever, right? They were talking. Then it bounced out to a developer article. They were talking about the Legend of Zelda: A Link to the Past, which was for the Super Nintendo. It took three years to build. Do you want to know how those three years were spent? One year was spent designing on paper and pencil, figuring out how it would work.

Chris: Mm-hmm.

Dave: One year was of experimentation. Then the last year was building it, shipping it, marketing it, and putting it out….

Chris: Oh, my god. That's the first chapter of Dave Rupert's notebook….

Dave: I know! I mean absolutely because it's 100% like, "Whoa! 33% of all product features should be experimentation? Sign me up."

Think of it in those terms. Don't think of it in two-week sprints. That's my whole jam. Don't just try to get it out.

Sometimes you do need to get it out because you make these little mountains or these golden calves, I'd say, in your brain. But you need to get these out. But you can do that in experiments and validate with users, like A/B tests or even just prototypes and sending people links and stuff like that. You can validate all that stuff in experimentation so that when you do go build it, it's like you at least know you're building something smart. Anyway, that's my book.

[Laughter]

Dave: I forgot how I got to Zelda. Okay, yeah. Back to the cloud Edge workers. You can experiment. What if we move the button over there? Okay, let's just -- we can do that with CSS probably easily enough. But I don't know. What if the button takes you to the About page instead of the Contact page or something? That's something you could do. Just do that. Test that.

Chris: Yeah. Yeah. It's starting to be just as big of a talked-about thing, the testing abilities of them as the offline stuff of service workers.

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Pastel. That's usepastel.com. Follow the link in the show notes.

It's about collecting feedback on real websites. It's like you got this website, whether it's in development or production or even if it's just a graphic of it so far, you need to get feedback on it. Pastel makes is possible to get feedback from anybody: from people on your own team, from the wider scope of the company, from stakeholders in other companies, to anybody at all. It's like you get this URL that's a wrapper of your website. It's got this bar at the bottom that's like, "Are you browsing or commenting?"

The idea is, you're looking at the actual website or mockup of it or whatever, and you can just point at stuff and be like, "See that? I've got a question about that," or, "I think that should be different," or "Talk to this person about that."

You're making comments on the real thing that the people who then need to deal with those things can do it. It's like this universe for that. It eliminates back and forth emailing. Instead of like, "Hey, take a look at this URL and then just send me back random bullet points of that and I guess I'll triage it then to the right people," it's like, no, this becomes the place where triage doesn't need to happen. The feedback comes into the place where it's altogether from these different people and all that.

It's really simple to use. It's designed for not technical people necessarily needing to do it. You might set it up. Setting it up takes like two seconds. You just sign up and be like, "Uh, put this URL in this thing and now it's ready to go." It gives you this URL that you send to people for collecting that feedback, which is tremendous.

Anybody can use the thing. You just point and click and you leave feedback. That's that, which is the way feedback should be. It's just that this facilitates it in the nicest possible way. Then it fits into your workflow too. If you need integrations with other tools and stuff, like a good, modern Web app, it's got all that stuff.

Use Pastel. Follow the link in the show notes to check it out. It's very cool. Thanks.

[Banjo music stops]

Chris: Here's another use case, though, that I think is fascinating. Let's say you're going to build a SPA and you're going to use a headless CMS to do it or some kind of -- just a website, you know, like you pick on purpose a static site generator for your site because you like that approach. You like that the pages are pre-generated, it's fast, and you can deploy it to the Edge and benefit from the Netlify approach and all that, right? Huge fan. Great way to work.

I'm also pretty hot on WordPress, still, after all these years. It's server-side rendered anyway, so that's cool. I can still make it fast. I promise.

Dave: Mm-hmm.

Chris: I just get a lot of benefit out of that and, lately, I'm just so hot on Gutenberg, which we're kind of stopping calling it Gutenberg, right? That's the development plugin. It's just the block editor now. This new editor that WordPress has I just find tremendous. It's so cool. It feels so good for me to work in that environment. I feel like it's just really nice and I'm doing this new thing now where I can use the same CSS for the content and make it load in the admin area as I do on the front page.

Dave: Oh, wow.

Chris: It almost trips your brain out a little bit because you're editing the site 100% as if it appears on the front-end of the site. It's just like editable copy.

Dave: Like it's typeset, like your site. Yeah.

Chris: Typeset like the site. All the images look like the front-end of the site. The columns look the same. Any special classes you're using look the same. All the blocks are just the same.

Dave: Yeah.

Chris: Wow! What a cool editor experience, but you're like, "I don't know. Maybe I don't want to use WordPress in the front-end. I just want to do it some other way."

In the case, this came up of CodePen. I'm not sure if we're actually going to ship this, but it looks good. I want to build landing pages, pro landing pages, pro feature landing pages. These are just -- you know what landing pages are. They've got a hero image. They've got call to action buttons. They've got columns full of features. How many landing pages have you built in your life?

Dave: Testimonials.

Chris: Hell yeah. Hell yeah. Gutenberg was born to build pages like that.

Dave: Yeah.

Chris: It's a very natural fit. I'd rather do that then have to hand-build it in an ERB in Rails or whatever, but I want to serve them on the Rails side. I want them to live over there.

Dave: Yeah.

Chris: What's kind of cool about this is that WordPress has this Rest API, right? It's like you can just hit an endpoint and it will cough up the URL that the Gutenberg editor made.

Dave: Mm-hmm.

Chris: It couldn't be simpler to grab that HTML. The thing that you can do with a worker is, okay, I'm going to intercept this request. Just this one URL, I'm going to intercept with a worker. When it does that, I want you to perform the fetch request that you were going to anyway, so spit up a Rails shell.

In our case, a Rails shell has all this stuff. It has the footer. It has the sidebar. It has the header, all in React and all just in our normal site shell. It just so happens there's an empty div sitting there with an ID on it.

Maybe in the past, you'd just do an Ajax request, hit that API, get the HTML, plot it on the page. That's a little gross, though. Nobody does that anymore.

Dave: Mm-hmm.

Chris: They don't do it because it's bad for SEO. It's bad for performance, for all the stuff we were just talking about. It's not very resilient. Yadda-yadda-yadda.

You can do that same thing with a worker. The worker can intercept that request, make the network request on your behalf, which is going to happen about ten times faster than the Ajax request would have anyway because it's happening on these Edge, super-powerful computers.

Dave: The server. The server, not client to server.

Chris: Yeah. Right. Grab that content and plunk it in that div. By the time that a request even gets to the computer, it's already sitting in there. Now I have landing pages on a Rails site generated by a WordPress Gutenberg site with this incredible editor experience.

Dave: Yeah.

Chris: How cool is that? What it makes me think of is, that's static site generation. Having this worker in the middle is like that. Let's say you wanted to hit your Contentful API at the worker level. It could do that.

It's not like you have to prebuild. Prebuilding is just one approach to a static site generator thing, but you could have a SPA-ish style site without the client-side JavaScript because the worker is the thing that gets the content and stitches everything together before the request happens.

Dave: Yeah, you're doing a server. The server is generating the page. It's almost like how PHP would go look things up in a database.

Chris: Right.

Dave: A server is doing the work and the client just gets the end product.

Chris: You can be like, "Okay. Sure. Now the server has got to make a network request anyway," but you can do smart stuff if you need to. You can cache that page in key-value store, like I was just talking. You can have the worker go get the content once, but then have a cache breaking mechanism and stuff. It's almost like, why bother? It's not like our landing pages, in our case, our so heavily trafficked that it's going to put burden on the WordPress instance. It's like, big deal.

Dave: But the tradeoff you're talking about is, you're maintaining a Rails instance. You're maintaining a WordPress instance. Then, in the middle, you have a little bit of JavaScript on the Edge worker to stitch those two outputs together.

Chris: Right. It is not light on technical debt, for sure. But what's happening feels like it could be. It feels like the technology is interesting here. It doesn't have to be a Rails app on one side. It could just be anything. It could just be a static div or it could be a static HTML page.

Dave: Yeah. It could be a React app.

Chris: Yeah.

Dave: It could be anything on that….

Chris: Yeah, and it doesn't have to be WordPress delivering that HTML either. It could be Contentful.

Dave: Yeah.

Chris: It could be any other number of--

Dave: Another HTML file.

Chris: Right.

Dave: No. See, that's cool. Yeah, I think there's a lot of potential. I've been thinking a lot about the tradeoffs and that's why I asked about it, in complexity and where we put all that stuff.

What's interesting is, I think back in the day or even now, the majority is server and client. Those are your two choices where you can put things, right? Either the server is doing the work or the client is doing the work.

We kind of have this new kind of server in Web land called the Edge, which is a server but it's next to the person, as close to the person as possible.

Chris: Yeah.

Dave: It does tiny little jobs, and so that's kind of a cool change. I'm sure there'll be a blog post in five years where it's like, "Why are Edge Workers Considered Harmful?" or something like that.

Chris: Oh, my god. It totally will be but realize how fast they really are. We're not talking about adding 200 milliseconds to a request. We're talking about adding 1 or 1.5.

Dave: Right.

Chris: It's real fast.

Dave: Yeah, and so that's kind of cool. I think the big risk, too, in a lot of bottleneck there would be if it has personal information. You probably can't do fancy stuff with the user's account page or something like that.

Chris: Yeah. Right. Right. Not always, although, you'd be amazed what these key-value store things can do.

Dave: Well, exactly, yeah, if you're kind of passing over their level. You can get kind of contextual pages.

Chris: Right, or that worker could hit an API too. You have a bunch of user data in Fauna or whatever. That worker can talk to Fauna.

Dave: Mm-hmm. Well, and not to--whatever--analyze CodePen--

Chris: Yeah.

Dave: But I've seen y'all do little ads, like one-line ads kind of at the bottom, before, or something like that.

Chris: Mm-hmm.

Dave: At least experiment on and off with that. You could also do a thing where it's like, if the header on the Edge worker has the pro account, you'd never inject that ad.

Chris: Right. Rather than having to request a client-side. Yeah. That's actually a really good idea. It's a great idea.

Dave: Even in the shell of your application, you can just turn this ad on or off based on the user level. Maybe it's even--whatever--anonymous versus logged in or something like that. You know. There is potential there. I think about with my site, I could use that.

Chris: Right.

Dave: Or get back to Web monetization, here we go. If you have a Coil account, and I know that, and I've set a cookie or something, I'll just never show you an ad div. But if you don't, well, guess what, sucker. You're getting the ads. [Laughter] You know?

Chris: Yeah, that might serve their problem. That is one of the problems of Web monetization at the moment is it's a little slow.

Dave: A bit slow.

Chris: Yeah. If you want an answer whether this user is for sure monetizing you or not, it's a half a second, something like that.

Dave: Have a second because it goes through a browser plugin that probably waits until the page loads.

Chris: Right, so if you want to be like, don't request ads until I know the answer to this question, your ad sales are going to go way down because that's too long to wait for that answer. If you want per fee ads, you've got to make that request right away.

Dave: Well, and anyone who has worked with ads knows marketing wants that to show up before anything else.

[Laughter]

Dave: It's always, can we make the ads faster?

Chris: Yeah.

Dave: You're like, ahhhh!

Chris: But that's Edge worker stuff. Now you combine service worker stuff, meaning in some cases the requests don't have to leave your computer at all because it's caching, and then you factor in Web worker stuff, which is like, oh, I need to do high computationally intense things. But I can do it network second. I could try to hit a Web worker if it exists. If it doesn't, then hit the network.

The architecture of the future on the Web is just so exotic. There's so much power you have. You do it all right and you have smoking fast sites.

Dave: No, I think there's a lot of potential, so it's very interesting.

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Hoefler&Co. Welcome. As a sponsor, I am stoked about it. They are my favorite type shop out there.

The URL is one of the best URLs you could possibly imagine, typography.com. Nothing is more critical to a good Web experience than just clear, clean, attractive typography, which is good news because it's not particularly hard on the Web anymore. Type on the Web has just gotten so good. It's affordable and easy to integrate. Hoefler&Co. fonts are the designers of some of the world's most beloved typefaces like Gotham and Knockout.

You know the CCS-Tricks logo? It's just Gotham rounded, all caps, CSS-TRICKS. [Laughter] That's it and I've used for so long, I feel like it's striking. I feel like it's just coming into its own, really. I really like it, still.

All the typography on CSS-Tricks is also Hoefler&Co. fonts: Ringside, Sentinel, Operator. Ringside is the title, Sentinel is the serif'd body copy, and I've only been using it now for--what's it been--three, four months, and I just love it. In fact, my own team, just yesterday, complimented me on the typography of the site. I've been tweaking it forever. It's finally really beautifully come into its own. It's something I take really serious. Operator mono is just my favorite monospace font for code. Really. It was one of the first ones out there that had the kind of slight cursive look for italics, which was just genius and has been copied many times since. I love it.

At typography.com, you'll find nothing but the highest quality fonts. They're screen optimized for the browser, complete families, deep character sets, clever features to help you solve design problems. Then, on the site itself, there are free tutorials and stuff to help you become a better typography. Oh, thank god. I could use it.

Download their fonts to self-host them or it's $99 a year to get a cloud typography subscription, which lets you use the entire library for $99 a year. You get 15% off that if you use coupon code SHOPTALK at checkout. Just one word, SHOPTALK at checkout. Typography.com/shoptalk gets you that deal. Incredible deal. Incredible fonts. Thank you for the sponsorship. Love it.

[Banjo music stops]

Chris: We were talking about Perf. Do you want to do that for a minute? This is a big deal for everybody because you can't escape Google. You can't escape Google search engines. You can't escape needing to appease the Google bots, in a way.

Dave: And their drone copters that are flying over your house right now.

Chris: No doubt, right - unmanned.

Dave: [Laughter]

Chris: Taking pics. Google said there are three performance metrics that we think are super important and we're calling the group of them Core Web Vitals.

Dave: Vitals. We have vitals now.

Chris: Here's what they're not. They're not how many requests does your page make.

Dave: [Laughter] Darn it!

Chris: Yeah. [Laughter]

Dave: (Indiscernible)

Chris: You have been spending so long doing that.

Dave: I was down to 13.

Chris: Yeah. They're different things, but they're interesting in that they're all what the user experiences, in a way. One of them is called CLS, cumulative layout shift. Meaning, if your page does obnoxious stuff like it loads and then the ads come in slowly and push a bunch of crap around on the page, or you Ajax in some content and it pushes things around, you're essentially penalized for that. That's a bad metric. You should not do that or, if you're going to do it, do it responsibly in such a way that it doesn't cause the shifting. Fascinating! That's a core vital.

Then the other two are basically how fast it is, but not how fast does the request come back from the server. It's like, when can I start painting this site? When is the biggest area of the site ready to be painted? That's the metric.

Dave: That's Contentful paint.

Chris: Yeah, but it's L. It's largest Contentful paint.

Dave: Oh, largest.

Chris: Meaning, not the first thing that renders but the first thing that renders that matters.

Dave: Yeah.

Dave: Which is a fascinating little distinction. Then first input delay is like, okay, you painted fast but can I actually use it? Can I actually type into something? Can I scroll? Can I use your forms? If I can't, or whatever, that needs to be factored in too. It's those three things, which just makes a lot of sense to me. It's cool to see Web Perf evolve to what matters to users rather than academic stuff like how many requests are there and how fast does it come back from the server and stuff? All stuff that matters, but that's secondary to what it feels like as a user.

Anyway, we could talk more about that. The big news was two-fold: It was, Core Web Vitals are going to be used for SEO, so we're telling you that to your face. Look at these three vitals because it's going to affect your SEO. The other lead was, we're removing the Amp constraint from the carousel.

Dave: Hey!

Chris: Which means that if you kick butt with these vitals, we'll put you in the Carousel now, which is wow. I don't know when exactly, but soon.

Dave: Well, no. Actually, it mattered to people. I think they said it was over six months. They gave people a six-month -- because they did this thing where they shifted to Google Panda or whatever. They basically changed the algorithm overnight. Surprise! Then businesses went out of business because they were basically doing shady stuff to get boosted. I think they have a new 6- or 12-month ranking thing or whatever before they implement new ranking, or something like that. Yeah, this is big news.

There is some vagueness, you know, like, "Is all the … shifting bad? If my comments come in late and that triggers a layout shift or something, was that bad? I was doing the best I could there," because it adds a sidebar or something like that. I don't know.

I think there are a few questions I have. These are relatively new things, like LCP, largest Contentful paint, and CLS, cumulative layout shift. These are little, new things and they weight pretty high on the ranking, and so I don't know. In a world of hero units and stuff like that, LCP is going to be a hard one because every website has a large Contentful paint that's slow. It's a hero unit. It's called hero units, so how are we--? That's going to downvote a lot of people and change a lot of websites. I'm curious to see how it shakes out but it's very interesting to me.

Chris: Yeah. It's also, like, it's easy to get your brain cooking on this so hard and then get so worried. Well, we don't actually know what the full algorithm is. Your full SEO ranking is not just these three vitals.

Dave: Right.

Chris: This is probably a tiny little sliver.

Dave: Five percent or something.

Chris: Yeah, I mean I'd be surprised if it was that high.

Dave: Right.

Chris: The rest of it is who knows what other magic. If you have great content on the Web, I assume this is practically irrelevant.

Dave: But if it can get you -- if just this can get you in the search carousel, having good ones of these.

Chris: Yeah. That's huge.

Dave: And you didn't have to build and maintain a whole Amp site yourself on a three-person team or something like that, that's big news. Yeah, I'm curious. I think the Amp change is very -- I know you went to meetings, so you've got to be political about it.

[Laughter]

Dave: It seems to me very damning in the sense that the Amp announcement was done by the Google Search team. Even people I had heard on the Amp core team didn't know or the Amp advisory board or whatever didn't know that this change was happening. Probably for leaking news means, but this, it's very clear to me--

Chris: Well, what is your deal? Why didn't it come from the Amp team?

Dave: Well, it's very clear to me that Amp is a search technology. You know?

Chris: Hmm. Ah.

Dave: The only reason you'd ever implement it is for search.

Chris: Hmm. We also heard from people on the Amp committee that they had no idea this was coming.

Dave: Yeah.

Chris: Like, "Oh, cool committee."

Dave: Yeah, well, good thing we have transparency or whatever. Again, let's let it shake out, and I'm glad that Amp is no longer a requirement to be in the carousel or won't be in the future because I think that's good for the Web in its longevity, but I also just am like very -- I don't know. I was very, like, see, this Amp -- for the longest time, Amp was like, "It's not about search. It's not about search." But then the news comes from search. Case closed, man.

Chris: [Laughter]

Dave: I'm fricken' Ice-T over here like--

Chris: Case closed!

[Laughter]

Dave: Take them down to the station. You know what I mean?

Chris: I didn't even think about that until now. I thought of the weird disconnect from the Amp team but not that we heard about the Amp news from the search team. But it was kind of like the Perf team too because I was at a meeting and it was pretty good. I think they got a lot of kudos from a lot of people that have been highly critical for just being this open and advanced about what's going on and stuff. It seemed like most of the people there were like -- I don't think Google has an official Perf team, but it felt like the unofficial Perf team. Maybe they do, I guess, but I don't know. Paul Irish wasn't there.

Dave: Perf squad.

Chris: Where's Paul? Come on. Are you too busy, man?

[Laughter]

Dave: I know but, again, whatever. Giving the good faith take is, I'm glad they are being more openminded about the search carousel. The bad faith take is, I called you on your bullshit.

[Laughter]

Chris: Amp was criticized a lot early on and then they put the committee together, whatever, whatever you think of that, but the idea was to have some kind of community input and perhaps even a little oversight, although I don't know that it ever manifested that way. I heard some calls for, like, this should have that too.

Dave: Mm-hmm.

Chris: Can this be open? Can this be opened up a little wider for having kind of a guiding committee or something? When I first heard that I'm like, there's no way. It just doesn't feel like the same kind of thing.

It's not a technology. It's how you measure technology. But it matters, though, because the way that those measurements are used then become part of the algorithm. But it's like the algorithm has never been open, not even a little bit, not even a tiny hint.

Dave: Mm-hmm.

Chris: That's the secretist thing. You think KFC's original recipe chicken is secret? That's way more secret.

Dave: Well, I mean, these three numbers are going to launch a thousand project managers. You know? These will change products and businesses, their whole strategy, just around these three numbers because it's all we know. It would be nice if other people were involved, but I guess whatever. Google is a private company. They can do whatever they want. Anyway, it would be nice--whatever--if they're a bit more open.

Chris: You'd be pro-openness to this?

Dave: I think so. I think it added value to the Amp community or the Amp project. I think it was like, okay, at least there are people overseeing this, what I saw, sort of a potential power grab for the Web - potentially. I think that was one of its criticisms.

I know people were very well-intentioned on the Amp project. I don't want to dismiss that. But in that Amp advisory committee, I think a lot of people posted. I forget the name of the person I'm thinking of. They were like, all the feedback is, "We only use Amp to get on the search carousel." That tells you a lot about the motivation of projects using it and I heard a lot of publishers be like--

Chris: Maybe the Amp team is stoked then. Maybe the Amp team is like, "Okay, now we're going to get people using this technology that want to be using it for some other reason."

Dave: Right. Right.

Chris: They're into the tech of it, not because they are forced over to this community against their will. I guess I'd be stoked if I was on the Amp team.

Dave: Yeah.

Chris: Like, "Now we're going to get more real, true users."

Dave: Validity. Yeah, you get more validity, for sure. For sure. Anyway, I guess, again, I have good faith takes, some bad faith takes. Whatever you all want, I've got both.

Chris: Dave, that's why you're great for radio.

Dave: Yeah.

Chris: Which Dave do you want? [Laughter]

Dave: Which Dave do you want? Do you want -- oh, yeah. No, I mean I could -- yeah. Do you want, like--I don't know--Kai Ryssdal Dave or do you want an Alex Jones Infowars Dave? I've got them both. I've got them both.

[Laughter]

Dave: They're both here.

Chris: Let's just do this last one or this first question by Whalen Walker because this gets into some Perf stuff that might be relevant and interesting here. He says, "I have a site I built from an old school static site generator." He called it make docs, MkDocs. Never heard of it. Maybe I'm too new school.

"It has a pretty decent theme. It has great built-in search," which is fascinating to me. I wonder how that works. "All I do is give it Markdown and it makes--" so a static site generator. Fine. "Lighthouse, though, is really crapping on the performance. The thing is, there is a ton of duplicate CSS, unused CSS, un-minified CSS and JS, yadda-yadda," so bad Lighthouse score. "I feel like at this point there should be some sort of CLI tool that I can do a bunch of optimizations, like bundle my stuff, minify my stuff, inline the critical stuff, optimize the images without much effort but I can't seem to find one that doesn't require me doing a bunch of manual work. At this point, I feel like I should just take -- should I just take what I get from the tool or whatever? Should I start over with a different tool that helps me with this kind of thing?"

It feels like it's kind of conflating some things, right? Isn't it kind of okay that a static site generator doesn't get into your Perf concerns? Do you want your static site generator optimizing your images for you?

Dave: Yeah, even like 11ty, which kind of, at least right now, has kind of notoriously good Perf or just ends up being kind of very performant. They kind of enforce a performance culture. Zach does.

Chris: Sure.

Dave: Zach Leatherman. Even that, a lot of the Perf, it doesn't come with the CSS processor. That's BYO. It doesn't even have an HTML minifier that I know of. Maybe there's a plugin for that. That stuff is BYO.

Even if you switch platforms, going to 11ty, which I'd super recommend, but even if you switch platforms, a lot of that stuff is BYO. You may -- I don't know. You may want to think about what you could do. You could probably do this in a Gulp task is what I was thinking, but you'd have to get your, whatever, your five Gulp plugins and just go through your folder of output from MkDocs and then--

Chris: Then you've got to make sure that plays nice, too, because then your Gulp probably is like, "First, do MkDocs. Then do other things." Do one or the other. Don't have them do it at the same time and get all confused.

Dave: Yeah, do a serial process. You could do that. My advice would be work on the CSS and JS first. CSS is kind of easy. It tends to be. There's Clean CSS is a good plugin for that on NPM. You could just run that. That could be an NPM task that you do and just generate a minified, cleaned CSS file.

Then get into the JavaScript, which there are a lot of tools there. Parcel can do it pretty quick for you. Then I don't know. Get into what? Then get into the HTML. Minifying HTML can sometimes be super bad.

Chris: That's what I would do. I think that's probably what I would actually do is all the stuff you're describing. I'm going to do this myself.

But here's another path forward. Okay. One, just throw Cloudflare in front of it. Boom. It'll minify your HTML, CSS, JavaScript right there. It's a flip of a switch.

Dave: Okay.

Chris: You do nothing on your side. You just let it do it.

Dave: Okay.

Chris: That's problem solved there.

Dave: All right.

Chris: Then the thing about having too many different files. Well, guess what. Your Core Web Vitals, it doesn't care about how many files you have. That's not a metric that matters anymore. Because you have Cloudflare in front of it, turn on HTTP 2. It's guaranteed that your site is being served with HTTP 2, which has way less penalties for serving multiple files. Who cares if your CSS is split up into three files. It's now irrelevant.

Dave: Mm-hmm.

Chris: You can stop caring about that, too. Then check your score against Lighthouse, but the new Lighthouse, the one that's in Canary now that's using Core Web Vitals and not the old stuff. Just see how you do then. Now you've done no work. You know?

Dave: Yeah.

Chris: All you did was flip on a couple of switches of Cloudflare and you got most of this stuff handled for you. Now, if the images are a problem, maybe sign up for a Cloudinary account or an Imgix account and put that URL in front of those images so that it grabs it, does the optimizations for it, and caches it too. Now you're not manually writing some optimized images Gulp task thing. You just throw your originals in there and, at the URL level, it's handling the optimization and serving them in the right format, too. Lighthouse will love you for that.

These are some no work efforts to get pretty good Perf for nothing. You know? Then your SSL is going to be super high quality, all that stuff. You know?

Dave: Hey, you're probably right. If the thing you care about is the Lighthouse score, yeah, that's great. It's a shortcut, but it's a great one, so you could do it for sure.

I'm very much on the tinker side. I'd rather do it all by hand.

Chris: Tinker. Tinker tanker.

Dave: Again, that's Dave Rupert's biggest fault. I should just be using normal crap and frameworks but I don't, so that's my fault. Sorry, everybody.

Chris: I'm just in this middle ground where I a lot of times will do both. I'll get it all situated and then I got Cloudflare in front of it anyway and flip those switches on too. But maybe I won't forever.

Dave: Yeah, I might have to do some metaphysical exploration on why I feel this way. [Laughter]

Chris: Well, Netlify does a lot of that too.

Dave: Yeah. Netlify is doing a lot of it for me and they have this thing called Git LFS. Well, you can switch over to Git LFS. They actually do image optimization for you on Netlify. Bingo-bango.

Chris: It's beautiful, dude. It's so cool. I've used it too. I was going to use it for this new site I'm working on, but then if you have multiple contributors to the site, they have to set it up too. It's not that bad, but you need some CLIs. It's not beautifully simple to set up if you want contributors.

Dave: Yeah.

Chris: Then they go to upload an image and they don't have it set up, they're not going to be able to get commit and stuff. It's going to be like, "Ew." I'm scared of it here and there. But once you have it set up, it's cool because you can be like--I don't know--serve me the 500-pixel version of it. Done.

We're doing this at CodePen, too, and we're using not just workers to cache images, but we're sending it -- if you serve an image through Cloudflare, you have all those same URL parameters.

Dave: Okay. Yeah.

Chris: Do you want to serve it with format auto, meaning it's not as fancy as Cloudinary, but it will serve it in WebP if it can, which is huge. Sometimes, WebP is 10% of a JPEG. That's crazy!

Dave: Yeah.

Chris: Without even resizing it. Then you have the resizing parameters. You have cropping parameters. You have all that stuff. We're just about to roll that out on CodePen. Whenever you upload an image, the URL that you have for it is CDN backed, finally. That's already live but to have the URL parameters too, and that's what Netlify's Git LFS does, too, is you have all these URL parameters you can pass. That's how Cloudflare works. That's how Imgix works. All of the companies do this now.

If you have an image asset, you should be able to, at the URL level, do anything you want to do the thing. Nobody does it more advanced than Cloudinary because they've been at it longer, but everybody has hopped on the train. If you have an image asset and it's hosted on us, you should be able to ask for it any which way.

Dave: Which is kind of cool because I think -- so, on my website, I was doing 100s on the Lighthouse score and then Lighthouse updated on my dev browser. Jerk! Now I'm getting dinged on image sizes. I hate generating multiple images and all that and picture sizes and all that crud. I hate that stuff.

Chris: Wow.

Dave: I love picture element. I hate this part. Not everyone who worked on it did a very good job, but I just personally am like the syntax is a lot of action. But if I could just, you know, say, "Do these sizes," and I actually never have to even do it, I just make a little shortcode that does it and it adds the question mark, w=480--

Chris: Hell yeah, man.

Dave: W=562--

Chris: Hell yeah!

Dave: And it's done for me. Good night. That's awesome. I love that.

Chris: It's meant to be automated. I feel like that should have been a message stronger earlier on in all that is that this syntax is very verbose. It's not -- it's for you to understand as a human being but it's not for you to write as a human being.

Dave: Yeah.

Chris: It is meant to be abstracted.

Dave: I still have nuanced arguments about, like--

Chris: [Laughter]

Dave: HTML should not depend on a build step or automation, but that's just me. That's just me. But anyway. But, yeah, now I'm getting dinged, man. I got a 92 on best practices. [Laughter] Oh, man, 99. I'm just one element is found on the largest Contentful paint getting me again, man. I'm telling you. All right. Well, hey. We should -- that was pretty good.

Chris: I enjoyed it.

Dave: We talked a lot about Web Perf-y. A Web Perf-y little episode, so I think that was good. Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.

If you hate your job, head over to ShopTalkShop.com/jobs and get a brand new one. People want to hire people like you, maybe like this company.

Chris: Hey, do we got any designers in the old ShopTalk Show listener universe? If so, we've got a pretty cool job opening to let you know about. They're looking for a senior product designer for mobile at Automattic. You know Automattic. They're an all-remote company, the makers of WordPress.com, and a whole bunch of other apps too. We talk about things like WooCommerce, Jetpack, and stuff around here.

Automattic has a number of mobile apps like the WordPress mobile app, which I use all the time. Sometimes I'll pop it open to look at our comment queue, for example, at CSS-Tricks for approving comments and the like. It's a really nice, full-featured app for WordPress. Pretty cool. They have the Tumblr app after they bought Tumblr, you know, simple note. WordPress VIP has an app.

They are looking for a senior designer to join their mobile team, work on these apps, and collaborate with over 60 other designers across all their various products. These are native apps for Android and iOS and there is a role for you there, so check it out. We'll put a link directly to this job posting in the show notes.

Dave: Chris, do you have anything else you'd like to say?

Chris: ShopTalkShow.com.

I was going to intercept that comment with a worker and change it on the fly but I didn't.

Dave: Hey, do it end post. Black Lives Matter. Bye.