PurePerformance - State of Web Performance Optimization in 2021 with Sergey Chernyshev

Episode Date: July 19, 2021

Like many frontend developers, Sergey Chernyshev was inspired in the late 2000 by Steve Souders to contribute to and grow the web performance community. Not only did he launch the Meed4SPEEDs as part of the New York Web Performance Meetup. He also worked for meetup.com helping them to improve web performance and user experience. Over the past years Sergey contributed to many projects such as WebPageTest.org, UX Capture Library, Jamstack and more.Tune in to this episode, learn what has and what hasn’t changed in the quest for better user experience. Get a quick start on Core Web Vitals and current challenges. Most important: get inspired to contribute back to this community.Llinks we discussed during the podcast are here:Sergy on LinkedIn https://www.linkedin.com/in/sergeychernyshev/Steve Souders Page: https://stevesouders.com/NY Web Performance Meetup: https://www.meetup.com/Web-Performance-NY/WebPageTest: https://www.webpagetest.org/Github UX Capture: https://github.com/ux-capture/ux-captureJamstack: https://jamstack.org/WebVitals: https://web.dev/vitals/CrUX: https://developers.google.com/web/tools/chrome-user-experience-reportEdge Compute:CloudFlare Workers: https://workers.cloudflare.com/Fastly: https://www.fastly.com/products/edge-compute/serverlessPWA Stats: https://www.pwastats.com/Next.JS approach to SSR: https://nextjs.org/docs/basic-features/pages

It's time for Pure Performance! Get your stopwatches ready, it another episode of Pure Performance. My name is Brian Wilson and as most of you who listened to the last episode might have known, through the magic of editing and producing, although this is two weeks ago, it's actually the day after yesterday's recording, and I know Andy is so, so excited because old news now, Austria won in the latest game. So Andy, I imagine you're pretty happy. How are you? I'm pretty happy, as you can see. I'm smiling. The question is, as the time of this episode airs, I wonder if I'm still happy or if we

ended up losing against Italy because that's our next match on Saturday. But yesterday we won against Ukraine, even though I think they played a pretty good game as well, even though I didn't see it. I thought you were leaving the recording and going to watch. I was leaving. I only saw a couple of minutes

because I had to take the bicycle to my friend. And I saw a couple of minutes. I saw the important ones, the last three, where the referee blew the whistle and it was a done deal. This is why I still want to advocate for all technology and resource efforts to be put into teleportation. Because if we had teleportation still, you could have gotten there instantaneously and caught more of the game. Yeah.

But, you know, as they said, it was a great performance. See, Andy, there you go. I wonder where this is going, Andy. Please continue. It was a great performance. You know, I watched a lot of this on the web using my mobile phone,

searching for the Euro 2020 or 2020, even though it's in 2021, it's the Euro, officially the Euro 2020 because it was postponed. But talking about web performance, this is a topic, Brian, that we haven't covered in a while,

even though it's been a topic that is very dear to all of our hearts because we are impacted by it all the time. Yes. And this is exactly where we are bringing in one of the names, I think, in web performance, at least that I have met over the years. Me as well. Years, yeah.

Sergey, hello. Welcome to the show. Thank you. Thank you for inviting me. It's great to be here. Yeah, performance, I don't see there is, I don't actually know if there is any other performance other than web performance. So I don't know what you were talking about earlier.

You know? It's the only one that matters. To me, there is no other way. It seems like you're living in your own little silo. But you know, there's a world beyond the browser. No, I don't think so. I have two kids who are now adults, by the way, and basically they only live in the browser.

They use a couple apps, but I think all of it is a web. It's just different technology. So that means if we agree with you now we say okay the only thing that matters is the web performance in the browser then that's all ties together though and i think you said it perfectly because you said they only live in the browser right and for anybody using any application whether it's mobile or whatever they're only using the interface they don't give a crap about what's behind it and they shouldn't have to give a crap about what's behind it. You know, and the slowness that you see in the browser that you feel in the browser can be

from browser side or it can be from the backend. But again, the user is completely, you know, they don't know any of that. So to them, it's all the browser. So Andy, I think we can happily agree with Sergey about that because front end back end, it's all performance. We're all part of one big happy family. And we're all making sure that we're delivering great performance to the end users. ANDY FRANKSEN- That's true. Hey, Sergey, for those people.

SERGEY BRINCHNIKOVSKY- Thank you for listening to this episode. ANDY FRANKSEN- Exactly. Thank you. We'll see you next time. But Sergey, for those people that may not know you, and I think if you have ever done any research on web performance then i'm sure people have crossed your name uh i remember i met you in new york when you were running and you may still run the web performance meetup or some of these uh you

know groups i met you in new york i met you at velocity uh i'm pretty sure we also met via steve sauders who you know years ago i remember he was one of the people that I looked up a lot, still looking up a lot, but he helped me a lot to push also our back then HX edition, the Dynatrace HX edition, which was a free tool for web performance optimization. So thank you so much, Sergey, for impacting in a positive way the web performance community.

But can you give a little background on what made you end up in that field and why you're still working in that field and what gets you excited? And then I want to pivot over to what's new because I haven't been following the latest and greatest. So I want to learn from you. Yeah, absolutely. I mean, originally I was a web developer, right? Even before web developer, I actually assembled PCs. But for most of my adult life, I've been a web developer and ran web development teams and built websites. First at an agency working for clients and then like at various companies.

And somehow I just got interested in performance. Back then it was probably just, you know, caring about what GZip is and like browser caching. And that's probably as much as we could do back in the day. But then, you know, more and more, as I worked primarily on what we now call front end or i should say i worked with clients who needed ui and needed visuals right like i obviously worked with all kinds of parts of the system but it's final experience that mattered um kind of performance became a thing.

Yes, meeting Steve Souders at the conference in, I think, 2002 or when he no, not 2002. It was a little later. Sorry, my bad. 2007. Yes. When he announced his work, I think his first presentation out of Yahoo with their work in there, I think his first presentation out of Yahoo with their work

in there, I was hooked basically. The moment you switch that perspective from performance being a computer thing to performance being a user thing, user experience thing, that's the moment

when you cannot go back basically and in a few years in 2009 i started the group uh because actually after talking to steve at the next conference i think i was like steve do you think it's okay to start the group and he's like well yeah i guess you know and we started uh i started the new york group and then bugged everybody around at every conference and every event to start their own and that's how community grew effectively yeah yeah i just wanted to thank you for that too because i was back in new york at that time and so i was running load testing the load performance type at WebMD. And the guy who was the lead on my team, Robert,

we were looking at how to make load testing more exciting again. And that's around the time the Satyr stuff came out. In fact, I'd say you and Steve Satyrs are responsible for me being at Dynatrace because we were looking to spice up the load testing. And we were like, we need to start incorporating front-end testing while we're doing our load testing. And we had this idea of doing this whole project of testing non-cache page load, cache page load, and started adding, like, broadening the definition of performance at the company. And we started looking for upper management support.

And then the head of the operations team liked our ideas, and she wanted to bring us in and start an SRE team. And the CTO said no, and I left. So if it wasn't for getting excited for full, getting re-excited for performance, I probably would have been stuck in the humdrum of traditional load testing. And obviously we went to some of the meetups in New York, so I just wanted to give you a big thanks for helping be an inspiration for performance.

And also, it's funny, you talk about that shift from performance being to the user. And I just mentioned earlier, SRE, it's funny to see how there's a connection between web performance. Around that time, then, the ideas of SRE started coming in, and then we have the SLO, and SLOs are focused on the availability, and SLOs aren't about what's my disk capacity. SLOs are about what's my uptime,

what's my availability, what's basically my user experience, which is an extension, again, that I think grows out of this whole web performance piece, which focuses things back on the user. So it's pretty interesting to see how far this idea has come. I mean, it makes sense, obviously, right? You're not going to argue against the end user.

But it's a great scene, that evolution. And by the way, speaking of the testing and things, I completely forgot, it's been a while, but one of the first projects I worked on was ShowSlow. It was the tool to collect synthetic measurements, I guess. Now it's all much more established. Back then it was like, well, we run a test with Y-Slow and whatever, which was the first tool that sent the metrics. I basically

thought that we need to keep track of that. Yeah, I think we wanted to leverage that tool. Yeah, perfect, perfect. And that's actually, Andy, I think how we first met as well. Like at least we collaborated first where the Ajax edition of Dynatrace was also sending data there as well. Exactly. I think we were both sending data and then we also pulled back your data.

And in the Ajax edition, we gave the user an option to compare what they just kind of recorded to kind of their benchmark. I think that was pretty cool. Unfortunately, that project is long gone because there are for many reasons and we can talk about that. But that was actually what gave me the stage at the conferences to talk about things as well. Kind of looped me into the speaker circuit. Yeah. Now I cannot stop talking about it. That's good. It's always great to talk about the good old times, I guess, right?

That kind of, like Brian said, inspired him to do something new and then also follow the passion, then also what you did. But instead of talking about the past, let's talk about the present and maybe a little bit about the future. Because I think, well, it's great to think about you know that uh uh what was the the image sharding and the caching and all these rules that we basically implemented in all our tools are i'm sure are still somehow you know important and it's good to know but i'm pretty sure that things have changed and um yeah this is why jerry can you give if i if i'm new to web performance if i want to provide kick-KS user experience, whether it's on mobile or whether it's on the regular browser, what are the new things I need to know?

So I think, as we discussed, we switch from servers to users, right? Basically from computers even to users, right? Basically from computers, even to users, right? I think that's basically what you need to realize and probably bring to the forefront of your thinking. Because the front-end technology, forget about server technology, the front-end technology has changed so dramatically. The whole concept of front-end engineer as a role

became a thing during this time. And how the technology, I mean, we all have jokes about JavaScript frameworks that, you know, you your ability to track user experience and concentrate on user experience and speed of user experience. It's dependent on technology. Yeah, sure. Some things don't change as fast, like gcp ip around sorry even that changes product all right so my point is like everything changes but general browser server for the web technology and web performance is probably a good thing to pay attention to, but otherwise you should kind of be on top of how pages or experiences even, they're no longer even pages.

They become available to the user. And I think this perspective is what changes how you work with everything. As long as that is constant, as long as you want user experience to be a primary thing, the rest will fit into place in one way or another. And I think there are quite a few things changed. As I mentioned, we measured servers first, right? And then, like, through the lens of metrics, if you look at, oftentimes I talk about metrics

simply because everybody wants to measure before they optimize, which is normal. Nothing wrong with that. You know, we measured server time, but even before server time, we measured language time, what we could measure effectively. Then we started measuring network a little bit better. Then we started measuring, oh, maybe technology. With Steve Stauder's introduction of web performance,

we started measuring the browser because we realized it doesn't matter what those servers do as much. We need to see the browser, the user's tool. And metrics, like unload time became a main metric rather than the server time or time to first byte, which is kind of server plus network. And over time, right? Or time to first byte, which is kind of server plus network. And over time, those metrics evolved as well because we started to realize we need to get closer to what is that user experience? Because we don't care what browser experiences. Browser is a computer. Who cares, right?

But if user doesn't see what we want them to see, it doesn't matter what browser fired, which event was fired, whether more metrics emerged. And like we're getting closer and closer to user experience. And one of the biggest developments of the last year, actually, very recent in all of this,

is Core Web Vitals. You probably, like if you make websites, you probably heard about it, at least from your SEO team, right? Because that's one of the biggest kind of power tools that came out of Google that say, effectively, they didn't just define the most important metrics as part of the core web vitals, but they also defined the thresholds saying, for the first time, by the way, for the first time, big initiatives

actually said how fast should the page be. No matter what they measured, in the past, we always had this industry norms and everybody was throwing numbers around, but they were, first of all, moving a little bit, and second of all, there was delay, and cumulative layout shift, which all are, by the way, very different metrics than what we started with, right? Much more user-centric. But they all have threshold now, which you can argue that it's Google's decision, right? But because they are so powerful in this industry, they kind of position it as a standard. We can argue that these became standards on the market. And this, for the first time, gave people very concrete goals to meet.

And I think this is one of the things that, if you never thought about metrics before, about performance metrics before, if you're just joining this performance field, you should definitely, for the first time, you should know about these metrics. And tooling is available. Google did an amazing job providing the tooling, like, you know, and then quite a few vendors as well. So from a tooling perspective, just a quick question, because I have to admit I haven't spent too much time in digging into the details.

A big challenge back then when I was active in web performance was that the tooling, there was no standard, right? That's why we had the different tools for each browser. So are there standards now across the major browsers?

Is this something that I, as a web developer, can leverage, or how does this work? Yeah. Well, first of all, for quite a while, there are standards around recording the performance data, right? Like performance timeline API that is... And now there is a version 2 as well that is available in, I think... Yeah, performance timeline is in all the browsers. Different versions of additional APIs are emerging as browsers start adopting them, right? And there are quite a few of those as well that are pretty standard now.

In terms of adoption between browsers, it is still a challenge. New metric comes out, it usually comes out of Google, it usually comes out as a Chrome implementation, right? So later on, other browsers support. I know Firefox been catching up pretty quickly and all. Oftentimes, there is a polyfill that you can use in your application if you want to capture it. But yes, this is still

a challenge. But the good news is that at least performance timeline, basically ability to record the data and ability to beacon it back is kind of there now, right? I think I forgot when it first emerged, but around 2009, 2010, we got this basic performance API and then timeline emerged a little later

and stuff like that. Surprisingly, there are a lot of APIs that most of the developers have no idea about. In terms of these APIs, though, I mean, with Edge, they're running Chromium. Some of the smaller but more popular niche browsers like Brave and some of the others are all Chromium. When it becomes available on Google Chrome, is it automatically available in Chromium when it becomes available on Google Chrome is automatically available in Chromium as well or do they do the Chromium versions have a control over that the bit the heart of the question is when we talk about the different browsers and what's available when they're available it almost seems like you have Firefox and then the entire Chromium family which is growing and

growing and growing so are we in a better shape now because so many of them are at least Chromium family, which is growing and growing and growing. So are we in a better shape now because so many of them are at least Chromium-based, or they just share it as soon as it comes out, or is it not like that? Yes, a lot of it comes out of Chromium, yes. But I'm not an expert in specifics there, so I cannot really say the details, but it looks like the majority of this is browser renderings, or at least things that relate to browser rendering and browser, inner browser behavior that is within the engine, yes, they come together. But a lot of these things, especially the deeper APIs that require hardware integration, like things like paint timing, for example, API, from what I understand,

required much more diligent, lower level integration. And that might be harder. And therefore, Safari probably wouldn't have it longer because they will need to implement it on their own, right? Yeah. Things like that. So it's complicated in a way that it's so complicated yeah until you until you until you uh start digging into standardization and like browser

adoption like there are so many reasons for things that from political to pure technical to bugs and things like that that from what i understand, a lot of it is very complicated. I mean, Jov Vy is probably one of the biggest authorities on the topic. He implemented quite a few of the APIs and different things in the browsers. And, you know, every time he talks about things like that, I'm like, amazing. So I'm so glad I don't need to care about it. Now, I know in the beginning,

you talked about how Steve Souders back then opened up all of our eyes because I think he had his 80-20 rule, right? He said, why are you all wasting your time on the server if I can prove to you that only 20% of performance problems where time is spent on the server, the rest happens afterwards.

Looking at 2021, where we are now, what is the 80-20 rule now? Have things changed? I know we talked a lot about still web performance is the most important thing because it's the end user, but we also talk about user experience. So my question is

is the 80-20% rule still applicable, but maybe has it shifted towards not only including how fast can we load the page, but really, as you said, how can we design the whole user flow? Because in the end, for me as a user, it may not matter how fast the page loads it's how fast can i get from a to b which means how fast for instance like yesterday i i downloaded my in europe we have the it's called the green pass right if you get your either you're tested or you're like from a covet perspective you can download that pass on

one of the websites here and And individual pages load really fast, but it's just fascinating how many clicks I have to take to get from one platform to another platform, then to click here to log in, go to another app for signing in. So overall, the individual steps are not too slow, but the whole process takes a long, long time.

So what would you consider, right? If you talk about web performance, how has the field changed? And also, what's the new 80-20 rule? So I think, first of all, I think 80-20 was very optimistic. I think it was always 95-5 or something like that. Unless your backend is pretty bad. But yes, it is 80-20 originally, yes. And that's a good rule of thumb

because people freak out, how come? And then they realize, oh, it's even worse. And I think that is staying the same, right? Like in the end, it's experience that matters. You're absolutely right. And majority of the experience is defined in the UI, right? Even if it requires API calls, even if a regional render still requires the backend processing and all of that. Majority of the experience is on the front end.

And with introduction of single-page applications, JavaScript-heavy UIs, you know, all of that, I think it's even exaggerated even more, right? Basically, more code now runs in the browser, in effect. In terms of measuring view slash page, right, versus measuring the journey, as you were saying. I think we always tried, or at least in the usability world, people always tried to do this time, how was it called? Time to action or time to perform an action.

I forgot, like journey was used, the word journey was used a lot. Unfortunately, it's very tough to measure that because a lot of non-performance aspects play into it right and generally even though it's tougher to measure right it's probably the right approach right like and that's where i think we are hitting this problem uh of measurement being everybody wants to measure to know the truth but reality is you might not be able to know the truth it's just too much data too much information to process and you should have the basic understanding of measurement and basic numbers but in the end, you should be designing the experience, right? And designing as in like graphics, visual, like movie director style of designing of experience,

right? Like usability, product, like very non-engineering, if you think about it, terms, right? Where if you design the experience, then you will understand the speed as part of that design. And I feel that is a very critical aspect of it. I don't want to say that it's established yet. I think it's a future and hopefully we're moving toward that future because technology only gets more complicated, harder to measure, harder to argue about. That is not getting better. The only way is to design the experience. And I would say there are a few things that emerged to support that.

First of all, well, first of all, ROM became a thing, right? Real user measurement, which allows us to actually know real user experience, right? So we can collect the data. But also browsers now support user timing API, which it's kind of weird because it's not clear who user is in this case. I think the intent is for developer.

Developer is the user in this case, meaning that you can actually instrument your application. You can actually fire events when your application reaches particular points in time. And that is very... I have my theories why it's not very popular, not very known, I should say, but I think it's the key to a lot of the answers where you're designing your application, you should be instrumenting your application, right? Your experience, how browsers work, what automated metrics you get,

you know, they can be good, they can be bad. But if you instrument yours, that's the numbers you can relate to, you know, and that's the numbers that drive your experience, right? If you measure how fast the most important button on your page appeared and became clickable, it means much more than unload event or even largest contentful paid automated metric from Google. In fact, I actually spent last approximately five years working on this quite a lot and even built a UX capture library when I was at Meetup,

the company I mean, I worked at Meetup. Being a Meetup organizer, it's always funny to say that. And if you can measure what you build, if you can design what you measure, basically if you create this cycle of designing the experience, implementing it, measuring that experience, then updating your design, I think that's the future of doing performance right the idea. I've had this conversation with several people, including Ben, in the past about when you're looking to measure the performance of your front end you look at page load dom dom ready first contentful paint speed index kind of like all these different things it's what matters to the organization you have to decide on something but what what it sounds like you're saying is with the the browse the timings that you can build in you're not just then stuck with the preset ones you can say hey this is the most important button on this page, or this is the most important image because maybe it's our promotion that always pops up. I want to know

that is the key to our business. Let's now, as we always tell the back-end developers, design with performance in mind. You're giving, you're suggesting that the front-end developers, besides testing and looking at things, are designing with performance in mind by adding additional timers for those key elements, whether it be for the business perspective or for their own perspective, and that they should be adding in these metrics, right? They should be coding in metrics to their page

because no matter how good and how awesome Google does, create additional APIs and stuff, the things that are important are not going to necessarily be there. I think that's very, very interesting. Exactly, because we are reaching the point where those automated metrics that come out of Google, who has to, the company, Google as a company has to care for the whole internet, right?

Yeah. It cannot be specific to your application. And unfortunately, that applies to a lot of measurement vendors as well, because they, to survive, they need to cater to as many different clients as possible, and they just cannot pre-build things that will work for one client, right? They can't usually apply it to everybody. And that's where uh not just development but also promotion of the

standards concentrates on those kind of uh more vague but standard standardizable things like lcp like core web violence right but by definition it will never reach the point where it's about your application. Because my application is different from another. Even if all e-commerce is basically the same, the implementation will be different, right? So precision of how it can be measured will be different. So there's... I struggled with it for a long time. Actually, as I was at Dynatrace, I started looking at how do we measure the future

single-page applications and things like that. And that's kind of what sparked this research of mine, like this user experience-centric, like design-centric research, that we need to stop trying to automatically measure everything and the precision that you get from intent intentionally measure what you have is much higher and yes it's not cheap it's not free right you cannot just turn on the tool right you have to but after that your precision plus actually your relationship uh with that metric changes right it stops being somebody else's metric that somebody else's

imposes on you and it becomes your metric right like i i was actually very surprised working with designers and product teams uh first at bed Bath & Beyond and then at Meetup, that they actually accepted it so much better when it was, oh, what is the primary content on this page? Oh, it's this, let's say for Meetup, it was event image and event description. When those show up, we fire a mark and know when those show up, right? And to them, that was much better than any of those three-letter abbreviation soup that we usually throw at them with performance match picks.

And much better. For me, this sounds, listening to it, like the same problem we have been trying to solve on the backend side as well, which means we are all working for companies that have over the years tried to auto-instrument all the different backend runtimes. But now over the last one or two, three years, some standards emerged, especially around open telemetry, giving library vendors the ability to instrument their libraries in a much better way than any generic instrumentation can do, plus encouraging developers to then also use OpenTelemetry to instrument their codes to, in the end, get a nice end-to-end trace and the right metrics.

So it sounds for me like you're advocating for the same thing on the front end, right? To do specific instrumentation for your app because you know your app best and whichever library you use, the library developer also knows the library best and therefore can build much better instrumentation in there. So now my question to you is, is there any standard emerging like open telemetry or might even be open telemetry something that should be extended to the front end as well? First of all, I'm not very familiar with details of open telemetry. I understand the basics, but I do not understand enough about the rest of it.

Unfortunately, the difference here is that the standard should be around the product and not technology, right? Around the product features, right? And obviously, those are always different, right? Like, depending, every product is different, right? So we might not be able to standardize, like, in the same way. User timing standard, user timing API standard is kind of the best we got. The guy just says, well, whatever you want to instrument, you can instrument. And because it is part of the timeline, performance timeline,

all of those metrics are reported in performance timeline. All the beacon technology can pick it up. So all of that is taken care of for you the moment you use user timing API. Or at least you can, in a standard way, consume it, right? Not all vendors consume it, right? But it's another story. You know, vendors can use a standard, basically, rather than

trying to do their own beacon, for example. I feel that unfortunately, because this starts to spawn more fields, right, from starts to spawn more fields, right, from engineering to design to product,

it will be even harder to create a standard, right? I don't see a new standard emerging, but I am pushing for this, like with this work of mine. I don't know if you're familiar. You probably didn't pay attention to this UX capture work that they did. But it's basically trying to standardize on like four, I call them UX metrics. And I didn't mean to dive into that too far. But since we're talking about it, four core metrics that kind of represent core experience of the page. Like when did the user appear on the page? Are they confident they are on the right page?

When the primary content show up, when the primary action showed up, those kind of things, right? And I did it on purpose not to be specific to e-commerce actions or to business or to media actions. So each page, each experience can actually say, well, primary content on this page is blah, blah, blah, right? On this page, it's that other thing, right? And they can track it together. But so I hope it can be standardized around those. But first of all, like, I don't think I'm an authority to really

define that for everybody. And it's just way too early to say that it's emerged yet. But you can be the one. You can be the next Steve Souders that inspires exactly the next generation. And Red will definitely. I mean, you shared the links with us already to your UX Capture GitHub page. But if people are seeing github.com slash UX dash capture, that's where you can find the project of yours.

Yeah, because it sounds like user timing is the equivalent right now, at least Andy, of what OpenTEL provides, where if someone like you, Sergey, or you and maybe other people say, hey, I have ideas, and people come up with a standard of

these are conceptually the things that front-end developers should time and measure. Maybe these are the four main points, as you're saying, and once those get sort of standardized, then everyone can start implementing those. Not from a code point of view, but conceptually, right, because, all these other JavaScript frameworks can start adding in the timing measurements around the things they know are most important within their code. Because if you think of any browser timing tools, we're looking at certain things that we can do. We're trying to do standards, something that will fit all models. But they know very specific things within their engine that are going to be critical, and they can just ship them with the standards.

So it almost sounds like there needs to be a bit of a movement around getting the framework vendors to start identifying and pre-instrumenting the key pieces, and then maybe, hopefully, Sergey, your ideas will start sparking adoption of conceptually what do we what should we add to our own pages that that's going to bring things a lot further than they are now and that i think that's almost like that generation two of the web performance handbook you know this is like the the next step up because the funny thing is

we still see all the time the original web performance recommendations still are not being followed yes so those will never go away but now it's like how do we up that game right and i think you're on to something there yeah there is one challenge there though uh unfortunately frameworks on by definition not specific enough to the product. So Angular will not provide you e-commerce experience. Angular provides you building blocks to build your e-commerce experience. And the specifics of the product are not in frameworks. They are in application code that developers build on top of the framework. So framework should provide the basics of instrumentation.

Right. I feel. But I don't think they can provide this user centric product points unfortunately. And that's I've been thinking of how do you simplify instrumentation for engineers for five years and I couldn't figure out any way for engineers for, well, five years? And I couldn't figure out any way other than saying, well, let's give them tools, but they still need to build it into a product. I want to point out one important part about all of this.

You guys are doing a lot of instrumentation obviously a lot of work with metrics and um you probably seen this problem right the numbers don't change the product right it's only the interest of developers that and product people that changes the product right giving them the numbers selling them the tool giving them terabytes of charts and statistics doesn't change the product until product engineers actually start caring about improving. And one does not necessarily mean another. It's a prerequisite to know what's going on but doesn't mean it so uh a lot of times people like say well but we need to instrument our product it's a lot of work i'm like yes but caring is a lot of work too right like to to improve performance is a lot of work too and without trying to you will not do that so if you didn't instrument it well you probably didn't care anyway so like

you wouldn't do anything right so there is this alignment of intent that is critical here whatever you use this approach and not use this approach it actually doesn't matter but you need to try improve it before you improve it right like if you don't no metric will help yeah there's that cultural piece of are you going to do anything with these numbers? If you get all the stuff in there, what are you going to do with it? And are you prepared for the consequences? It was a while back, I was helping out a colleague and there was a customer who they wanted to know why their mobile browser experience was so slow. And they said, and don't tell me because there's too much stuff on the page.

And so I just opened up my Chrome tools or whatever, set it to mobile, and I opened the page. And right away, there's, I think, about a four megabyte image coming down. And I'm like, it's because you have too much on your page. You're like, that's not what we want to hear. I'm like, that's what it is. You have to be prepared for this. You know what I mean? Like you can try to find things after,

but you have to take care of this first. You're doing the full page on mobile. And I even pulled up, you know, the difference between our mobile and our regular, which was a slight improvement. I went and then I pulled up the Amazon mobile versus desktop and said, I know you're not amazon.com and you might not have that horsepower behind you to make these kinds of changes, but the difference on their mobile versus desktop page is tremendous.

And that's where you get the performance from. So start there and then you could look for these non-image size things. But it's that idea that our people prepared to make the changes and to commit. And, and, and I think a lot of what it's, I think it's going to be really great when, when you can get back out there and others can get back out there and advocate for this, because that's where that interest comes from. You know, that's where you get people to start caring about performances by getting out there and talking about it. And you and many others have been doing such a great job with that over time. But unfortunately, a lot of people still need to feel the pain of it first. But a lot of them will listen and try to make changes.

So that's great, too. Cultural aspect basically matters most. If you don't care about your users, your website will not be fast, right? So maybe you, in that case, maybe you don't need a faster website. It's okay if your company dies, right? Like the company that will supersede you will be the one that cared.

I think it was also interesting comment in our last episode where he was talking about, he actually made the claim, or he said his argument was, you know, shift left load testing is a lie. The only thing that matters is production load testing and everything is centered around an SLO. And he said in the companies he worked for or with, they were typically drowning in alerts. And those alerts were typically coming from users complaining because he was working for a big publishing house back then. And then he said they didn't have any SLOs to actually say, what is our baseline? What do we measure ourselves against?

And they started defining SLOs. And then he said, hey, sometimes we have events where we expect much more traffic so how can we validate this and then they started load testing in production meaning on top of the existing load just adding 25 50 50 percent more and to see if they're still within the SLOs and and that based on what he said changed the mindset of many development teams other development names because they hey, I want to know how is my service doing under extreme load. And then before they were then onboarded for this type of test, they first had to define their SLOs. And that kind of really changed the culture around how important it is to think about what is it actually that we want to achieve so we can measure against ourselves against it and then kind of get better and one of our colleagues henrik he just published a great blog post that was initially initially inspired by a colleague from from france

and he gave the analogy of an athlete with the with the slos i'm not sure brian if you read that blog post but i thought it was pretty fascinating because he said an SLO is like an athlete because as an athlete you constantly try to get better right your end goal is maybe the Olympics and so an SLO gives you a baseline where you are right now but then you constantly want to improve and it's like and you and you always want to stay there or you want to always be as good as you are but you always want to get better and this was also something interesting and I think something that we want to stay there, or you want to always be as good as you are, but you always want to get better. And this was also something interesting, and I think something that we want to kind of advocate for engineers, that you can always get better.

You always want to train, but you need to have something to measure yourself against. And then hopefully you'll see the benefit of better performance because it will make your users happy, business strives. But on the other side, performance often also means more efficient, which means less costs. And then you can be proud of great software you build with great user experience and also great resource efficiency. Yeah.

I feel that in the beginning, we were trying to see, oh, maybe we should have a stick or a carrot that forces people to do this. And somewhat the core of Vitals is that stick, right? Like the search, Google's SEO play on it, right? But in the end, it cannot be external motivation alone, right? Like it cannot be external, like performance people cannot be cops or janitors, right? Like they cannot be like either pushing you or cleaning up for you. It's your work to do it right. And if you don't do it right, if you don't care about user experience of the product that you're building, nobody can help you. Yeah. Again, the culture piece of it ties to,

I find my job most exciting when I'm doing interesting things, when I'm trying to improve upon things that I'm doing, and when I'm working with other people who are right there with me with that same enthusiasm. Because suddenly you're working on something fun, there's a lot of energy going on and people get excited about what you're doing. And I think no matter how much we love our jobs and our careers, we could probably think of a million other things we could be doing with our time if money was not an issue. So as I'm going to be at work, I want to make it the most fulfilling and rewarding as possible, which is even, again, going back to like 2010 when we were trying to add that front end optimization into our load testing. That was making me actually really engage in performance again, because I was starting to lose interest in it. And to your point, though, I hate to do the two types of people in the world

camp. But in this case, there are the people who get excited and are happy when their job is better, because you can say, hey, your job's going to be so much more fun if you care about these things, because that's going to be infectious and other people are going to and you're going to start talking about a lot of ideas and a lot of goals and you know hey we're all going to make it to the olympics right and then you have other people where you might say that too and they're like i don't care i'm just here to get my check right and they're to your point so again there's nothing you can do for those people um but for the others we can you know at least try to put all the stuff out there give them inspiration as you're doing putting out all that things and giving them at least

something start look at looking at and some guidelines and some guidance on how to maybe get there help others get there and then when we all benefit then because then suddenly we all have better performing websites that we use and then everyone's happy and it just keeps on looping then. But this organization, you could even for those people who come for the paycheck, you can drive that direction as well.

It does make it harder. It does make it harder when you need to do it top- right but that top down support is always required as well yeah and by the way we were talking about the future of performance right and i really hope that the future when people start caring right uh and i don't think uh there is any other way uh at least on the side, we see there's a lot of people caring. I'm not as in touch with the front end side,

but we know performance has come a long way in the last 10 years to this add on, on the end. And I think it's just extending further and further into the front end. Cause I see even, even on our engagements, anytime we ask people, are you interested in real user monitoring? They're like, Oh yes, absolutely. That's the most important thing. So I think it's getting more and more spotlight that's a good point uh i i was actually probably in the last few years i've actually seen that change myself yes probably two three years no more but we had to push very hard over years to saturate the market enough that it becomes a more established idea.

It was such an uphill battle before that, and still is, but at least that hill has some kind of slope going down a little bit. Hey, Sergey, I know we've been talking already, I think like 40, 45 minutes. And we could go on forever. You gave us a great list of links in preparation for this. So we want to make sure that we are passing on a lot of those. Is there anything before we close that you want to make sure we need to cover because people need to know about it? I see things here like web page test,

I see Jamstack, I see Edge Compute. Is there anything you want to particularly highlight that we haven't talked about? Yeah, there are probably two topics, especially for people who do build front-end, right? That one of the topics is be careful with your JavaScript. I know a lot of JavaScript engineers will disagree with me.

They feel it's magic and there's nothing better than just using JavaScript everywhere. But I feel it's eating performance again. We have a new problem. It's not that new, but it became very problematic. So careful with your JavaScript. Effectively, you still need to measure the same things. It's still user experience you need to measure, but the solutions to that are now in the world of tooling of JavaScript,

build systems, and choosing JavaScript when it's necessary. I mean, we've seen a lot of stuff rewritten in JavaScript. CSS is rewritten in JavaScript. HTML is rewritten in JavaScript. A lot of standard out- the box single page applications today only render when javascript kicks in and that's that that bleeds my heart basically the browsers are so good at doing it without javascript why are we doing that so without going too far into this topic that's basically my message just be be careful with JavaScript. Realize what you're

doing in JavaScript. When browsers actually have your stuff available to the user, developer bias as we've seen a long time ago because of networking and other things now is even higher. Your JavaScript is cached on your computer. Your computer is probably 10 times more powerful than your user's computer and all of that. That's one of the critical things that I feel every engineer needs to understand. And another one is actually Jamstack. I did add it to the list. And basically, think of lifecycle of your data.

We got so used to three-tier architectures or whatever our tier count is these days, but with services and stuff, right? But we're so used to always go to the origin of data on every request. Everything must be computed in real time that we forgot that that's not true, right? A lot of stuff doesn't change.

We should follow the data lifecycle rather than just rely on every time computing everything, right? And Gemstack is more than that. And even to this day, it's a little early, I would say, but it's pretty advanced by now. So it's not just small websites of personal blogs that can be started and generated but i think the industry is going towards the right balance of pre-generation or or generation as data emerges and real time maybe edge compute uh and kind of cloud functions

to augment the main content right so those are the two things that i felt are big changers one is positive another one is negative that i think are emerging technologies i would say yeah we actually had an episode i'm not sure if you remember brian on champ stack uh with cassidy willidy Williams more than a year ago. Yeah. A while ago. Netlify is a big player in the market now. It's

definitely an important topic. Once the world goes back to better normal, not the old normal, not the new normal, the better normal, will, especially in your local community in New York, any plans on resuming the meetups? Or have they already resumed? I don't even know what the situation is right now.

Yeah, we're doing online ones, right? We've been doing online talks. But interestingly enough, talks are not as interesting as meetups. And maybe, you know, when it's no longer local, it stops being as important. But we do have hands-on sessions

called Meet for Speed, which we run every two weeks, actually, now. A little tiresome, but... But we have people from all over the globe from India to New Zealand to everywhere in the US as well in Europe to in time time for Europe is a little harder because we do it in our New York even you know and yes I hope we

will restart session yes it's it's tough obviously a pandemic health pandemic is problematic you know we don't want to endanger anyone and culture will change so we'll see how it goes but i feel it's about community whatever it's uh in person or not in person first is community and the community became easier remote as well people got trained to be remote and digital a little bit better with all the downsides yes but there is a little bit of that going on so we'll see i think we might even keep both in person and virtual events as well we'll see. I think we might even keep both in-person and virtual events as well. We'll see. Awesome.

Well, I do hope we have a chance soon to see each other again and have a proper moment to thank you with a beer or so, something like that. Yeah, absolutely. All right, Brian, let's close this one okay well thank you everyone for listening and thank you sergey for being our guest today we certainly love learning about all this stuff and really appreciate everything you and others in the web uh performance area we've been doing all these years and hopefully more people are paying attention i think that's actually happening so it

does pay off it It trickles in. But it slowly creates that snowball effect where it's going to take off. Now all we have to do is compete with security, which is going through the same struggle we started 15 years ago, right? Because now everyone's trying to get security to pay attention. So as performance people, we still have to up our game so that we get the spotlight so cares about security anyway thanks to our listeners and if anyone has any questions or comments you can reach us at pure underscore dt on twitter or email us at pureperformance at dynatrace.com thanks a lot everybody bye-bye thank you bye bye