PurePerformance - Every Byte Counts: Web Performance Flashback with Andreas Taranetz

Episode Date: November 25, 2024

Andreas Taranetz is a software engineer and lecturer at the University of Vienna. He creates a lot of educational content around Web Performance Optimization. For the past seven years, he has also operated Wahlkabine, Austria's top website, for matching one's political views with the parties that are up for election.This episode was an amazing flashback - reminding us about the time when Steve Souders - the "godfather" of Web Performance Optimization - educated web developers about optimizing CSS, JavaScript, and server-side roundtrips.Tune in and learn why Web Performance is still such an important topic, how it relates to sustainability, why you should cache on every layer, and what the Static Site Paradox really is! Links we discussed in the episode:Andreas on LinkedIn: https://www.linkedin.com/in/andreas-taranetz/Personal Website: https://andreas.taranetz.com/We Are Developers Talk: https://www.youtube.com/live/KRemC82gsBkWahlkabine: https://wahlkabine.at/Steve Souders: https://stevesouders.com/

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson and I have with me my fantastic co-host Andy Grabner. Andy Grabner, how are you doing today? Pretty good, Brian. I know what you were trying to get me to do. And I did it. People don't know because they never get to see. We and I did it people don't know

because they never get to see we should really do outtakes because if the video recorded and you could actually maybe leak you can do like you leak some information on the internet and say look this is really what happens

and then you basically get people not like me anymore because they see what i do with you all the time people people will never stop liking you too smiley and nice and you're one of two it could be yeah but it could be um you know like they do in politics yeah so you're either one or two of one or one of what 70 but yeah i see it we're both transitioning here but you you can do your transition you're much better i was trying to do some borg reference i think i don't know what the whole thing is like one of whatever but i'm one of two today one of two andreas is yeah and uh before i

introduced the other andreas and we decided to call him andreas and me andy because i think it's just easier to keep to keep us separated how what i'm really looking forward to this talk, this conversation today brings me back, I would say, 10, 12 years ago when we had conversations with people like Steve Sauters who were spearheading the whole web performance optimization

movement. Folks, if you've never heard about Steve Sauters, it's time to read up on what he did back then and some other people that built great content around web performance optimization. But today is not back then. Today is, we are in 2024. It's today, exactly. And we have new people, younger people than Steve Souders.

And sorry, Steve, if I made you older, but I think Andreas is a little younger than you, they are still figuring out how to educate people around building not only more performant, but also more sustainable applications. And with this, Andreas, welcome to Pure Performance. Don't forget to unmute and then please let us know who you are. Thanks for the intro. And of course, thanks for having me. Yeah, so I'm Andreas. I'm now three and a half years with Dynatrace. I'm building websites for way longer than that.

And the longer I do it, the more it seems to me like we still haven't figured this thing out. the more I it seems to me like we still haven't figured this thing out I didn't know the reference you made earlier but I guess we're still struggling with the same problem that this guy did what did you do? You don't know Steve Sauters? no I didn't know him web performance optimization

what's wrong with the world he's the grandfather of web performance optimization it's funny I was just, Brian? He's the grandfather of web performance optimization. It's funny. I was just going to say it. It's almost like tech is similar to hip-hop, where in hip-hop there's a lot of shunning of the old and embracing the new.

Here's a great example. What was it? Firebug was the name of it before it became the tools. What was the tool? Was it called Firebug? No name of it before it became the tools. What was the tool? Was it called Firebug? No, YSlow. YSlow, that's right. YSlow, yeah.

So it was basically, you know the inspector in all of your browsers these days? It was basically the first prototype of that as an add-on that would help you understand the performance of your page. I don't know if it was the absolute first, but it was one of the most adopted, and he was the champion of it all, so that you can see how your page is actually performing in the browser. He ended up coming up with all the rules of, or the suggestions of caching your images, minimizing your JavaScript files, all that

kind of stuff that's domain sharding. Maybe that's a good way to date myself. So for as long as I have used the dev tools in browsers, Lighthouse reports, and similar things were there already. Yeah.

But now you know who initially came up with it. Steve Sauters. We will link to some of his books and his videos. It's fantastic on what he did back then. He used to work for Yahoo. Then for Google, he built the tools,

as far as I remember, into Chrome, or helped at least on the Google side to build Lighthouse. And then he founded his own company. And we got to talk back then because at Dynatrace, we built a free tool that was called

the dynatrace hx edition which basically brought the javascript instrumentation and the waterfall diagnostics into ie6 back then because ie6 believe it or not it's a browser that you probably don't even remember it's pretty big and uh it's pretty big and pretty terrible yeah that was the ones and i know we're getting way off topic but that was the browser that everybody would have to write a separate javascript file for because it didn't process javascript exactly the same so that was a big deal back then like to check i think it's pretty good these days like as far as javascript functionality across browsers because everything's either either Chrome or Firefox or a variant. But IE6 was notorious for something's just not working in it,

and it was everywhere. Yeah, not only JavaScript. It's also like CSS was handled differently by every browser, and you had to add these mixins, so every browser got their own extension to every rule. So you may have written clean CSS, but what you shipped to the client was kind of bloated. So I like that we conform to a standard now

and need to ship less CSS even. I guess that's something nobody thinks a lot about, like minimizing CSS. But again, every byte counts. Yeah, I like that every byte counts. Hey, so Andreas, in your introduction, I also looked into your LinkedIn profile and you are also a lecturer at the university in Vienna

teaching web technologies. And I think you recently spoke at the WWC on the title was called Sleek, Swift and Sustainability. The video is online. And folks, as always, if you listen to the podcast, check out the details. We link to the profile, to the talk. You also gave us some additional links in preparation of this podcast. What I'm interested in, what actually made me reach out to you, besides obviously being a colleague of us, but

I saw your video on LinkedIn, a very short video where you basically talked about, you were kind of restarting Valkabine RT. You can explain what that is all about. And then you realized that something is not right. And then you had a very good explanation on the lessons learned around caching. But I think this would be a great starter for people that maybe, you know,

like are not as ingrained into web performance. And maybe you can just give us a little bit of lessons learned in that and then we go further. Yeah, so the talk at the VR Developers was of course also about this Wahlkabine.at project and everybody from Austria probably knows this page. It's a voting advice application. So a tool where you can answer some questions about political topics and then it results or it gives you a result of what political parties kind of share your beliefs or don't.

So you get a glimpse of what you might want to vote for. Especially this year, of course, a good tool to have. And it's quite popular. And this popularity is nice, but it's also, of course, an issue. Because for a national election, you get in Austria a million users over the course of a month. That might not sound like that much, but then again, it was hosted on a very tiny server because there was not a lot of budget behind it.

So we had to be a bit smart about the stack we used for it. So if you don't have enough resources on your server, you basically need to cache all the things you can cache. And I explained this in more detail in my talk. You can cache on the database by having materialized views. You can cache everything, the application server response, and you can cache the finished or the finally rendered

HTML responses in your reverse proxy. Of course, we know caching is one of the three hard problems in software engineering. The other ones being naming and off-by-one errors. But if you really know your application

and you know where requests look the same and result in the same things, this is, I think, where you can get the most performance out of it. And that's what we did. That's how this tiny little server could handle these big loads and not cost a lot of costs. Now, there were a few weird things like you could share your result of this voting advice application and for this we created a link that contained your result as query parameters. Now if you shared this on some social network,

their bots would come to our site and ask for this link. And then, of course, we had to do a server-side rendered HTML file with the meta tags and everything that would lead to a preview of our website that contained your result in the description. Hope that you can follow.

The thing is, if you don't make an exception for query parameters, every other query parameter also kind of busts your cache. And that's exactly what happened this year. So they created a Facebook campaign that linked to the main homepage. And Facebook is nice and adds a tracking ID if you want to track conversions and stuff. Google does the same thing. But in our case, this was not so helpful because the server thought, oh, this is a totally new request I've never seen before. And it had to re-render the page because of this query parameter containing the Facebook click ID or whatever it is called. So instead of handing out the same homepage that was pre-cached and pre-rendered,

it had to re-render the same homepage over and over again. And of course, the scale of the server couldn't handle the load. And what was really weird to me was, this is the first year that this happened, because I guess Facebook didn't, or they didn't do a Facebook campaign before. But it showed me that even after seven years, a system that always worked can suddenly fail.

And it's... Luckily, I was able to debug it quite quickly because I at least had some verbose logging on the server. So in my video, I told that on the bus ride, I SSHed into the server and read along the logs. That was all I had.

I didn't have any other kinds of metrics. Also, again, because of performance reason. And in this case, you know, when it's about your political opinions, people don't want to be tracked. You really need to be careful about privacy concerns. So all I had was some logging on the server. But if you've built your application, you know what happens.

You know what actions a client did that will cause a certain lock on your server. So I could kind of see what is going on. And I noticed these long links and how the application suddenly did way more database connections than usually. So this kind of led me to understanding, oh, the page is re-rendered way more often than it usually is. Because usually it's just re-rendered like every five minutes to refresh the cache. But this time it re-rendered for almost every request. All of those requests that came from the Facebook campaign. So, yeah, the marketing paid off, but it

also brought the site down. In the end, a simple regex in the nginx config just excluded this query parameter and everything was working fine. But it was a thing I couldn't have tested for or I just didn't consider beforehand. It's interesting because it comes from outside, right? And I don't think we've thought about this or heard too many stories about this, at least recently, Andy, where

you optimize your site and some external factor, and I don't mean like hackers or even bots, right? We all know about that stuff. But just something like this campaign ID from an external site blowing everything you had out of the water, which is just really unfortunate because you're like, we did such a great job and now, yeah. Try to cache everything, and then you unfortunately cache-bust your own stack, yeah.

Yeah, and I think, Brian, you're correct. What you said, right? We've been talking about the dependencies between system components. And typically we talk about the dependencies between components that you have under control or let's say third parties that you call but if a third party calls

you and obviously and all of a sudden changes the calling pattern I think that's something that is a very hard to test for and the question is you know are there any lessons learned from what you've experienced now to say how can we be better for the future?

Because maybe now it's Facebook next year, it is, I don't know, Blue Sky or whatever, the new social media or somebody is sharing something on TikTok and maybe they come up with some new parameters. So that means you said you're using a regex to basically cut out every parameter that you're not expecting, I would assume? Yeah, but in this case, it's super hard

because the parameters come from the input of the editor. So the parameters contain the names of the political parties. So they could be different as well. I can't change the reverse proxy config for every new election. I think the real learning is we shouldn't have done this feature in the first place, the feature of sharing your result. Actually, in the very beginning, this caused us some headaches and it showed me that you shouldn't treat your users as,

yeah, you shouldn't belittle your users and you shouldn't treat them as dumb users because the people who wanted to share the result just took a screenshot and shared the screenshot. And this caused the same natural marketing that you would want from this feature. So whoever really wants to share something knows how to share it.

You don't need to build this feature yourself. Also, it's a very maintenance-intensive feature if you want to adapt to all the changes that all the social platforms have for their preview features. So I remember we had to include certain meta tags for Twitter, for Facebook, for WhatsApp, for LinkedIn, they all have different meta tags that you might want to include to make it look perfect on every platform. I mean, I would counter argue a little bit or challenge a little bit on the usefulness of the

feature. I think for sharing political opinions and results, I agree with you. Maybe people don't want to share this publicly necessarily. But for other websites, this could be a completely valid use case. Because while taking a screenshot is easy and posting it on social media, what you want, if you want the traffic back on your website, just providing a simple link is easier than somebody having to type off the website URL. But yeah, when you told me that you introduced that sharing feature, I was actually curious, how many people do you know, do you have any idea on how, what's the percentage of users that went

through Wahlkabine and then actually clicked on the share button? I would need to extract it from the logs because as I said, I didn't have a metric on that endpoint. It's an odd share. It's like, hi, I'm Steve. I'm a fascist. No, I guess it's in the single digit percentage. Yeah.

Then again, this name is already widely known in Austria. And what was way more impactful was, and I saw that in the log. So I don't have the metrics of the server itself, but I know when a questionnaire was started. So I know when the website was used and kind of how many people started it. And I could match this up with real life events. So I saw exactly like, oh, we were mentioned in the news and you saw the spike in your histogram. Or we were mentioned on the radio show and you saw the spike. And looking at these spikes, I also learned something very important, which was if your website needs to adopt to these spiky loads, it needs to be able to scale super fast. Once you detected it in a robust way, you would need to spin up new servers,

if that's required for you to take the load, within a minute. So booting up heavy Spring boot applications that take 30 seconds to start up is not an option, which also went into our considerations for the stack of this website. In the end, we didn't need to scale it because all the caching was enough to deal with the load of Austria. And in our case, we are lucky. It's just an Austrian application, so our user base is kind of naturally limited. But not everyone is in this lucky situation.

But I mean, if you say a million people or a million requests that came in over a month, it's a good percentage of the population. And I guess obviously some people went through multiple times. I did too. I think I went through it two or three times. And by the way, it's really interesting. Just first of all, kudos and thank you so much for building that website. Because over the years, it helped me to at least get an understanding on the topics that are relevant for me.

And instead of going through all the details of every party and what they think of these topics, you just make this very easy. And then within a couple of minutes, I know which party most aligns with my thoughts. And then what I thought is interesting, and maybe you've seen this and hear this from other users as well, some of these results were very surprising. You always think that this party aligns best, and then all of a sudden the party that you thought is ranked very low.

And how many for the non-two-party, or for the two-party system people, listeners out there, how many parties does Austria have? Just so people understand why. It fluctuates a little bit depending on the kind of election. I think this time it was like seven different parties you could vote for. Some don't. Yeah, some very small where you obviously, you know, want to make sure the question is, you know, are they too small? And that is obviously some thinking that goes beyond behind when you vote for somebody.

Are they too small and don't even make it? But in general, it's really interesting to just see who aligns best with your thoughts. This year, it was even nine different parties. And to be fully fair or fully transparent, I didn't write the questions. That's, of course, the work of journalists from all kinds of news outlets in Austria who do the tedious work of sifting through the political parties' programs and then coming up with these questions and also verifying if the answers we get from the political parties

align with their actions. Yeah, because Brian, also for your reference, I think, let's just say there's like 20 questions, you go through 25 questions and you can basically say, do you agree or not agree on a scale from one to five i believe and something like that and you can also say you can ignore it you can say how important is this topic for you and i think that's that's really and in the end you know it basically doesn't match on which party is most aligned with your answers

yeah it's it's sort of like a, which Harry Potter house are you aligned to? Those quizzes. Exactly. Like a matching head. I'm slithering. Sorting it, yeah. So the math behind all of this is super simple. And I think the big improvement that came

when I and a student colleague of mine rebuilt this in 2017 was that it's, once you loaded the initial page you could go offline and still use everything you need because i mean even today internet can be spotty on the subway or yeah wherever and you don't want to interrupt the user who has gone through 20 questions already just to fall out of this quite long conversion.

That means you designed the page so that everything was client-side processing basically until the very end when you submit your results. Exactly. Even the result is calculated on the client-side. That's actually quite interesting.

When you load the page, you get the server-side rendered result, so you immediately see your browser has something to render immediately. And in the split second it takes you to process what you're seeing, it starts up up it was angular 4.5 and yeah but it starts up the rendering on the client side and then today we call it destructive rehydration i guess you replace the whole page with the client side rendered result and since it hopefully renders the same thing you don't see anything jitter around. Also because it does not load any external fonts, there is no jittering because of font changes.

All the CSS is already inlined. And what's more is the few snippets of JSON that you would usually request from the database, since we already rendered it on the server and we know what you will need, is also already inlined. And not only the one for the current election, but also the past three elections. So even if you navigate around a bit on the website, in I guess 95% of the cases, no further requests to the server would be necessary. But that's because we exactly know

what this page does and how users usually behave on it. I'm curious, from an optimization point of view, and this is a problem I face more and more, and I don't know if this is a change of subject or not to some of the other bits, but

I hate using my phone for internet when I'm outside of the house or I'm off wifi. Cause even if it says 5g and there's one or two bars, or if I have four, four bars of 4g sites are terribly, terribly slow. Right. That's obviously a problem with, well, not only our networks here, but bloated websites that are just really too big but it sounds like you're pre-loading everything into the first page which i would imagine in that kind

of scenario of lower data would you know make it take long for it to start becoming functional on the initial hit but then after that no problems right so is that a trade-off i mean am i am i capturing that right that that would be the trash i know you said you're going to see something first and then it's going to do that really crafty uh uh would you say destructive um yeah rehydration which is nice um but yeah i think that's the challenge with a lot of these things on on mobile is that sometimes you're like, I should have fine connection. And for whatever reason, it's not. And do you run into any of those issues that you know of, at least, where that decision, everything's in line, obviously your files are going to be a little bit bigger for the initial download.

Has that been causing any kind of problems at all or has it been mostly smooth in our case it's smooth but that's because we did everything we could to get that initial page load to be as small as possible like the there is only one big image that is loaded that's in the header and that's served in different resolutions so you really don't load the pixels you don't see especially on mobile so it's about a bit above a megabyte which is kind of small

and I think even on lower or slower connections on mobile there is no tracking on the website whatsoever, mostly because of idealistic reasons of the creators, because

it's about political topics. But this really helps when it comes to saving a few bytes. It was always a bit controversial because sometimes the website was looking for funding and maybe the city of Vienna wanted to fund them, but they also required us to put an

ad on the website. But this ad would have been an iframe that would have kind of doubled the initial load. So we said, well, in this case, we can't do it. Or best we can do is maybe a GIF or whatever. Then again, as I said, no external fonts minified the JavaScript as much as possible. I remember back then ahead of time compilation was an experimental feature in Angular. Today it's common practice, but this shaved off, I don't know how many bytes, but quite a lot back then. So I learned that there are so many knobs you can tune in your JavaScript framework, but also on the web server. Like Nginx has so many options when it comes to how much compute cycles will you use on the server to compress

versus how fast you need to get a response. But then if it's cached anyways and most requests are the same, maybe you can dial that up. So I see why we still haven't found the silver bullet, because it always depends. It reminds me of, we still haven't found what we're looking for. Exactly. So that means we can call Andy bono for the rest of this and andreas if you prefer andy you could be andy now um thank you

bono um and the last thing i want to mention on this and we don't have to talk about this but i love the fact that you talked about database layer caching because that's a topic that andy and i have been talking about since pretty much the early days. And in my circle, I don't hear about it anymore. I don't know if there's an easy way to tell when people are using it, but it's just one of those simple things that I don't know if people forget about or if it's just like everyone's doing it and it's standard,

but it's just great to hear that. So that's all I want to say. No question, just a comment on hooray for database caching. Yeah, I remember a session I've been in when I did an internship at a bank and there was an Oracle certified master or some fancy title or wizard, whatever. And he basically told us,

whenever you have performance issues and it's a server-side application, it's either the database doing something the database is not made to do or the application is doing something that should rather be done in the database like sorting or filtering. Yeah, I think we and Brian also to the topic of the N plus one query problem, which I think you're probably going to, right?

Requesting too much data there and not being smart with how you exit it tomorrow. Obviously, this will air a little bit later, so it will not be tomorrow, but maybe a couple of weeks back. I actually present at the software performance symposium in Linz that is happening here, and they've asked me to give a little bit of an overview of performance engineering and kind of my background in the last 20 years in the M plus one query problem, which feels like we still haven't solved because we still see it every day, is very well aligned with what you are telling us. We still

need to educate folks on the importance of basic principles in distributed architectures, caching on the different layers, reducing the number of round trips, optimizing the layer for what it's for. I think that's also important. Keep it simple in the end. Now, in your case, I know you said you have a very specific scenario with that website. There's no commercial gains that you want to have, so no ads, no stuff like this. But you know exactly what each page is supposed to do, and therefore you can optimize it for it. Exactly. Which brings me to something that you also highlighted in the preparation of this.

You sent a link over with the static site paradox. Oh, yeah. And I'm actually wondering if you could quickly fill us in on what this is all about. And I know, Brian, you also have your story about it.

So just to quote this correctly, this is based on an article of Loris Kroll. So the easy way how most people build websites, and maybe you've heard the drama about WordPress recently, is to use WordPress, which actually involves a lot of moving parts. You have a database, you have some server that needs to render HTML based on the content of the database and you need to do almost the same thing for all requests

and a lot of websites are super simple so they just expose data that maybe changes once every month or even yeah, in our case of Valkyrie B&R, it maybe changes once a year and then like three times this year and then it's static again for a long time until the next

election. So why do we build systems with so many moving parts? Well, because it's easy to install a WordPress instance. So people without the expertise go for these kind of technically complicated solutions. And this is where the paradox comes in. The people who have the expertise, they build a super simple solution like the statically generated site that has no moving parts. And somehow we need to make these static site generators so simple that it becomes kind of the default option

for all these websites that don't change that often that don't need that much complexity or where the little bits of dynamic features can happen on the client side because if there are no moving parts there is nothing that can break there is no surface for any attacks. I mean, I think maybe this is a great business opportunity

for people that are listening in. So I'm not aware, I'm not familiar with all the organizations and vendors in that space. But if there's none, that actually provides a great, easy experience and in the end comes up with static, simple websites. If there's none, then this is a great opportunity. I guess the challenge is always with WordPress. I guess it's a very generic solution, so you can do a lot of things with it.

If you obviously understand the technology and you are a web developer and you know everything that you know, Andreas, then it's easier for you to build something very specific. But if you look at the big group of people out in the world that want to build a quick website, yeah, they just go with the easy button. And the easy button is a generic solution that works easily, even though it's not optimized.

Yeah, it would have to take something like WordPress to look at that stuff and say, we can optimize this. And do they really have, how much of a vested interest do they have in setting up some sort of automated optimization routines on all these pages and then find out, well, they're wrong. And then, oh, my site had issues because it is a complicated scenario. I just even think of going back to, I don't know if any of you remember FrontPage, I think it was called. I think Microsoft might have made it. So it was a web design tool that would basically spit out HTML, right? I don't think there was CSS and JavaScript at the time. It was more for basic sites. But as you're creating, I looked under the hood once at the source code. As you're creating a page and you're

trying different fonts, or you're like, oh, let me move this to the left, let me move this to the right, what it used to do was all those experiments were added as lines of code to your page. So it'd be font one, font two, font three, font four, you know, and if you did a view source, you're like, I have a page that says hello world, right, something like that, but since I did so much experiments, I had like 80 lines of code, right? Something like that. But since I did so much experiments, like I had like 80 lines of code, right? And I feel like that's an extension

of like the WordPress type of problem. And I don't mean to pick on WordPress, but anybody who's doing this kind of stuff, right? It's just there to make this work for somebody and it's going to set up what it needs to set up. I guess, Andy, you were referencing, my story was just like, I have an old

friend Brad who started web web design probably in in 94 ish he actually dropped out of college started doing web design for small companies and was making a hundred thousand dollars a year and we were all like what what's this world computers what money but even to this day he keeps you know it's again it's for small businesses but it's it's simple websites it doesn't have all the flashiness to it these these sites don't need to do as you said all the commercial aspects of it it's their informational sites um very minimal you know database only when someone's gonna like have maybe a contact us or some sort of form or something.

But it is that idea of keeping it simple. And I think that rounds back also to this idea of mobile websites, right? Because they are still very much bloated, right? We saw when my colleague David Jones used to do the Super Bowl ad analysis. How would websites optimize their pages to handle the traffic from, say, the Super Bowl or some other large event, Olympics or whatever it might be? And you would have these large companies stripping everything off their page, the smart ones. I think there was a car company once who they were advertising one of their

cars and they got rid of all the other stuff on their page because they knew everyone was going to hit this front page. Right. And it worked like a charm. But to me, I guess being an old timer internetter, I missed the simpler pages. I missed that less obtuse because that also means speed, right? It means you're going to get on, you're going to get what you need um but that's got to be balanced with business needs such as the advertising such as you know go into a shopping site and they're going to try to suggest other products for you and i get that but it's uh here i'm just because i sound like an old man complaining now i'm wrecking my day but it's you know there is that trade-off and And tying it back to the static site paradox is you can keep it simple.

But I think in this day and age, it's easy, even if you're not using WordPress, with having any and every technology at your fingertips in a cloud vendor, right? You know, AWS, any of those, you can just grab whatever you need and not have to think about it and get it up and running. And, and this ties back, you said something about sustainability,

right? And I don't know if you were talking about energy sustainability, right? But if not, this goes back to that same idea, because how much extra compute are you now using to run something that doesn't need it? But I don't know if there's a solution for any of this.

And I'll step off my soapbox now, sorry. In our case, we also had to consider, I knew that I won't be full-time available for this website to be the maintainer. So I also chose the components I did seven years ago with respect to how easy would it be to find somebody who could maintain it aside from me. Like what languages, what frameworks can I pick that might be around in 10 years from now?

I think I made a good choice with TypeScript and Angular. And yeah, it was kind of basically the means stack. But it was the right choice for this type of application still. Just because it's low maintenance doesn't mean it's no maintenance so if you don't regularly update and unfortunately i didn't set up a thing like what's called today dependabot that would remind me every week of all the updates i could do or maybe even test them um i now ended up with a super outdated project. And at the current time, it might be easier to start from scratch. So I'm already thinking about how could I build this differently

if I might need to rebuild it. And this is again where the static sites come in. If you have just one tool that generates your site, like the Kubernetes docs are just generated with Hugo, which is a super popular static site generator, you have only this one dependency. Of course

you can overload it with plugins, but you can do this with any stack. So kind of reducing it to one dependency also makes maintenance way easier and will ensure that this website will be maintainable for years to come. So that you're talking about sustainability in terms of maintainability which that's, I don't know if you've... That's just one aspect, yeah. Yeah, yeah, yeah. That's a new one to me, Andy.

I don't know if that's something you thought of, right? Someone coming in and being able to put all the pieces together. Yeah, I mean, think about it, how fast. I know it's not always easy, but definitely the tool choice and the framework choice, especially for large organizations where you have a churn rate in engineers, you want to pick something that new engineers

that come in at a later time can easily pick up. And then keeping it fresh and keeping it updated, not that somebody then maybe, you know, maybe you're heading off and then years later, somebody comes in and say, doesn't work anymore because nobody ever has updated any of the depending libraries, that would be very tough to do. But yeah, I mean, I typically also hear, Brian, I think that's what you want to get to, sustainability, more of resource optimization, so fewer memory, fewer CPU, fewer network in terms of needing less resources. But I think this is just as equally important because it's better sustainable, better maintainable,

and therefore it consumes time and resources. And I'd have to imagine the simpler it is to maintain, the longer it'll be able to run without interference. If you don't have all those dependencies and whatever dependencies changing at their own free will as they get updated, you have less chances of something going wrong where you do actually have to step in.

Interesting. Andreas, as we are approaching almost the top of the hour here in your talk, anything else from your WeDevelopers talk that you wanted to highlight that people should definitely look into? I know the full video is obviously available on YouTube, but any other things or any other best practices that you want to make sure those listeners of us

that are building and maintaining websites are aware of? I mean, one thing I was kind of proud of that I did seven years ago and it's still not solved today is the rehydration part. And Brian, you mentioned, yes, having the big load in front can lead to slow startup or slow initial load. But I think that's the issue a lot of front-end frameworks try to solve today. By already doing some server-side rendering, but then only partially rehydrating the parts

that are most needed right now for the user to make the website feel interactive, even though it might not fully be yet. It's interesting that now seven years after I did this project, this is still a hot topic. Yes, we've become way smarter than the destructive rehydration, so now they call it donut rehydration or whatever. Every current major front-end framework

is trying to solve this in their own way. So I think that's something people should look out for and should get involved with, because it's really the thing that can give you this last few percentage points of performance improvement. So it's really, again, about calculate only what is really necessary at that point in time and then only load the least amounts of bytes that are necessary for your user interactions to work. Again, every byte counts.

Yeah. It's interesting, too, because it marries the two worlds of the older web performance suggestions, the initial ones, with the modern ones, such as rendering above the fold type of things or whatever you might call that now, or taking care of what's on the screen first

and then focusing on anything that's going to be off the screen size or just even getting that first paint going so people see something coming and feel how that's going, which I think are more of like second generation of web performance, which is probably more around when you came in, I would imagine. But it's fascinating that this little site is such a I don't want to get too dramatic and call it a beacon of hope, right?

But it's, you just see so many of these practices either only partially being practiced or some not being practiced at all. You go to some web pages and they're like, how many megabytes is this page? Or how many megabytes is this one image on this page? I see clients loading pages and they have maybe 40 JavaScript files being loaded. And you're like, what is going on?

And yet this is the little engine that could, if you're familiar what is going on and yet this is like the little engine that could if you're familiar with that story I don't know if that's this brings me back to sustainability it's like not everybody needs to do zero waste perfectly not everybody needs to be

perfect in this but everybody should try so if every website tries a little harder to reduce a few bytes, I think we would have a way better internet experience overall. Absolutely. And folks, if you want to know how

heavy or lightweight your website is, I think the easiest is for ValkaBinearty. As of today, the page obviously right now, it's after the election in Austria, so that means we have a different front page that's two megabytes

that you download. And the easiest is to go into your favorite browser of choice and just turn on the developer tools at least in my Chrome, this is F12. You can turn it on and go to the network tab, hit refresh. And then you get to see all the requests that are coming in. So job well done on that website. I guess you scrolled down all the way.

It should be less if you don't scroll. I scrolled a little bit, correct. Yeah, yeah, yeah, yeah, sorry. Speaking of above the fold, all these old practices still hold true. And basically, when we try to optimize this, it was really about looking into the lighthouse report, trying to understand all the things

that are showing up in there and fixing it. It's kind of as easy as that. But the hard part is understanding what this report is trying to tell you and then also how you can fix it for your use case. And I think another lesson learned, I want to repeat what you said is you need to understand what features actually really make sense and which ones maybe not make sense. In your case, like the whole sharing maybe was a great idea, but in the end, A, the question is what's the percentage of users that will really A, do it, and B, what's the harm that can be done or let's say that what's the complexity it brings in.

Because in the end it was complexity and it basically was counter against your sustainability efforts because it got bombarded with so many requests. I always like the idea of a website with the rule of a floppy disk. If it could fit on a three and a quarter, three and a half inch floppy disk, it's good. Which I think was 1.44 megabyte. Yeah. Yeah, we will check that. That's awesome. Yeah.

Andy, Andreas, any final thoughts? I know, as you said, we will add all the links that you provided and we discussed into the description also your LinkedIn profile so people can also follow you on social media because I know you're doing some public

speaking and I'm sure going forward on other topics as well. Any other thoughts? I'll try to upload some videos. I think it's, yeah, as I said, it always depends what's the right stack. Maybe one thing we rarely consider

is how hard is it or how expensive is it to train the editors of a website versus paying a developer to build an easy experience for them? Should you rather teach somebody LaTeX instead of

building a custom layout tool for them. Again, like maybe training them how to use Hugo is the simpler choice than building yet another content management system for them. Yeah. Yeah. What was the trade off, you know, build versus, I think typically we talk about build versus buy or in this case it's train versus build. Yeah, it's interesting.

Exactly. Yeah. But it's also an option. And then again, how often is your content really changing? these considerations should flow into your decisions and will lead you to the right places of where to cash and what to cash. Awesome. Brian, do you want to close it out today? Sure thing.

So Andreas, thank you so much for being on Andy number two. And to Bono, I want to say, I will be with you again on the next episode. That's a New Year's Day for anybody. But yeah, well, I got to start having all Bono quotes. Really appreciate this a lot, Andreas.

You did say it's going to be a fun topic today, Andy, and it is. It was definitely fun. At least I thought so, a yes you you did say it's going to be a fun topic today andy and it is it was definitely fun um at least i thought so and i know you did um hopefully our listeners did but they don't get mad at us and yell at us if they don't anyway so um but we do care anyway i'm rambling thank you everybody for listening until next time we will keep on performing. I don't know. That's a lame attempt at a tagline. Every bite counts. Every bite counts.

I like that too. That's a great tagline. All right. Thank you. Bye-bye. Bye.