Howard Beader

00:32 - 01:28

Alright. Let's, kick this thing off.

Welcome, everyone. We are gonna have a great webinar for you all today.

We're gonna be talking about web optimization, for 2025, and the tools and methods, that will help you boost performance. We have a great crew of, folks.

There we go. We have great crew of folks here, to, walk us through some phenomenal content and demos.

I'll introduce myself first. My name is Howard Beader.

I lead product marketing here at Catchpoint, and I'm joined from, some web performance legends. So, Mikayla, would you like to introduce yourself?

Mikayla Reddy

01:28 - 01:46

Hi. Yeah.

Nice to, have everybody here. Saw some familiar faces in the audience too, so thanks for hopping on.

My name is Mikayla. I'm the solutions lead for WebPageTest.

So work very closely with WebPageTest users and customers, and, we're excited to, share a little bit of information with you today.

Howard Beader

01:46 - 01:48

And, Claudio?

Claudio Biselli

01:48 - 01:57

Hey. Thank you, Howard.

So I'm Claudio Biselli. I'm a software engineer at Catchpoint.

I'm mainly working on the WebPageTest tool.

Howard Beader

01:57 - 05:30

Alright. Thank you both.

So let's get into what we're gonna be talking about. So we just did some, intros.

I'm gonna do a couple of more to set things up. Then we are gonna get into the product live.

We're gonna drill into some real use cases. You're gonna see some live demos, of the latest and greatest, of web page testing and catch point Internet performance monitoring.

We'll give you some tools and tips for success and, of course, throughout all of this. We're happy to take any questions and provide what answers, we can.

And if we don't get to every question during the webinar, we'll get back to you afterwards, and follow-up. We definitely want to have this, be a very engaging webcast, have it be, you know, two way conversation with you all, so feel free to actually jump in and ask questions.

So you know many of you may be familiar or some of you may not be familiar with the fact that Webpagetest was acquired by Catchpoint a little over three years ago. And CatchPoints in a very similar space, we do Internet performance monitoring.

Essentially, we are monitoring the front end digital delivery chain from where that user is all the way back, into the application, including, of course, the web experience. We were thrilled this year in October.

Gartner came out with their first ever digital experience monitoring magic quadrant. Catch point, as you can see, we're in the top right named one of the leaders in this magic quadrant.

And we talk about ourselves not just as digital experience monitoring, but Internet performance monitoring. Gartner also did recognize the Internet performance monitoring or IPM term as well and actually noted, Catchpoint as the highest rated, in what they consider that category.

Catchpoint is unique because we have this global agent network with over 3,000 intelligent agents located all around the world and all different parts of the Internet, ISPs, backbone, all the way down into the last mile to let you monitor from where it matters for you all. And we typically work with the largest, digital players, on the planet.

When folks really rely on their digital experience for their business, typically, they're working with Catchpoint. And you can see some of the stats there.

Now we're all here because we know web performance matters. Right? And if you look at some of these stats, it's amazing what the expectation is today.

40% of users will abandon a site that takes over three seconds to load. 47% of consumers expect a web page to load in two seconds or less.

I mean, did you.

Claudio Biselli

05:30 - 05:33

hear that? Two seconds or less.

Howard Beader

05:33 - 06:36

I mean, that's incredibly fast. And that's why web performance optimization is hugely important.

It's you know the front door for many of you to your businesses. You know when we start to take a look at even more of the stats, you know the option of optimizing your website you know is passed.

It's no longer an option. It's something that everybody needs to do and everybody needs to do to ensure that the experiences they want to deliver are being delivered and that you're able to actually drive the growth in your business through your web experiences that the organization expects.

So with that, let's get in. Let's take a look at some product.

So over to you, Claudio.

Claudio Biselli

06:36 - 06:51

Thank you. Thank you, Howard.

So let me share my screen. Alright.

Okay. Hope it's visible.

You can see something. Can you confirm?

Mikayla Reddy

06:51 - 06:52

Yep. Looks good.

Howard Beader

06:52 - 06:53

Yep. We.

Claudio Biselli

06:53 - 08:28

can see I mean, start starting from what you just say, so in this scenario is essential to know that, there are tools useful to analyze and improve a website experience. So for today webinar, we will take a look at look at a couple of websites and so how to set them up, how to read their results.

So we will go together through their test results, trying to identify eventual performance issues, how to, read waterfall. So in general, we will try to read results and improve the performance of our websites.

The tests are going to be executed using WebPageTest, which is baked into the Catchpoint portal and so Howard already mentioned it but for who doesn't do WebPageTest is a pretty popular tool, useful to analyze and improve a website performance, provides, great and pretty I mean, well, you can see from this form there are a lot of settings that you can customize and play with to set up your test configuration so you can, for example, configure network connection to simulate slow connection like two g, three g, and so on. So this may be.

Mikayla Reddy

08:28 - 08:35

Looking at those settings when you're looking at those settings, how are you picking which ones to do? Yeah. There seems to be a.

Claudio Biselli

08:35 - 13:11

lot of options. Yeah.

Yeah. That's a that's a good point.

So, for example, here in this test, this is so this is a test over, demo application. So this is currently running.

The test has been executed from a location in Milan. The connection is this is simulating a slow four g connection.

We can see the browser dimension, the number of runs, the repeat view. So this means that this test is going goes to show and run a cached view, and we are also going to, we've executed within this test also a Lighthouse test.

To answer your, question, let me change it quickly to this may be interesting. So for example, we have a custom dashboard for that.

So as you can see so this is a custom dashboard in the portal, using, so we have a RAM setup for, this specific website and this, in general, those pages. So RAM involves collecting performance data directly from actual users while they interact, with the websites under real user conditions, while web page test, provides detailed synthetic performance details simulating, as I said before, specific condition.

So by using RAM, we can see here we are now access to a lot of informations, related to, as you can see from the map, so the location, connection type, you can see here, breakdown by page, and what I've used specifically for the test we are going to see is this table where we have a breakdown by device, setting, connection type, So what I saw before running my test is that there were, low LCP, for specific conditions. So I've used those information to set up my test.

So, for instance, if RAM tells you that, under specific connection, we have low performance for specific metric, then we can optimize our search and, our test to focus on what matters. So, that's a good tool to, that I've used I've used for the specific test we are going to show, cause, helping me a lot in order to investigate, for specific location why something were odd.

So if this answer the question, So jumping back to the test result, another setting I want to mention is here. So I'm not going through all of them, just this one.

So I've enabled the response bodies for my test result. This is going to be just useful for what we're going to see.

Everything else is 34 settings, so I'm not going to deep on those to not want to waste time there. So this is the test result for this specific test.

What we can see immediately here, is that, I mean so here we can see the user sentiment. So overall, wherein in the sentiment seems the layout layout stability is not bad.

There are some accessibility issue. The site is pretty quick to to connect, but, we have a pretty high l s p SAP, and we can see it here.

So in general, I mean, just a quick overview on SAP is one of the Core Web Vitals metrics which tells you how quickly, the main content of the of a page renders. So we can see it was if we scroll a bit down, so here we have a screenshot for the test performed.

So and, specifically, we are looking at the run number two over drift because we have executed three runs, which is the media run by speed index. So as you can see here, the page starts with, blank screen, and at some point, something starts painting on the browser.

So the browser has concept to paint milestones, which are used to, analyze, the performance. So in this case, we have a first paint, which usually is, empty content, empty.

Howard Beader

13:11 - 13:12

boxes.

Claudio Biselli

13:12 - 22:47

Then we have here two seconds the first content full paint, which includes sample text, then what we can see is that the page seems stuck up to three point four seconds where we start rendering a background, a placeholder for, in this case this is a movie application, so we're loading placeholder for the movie, image and then around four point five seconds we can see that the main content is actually rendering on the page and is where the tool highlight the high LCP. Another thing we can see just looking at the screenshot is that the hopefully it's visible, from your end, but trying to highlight it a bit, so here we see that the buttons are moving around, so probably this is going to impact, of course, the cumulative layer shift metric, but also is going to impact our user experience because we do not want them to misclick, for example, on one of those button, got redirected to another page, and then need to go back to see what they actually wanted to see.

And then what we can see still from the screenshot is that at some point, the main image renders and the page then is mostly complete. Of course, the repeat view, since the images as cached are performing better because, we do not need to wait for them to to load.

Below, another thing we can see is the Lighthouse score. So because I I've executed also Lighthouse as part of my test, to have another metric to compare what I'm looking at, which is another good idea.

So comparing multiple point of views. So also, like, DAOs keys, you, if we go I'm not going into details to, not spend too much time here, but for example, if we go to the performance or accessibility, Lighthouse provide a very good audit on what we can do, to try to improve, the performance, accessibility, or other metrics for our website.

Below we can see, performance for individual runs. In our case, we have three runs, so six, if we can't also repeat here.

This tells how something about the trend, between different runs for our website. It's easier to see from here.

So for example, if I this this page allows me to compare screenshot from different runs and different views. This case, if I want to compare all the, for example, three first view, what I can see is that the trend for this page is pretty stable.

Only the first one, we can see a shift in the time to first part, which is impacting all the other metrics. This is another good way to take a look at the website with between different runs because we don't want to focus on, for some reason a very good run or a very bad run.

So we want to understand also the, the trend for the metrics of our website. Now let's dig a bit too deep on what we saw on the summary.

So we saw that the LCP is high, because it is above four seconds, which is DSCP, of our page. So in if we go to the waterfall table, we can see, for it's the same value we were looking at in the summary.

So clicking on DSCP, we see now that DSCP has been evaluated as this prompt. We have more details about this content here, so it's considered as this h five tag with this content.

So we know, now which is the content causing the SCP. Another thing we want to mention is we, saw on the screenshot some layout shift.

So let's take a look at the layout shift tab, and here what we can see, hopefully, it's very visible on your end and it's not too much luck is that this is the event which caused the LCP. So we have one here, another one here.

So we don't know if you can see, but the text is scratching, so probably we are loading a web font here, and another one, we have other here related to the search bar, which is changing and is getting bigger. So let's take a look at the waterfall for this website.

So the first thing we saw here without looking, details or request is that we are three blocking requests. So if we want we saw the SCP's eye.

We want to improve SCP. That's one thing.

We saw it's bad. Let's try to improve.

What what we can do to improve SCP? So, of course, reducing the server response time is one option. Now in this case, the servers is not that bad.

So another thing we can do to improve SCP is we're getting rid of those blocking requests. And another thing, we can see it now.

So let's dig on to this HTML response. So if we go into the response now that I have enabled, the response body, so I I can access, the response body directly from here.

What I can see here is that the HTML is this is a React application. I know because this is just containing a root diff, which is then be used as soon as React goes to, fill, the HTML and load our application.

Then what I can see here is that in the head, I've loaded a couple of scripts and a CSS, and is what we can see also on the waterfall. So here we can see the first JavaScript, second one, CSS, and then there is another, request blocking, which is a web font.

So another thing we can do, I was saying, is maybe since this is a React application and we want to improve SCP, we can switch between servers as front end side rendering to server side rendering, but this is something that we need to do on our build process. So let's take a look at what we can do here.

So let's try to get rid of those, understand what are those, but get rid of those, login requests. And another thing we saw is this web font.

So this web font, if we take a look at this CSS, is included here. So maybe checking with our team when we want to try what's the experience without this web font.

I mean, is this really meaningful? Do we care about that? So what we can do here without entering into the React scope of our application? So if we take a look at the opportunity stop, we know that, okay, in the quick section, there is one JavaScript file which is blocking the page rendering, and we saw it from the waterfall. So we know that this JavaScript file is important, it's one of our main JavaScript files.

So one thing we can try to do is we want to embed the content of this file into our initial HTML to reduce the time required by the browser to fetch the request, parse it, etcetera. Same thing for the CSS.

So we want to align and try I mean, we we're playing with it. So let's try what's the experience in aligning our CSS.

Of course, LCP, the tools knows that this is like a JavaScript generated context, so gave us information about the LCP, but then to to apply no code changes, we need this to be changed, applying server side to rendering. Another thing we saw from the water was the web font.

So we want to get rid of the web font without touching our code. One thing we can do is play a bit more with experiments.

So so here we have tons of different experiments, so you can add HTML to your head, to your body, you can replace text, etcetera, but one thing we really care about here is this, block request experiment. So one thing we can do is put here the full URL of this web font, enable this experiment, and run.

So below, I see a recap. Of course, I need to, the URL here, but, we're going to jump directly on the result, which is has been already executed because we don't want to wait for 12 runs to to complete cause, what does the experiment is going to run two different tests because we want to compare apples with apples, so we want to compare the new result without the experiments applied with the one with the experiments applied.

So this is going to run two different tests, and we're going to keep the repeat view and trigger on for each one.

Howard Beader

22:47 - 22:57

So so, Claudio, just just to confirm, running that experiment isn't changing the code on the seg. Right? Or is it?

Claudio Biselli

22:57 - 23:05

We are applying changes, but not, of course, directly on your website. We are applying changes, on a proxy server.

Howard Beader

23:05 - 23:06

Proxy server.

Claudio Biselli

23:06 - 23:16

And then you should you will then be able to to see the impact of those changes without actually making the changes on your website.

Howard Beader

23:16 - 23:17

That's very cool.

Claudio Biselli

23:17 - 25:24

Easier to see here. So this is, hold on one sec.

This is the actual experiment. Let me jump to another one here.

So this is so this is the experimental result. You can see we have a control run and an experiment.

So I want to check-in this case, the result of this experiment. So what we see is the experiment applied.

I've applied here what we already discussed, blocking this, sorry, aligning this script, aligning the CSS, and blocking this form. So, the impact of this experiment is, hopefully, you can see from the video, is that we have a bit of improvement here.

So the page let me run it again. So the the experimental one, the the one on the right seems quicker.

So let's take a look at what happened here. So this is the difference between the control run, which is the one without the experiment, and the the the one we have executed together, but without the experiments and the experiment itself.

So what we can see here is that, okay, there is a bit change on the time to first byte. We don't care about this number, even if it's better because, we want to remove, actually, this number from the other metrics.

So what we can see if we take a look, we compare the two screenshots, is that overall, we have so our response much quicker. So the the web page is actually start painting stuff earlier.

And we can see that overall so the response time are shifted a bit. So we can say instead of 0.

7, this is an improvement on around 0. 5, seconds with those changes.

So we can see the details of the experiments and the water. For for example, we can go to the experimental result, I think.

I.

Howard Beader

25:24 - 25:25

yeah. Yeah.

This one.

Claudio Biselli

25:25 - 35:20

So this is the experimental result. What we can see is the LCP is a bit, is low is lower.

Of course, we need to consider that the time to first byte is, like, zero point one seconds, worse than the original one, but in general, the SCP is better. And if we go to the waterfall, we can see now that our waterfall doesn't include anymore just blocking request.

The font is not anymore here. And if we take a look at your response, we've seen it now that this response is much bigger because we have included here your blocking JavaScript and CSS, which are now not blocking it anymore.

Another thing I want to mention is that, as you can see, this code is not minified. So probably another thing we would like to do on our build process is to minify this contact to, again, save more time, since the overall the the HTML size is going to be, a bit, tinier.

So that's an example of, improvements on our, web application where we didn't want to touch a piece of the application itself, which is the React side of thing. We wanted just to touch, the part before.

So another example is this one. So this is another experiments, and test that executed while using the same settings.

So it was at the same setting. Again, I've disabled a response bot is enabled to for demo purpose only.

What we see here again is that this is another pretty ish slow website with, large SCPs. We can check the again, our filmstrip will see that the website takes a lot of time to start showing something to the customer, and then our main view is not showing anything up to almost five seconds.

So the main content, which is, seems just looking at the screenshot, this image, is showing a bit late. So another thing what to mention is that if we take a look at this website, this is demo website, in web page test, so this website is divided in two.

So the first part is, the second part is a copy of the first part. So in this case, what we want to improve, of course, is the the initial view for our customers.

So we want this part to be snappy, to be responsive. So if we take a look at the waterfall for this use case, and, of course, we saw it from the FIMS FIMS stripper, but if we want to dig on the LCP, please know that now that is this dog image.

And checking, more on the test, we saw that we can see that this dog image is lazy loaded. So probably this is mistake from someone, but we should probably get rid of these senses, our LCP.

So we don't want this contact to be the lazy load, it should be, actually high priority. So if we take a look at the waterfall, what we can see about this doggy's image is that it's not here, it's not here.

It's pretty I mean, it's requested, I mean, not with that high priority, as we can see to this, lazy loading, attack. Another thing we can we notice is that instead those images, which are, for demo purpose, have the same names as the same image with additional parameters, is requested before the the main content.

Again, what another thing we can do here to improve our our LCP is getting rid of what we can related to, blocking requests. We can see that this bugs CSS is throwing a four zero four.

This, this JavaScript as well is throwing a four zero four, but all those requests need to be scheduled, and the browser then need to take care of those. Again, here, another thing we can see is that those files, caused our radar, and then this radar is causing a four zero four.

So there are a bunch of improvement just to looking at the waterfall that we can apply. So for sure, we want to touch, the task for those images to adjust the priority.

So taking a look again at our opportunities, you can see that the tool is is saying to us, hey, you have multiple JavaScript, file which is blocking the rendering. So another thing we can do is we can align them as well.

We can play with the CSS to to check the impact and do it in also into multiple steps. If it doesn't do not need to flag everything and check the results because also could have, like, a misleading output.

So we want to one we are improving our CP, so let's try to get rid of some blocking request. Another one, this one.

So the LCP side so what you can do, you can preload it. You can, add the priority in here to tell the browser, hey, I need it quickly.

So what we can do here, for example, is add the Fetch Priority eye and we can remove, of course, the lazy, tag to the same image and we should probably add this lazy load tag to the, images that we do not carry immediately, which are the one below. There are probably more experiments.

I don't want to add too many of those because, the output may be, messy. So what I've done here is I've, in this experiment, I've executed for this website, I've aligned some render blocking script, I've aligned some CSS, which were blocking were blocking the, or delaying the LCP, add priority into our LCP image, remove it in lazy loading to our LCP image, I've added the lazy, loading lazy to the other images, the one below, and I've also blocked some of the requests, which are where causing 404 or redirection causing Dan four zero four.

So what we can see here is that so we have something red, but if you can take if you can check here, it's just because the control run and the experiments runs. For some reason, the server I mean, especially for the experiments, replied, very late.

So we have a time to first byte delay, which, we can, I mean, skip it? So we're running the experiments, probably, we will get rid of this number. So but the cool thing is that our SCP, even if the time to first byte is going down, is better.

Because now, if we take a look at the screenshot, so we have now our SCP kinda immediately here, while above, it's around four seconds. Oh, sorry.

I need to refresh the page. Yeah.

So 3. 3 here.

And, yeah, you can see the the experience overall. I mean, you need to wait almost one second and a half, two seconds more to to get your first content for paying.

So, of course, in this case, also probably we had also a bit of layout shift to to this image. So probably we another thing we can do to improve our CP in this case is to add the or or the service space in our HTML, so add the proper dimension to our placeholder in order to avoid some layout shift.

And, I mean, overall, you can see we can take a look also, at the experiment itself and, overall, the experience, just looking at the result from there is way more better. So checking the experiment here, you can see now the talk here is immediately requested, and this is bumping the performance for our website.

Instead, the index, of course, takes a bit more time because, again, we are pushing stuff to our HTML, content, so this is increasing the size, so it takes more time. Also, the server is not performing that good.

So how about another thing in this case we would like to, ensure is the performance of our server?

Mikayla Reddy

35:20 - 35:43

Yes. So it seems like in these instant tests, right, this is a great way for you to kind of dig into the waterfall, identify where those performance bottlenecks will be, and also test out those different different recommendations to improve your page.

What would you do in the portal when it comes to looking more at monitoring over time for these specific metrics?

Claudio Biselli

35:43 - 38:26

So let's say that, of course, this is more a playground. So here you want to play with, as we saw before, like, mix and match and stuff like RAM or any analytics source you have to configure your test, find, tune the configuration in order to to to look at the cases you really care about.

But once you have them so let's say you find your configuration, you know what you want to improve, and, eventually, you improve it. What you want then to ensure is that, your metrics are not deteriorating over time due to server maintenance, due to deploy, measure deploy, something like that.

So what you can do is schedule your test configuration to be executed periodically. It can be once per day, every hour, whatever you want.

And so for that, I have should I have another example? Let's see. Yeah.

So for example here, for, the first application, this is the the the cinema application. We have set up, those tests which are web page test test executed every, certain amount of hours.

So in this case, it's, we're executed at 4AM, eight AM, and so on. So we have ranges where we are running our, test, and this allows me to, run it first, run it from multiple location instead of just one, run multiple web pages instead of just one, and analyze different metrics together.

Also from this test configuration, you can set up alerts so you can adjust, the threshold for your metrics. So let's say that you want to for example, here here we are looking on FCP, or let's say you want to be alerted when your SCP goes above your threshold.

So you don't want your SCP to to to to force any reason to become so bad. So you can set up alerts.

You will receive alerts when, for any reason, this is going to happen. And also, I mean, this one gives you details for specific request, but we have some, smart board that you to display aggregated metrics, for your continuous monitoring for your web pages in this case.

Mikayla Reddy

38:26 - 39:13

Yeah. That's kinda how people use Catchpoint too to be more proactive.

I see a question in the chat too about what's the difference between webpagetest. org and then also using Catchpoint instead.

So that's one of the big ones too being having the ability to monitor these metrics over time so that you can be proactive, integrate with any of your existing alerting tools, make sure that you're ahead of those performance bottlenecks before your users are ever impacted. So catch point, and we're gonna dive a little bit deeper into this as well because okay.

Web page test is important. You we obviously wanna make sure that your core web vitals page speed are where they should be.

But, Claudio, what are we gonna do when you need more than just web page test alone?

Claudio Biselli

39:13 - 40:40

I mean, in general, we saw that, there is a good, way to use other tools like RAM, Lighthouse to, embed and play with them to adjust your settings. For example, I'll identify and optimize, for example, we have RAM, you can check the location to optimize your city and distribution to set the content more closer to your the user you care more.

Another thing which is say, outside, let's say, to our code to to the code for your website, maybe to, dig on other components that can impact the performance of your website. So in this case, for example, should I have another dashboard? Yeah.

So for example, here, what we can see is stock map, which is another tool into the touchpoint portal where instead of focusing on the, page itself, you have an overview of the service that take place, in experience of your websites. If there are incidents on the service, you can modify the same I mean, so you can have others also on the dependency that take place in the overall experience.

Mikayla Reddy

40:40 - 41:50

Yeah. So this is a super powerful view for anybody who hasn't seen it before.

This is Catchpoint internet stack map. So obviously your services rely on more than just the front end of the internet, right? You could have the best performing website when it comes to things like core web vitals, but if you have anything, whether it be within your control or out of your control, CDNs, DNS, BGP, APIs, third parties, there's a lot of things that make your user get from where they're accessing it on say their local ISP all the way to where your services are hosted.

So if there's anything going wrong in that end to end experience, that's gonna cause problems for your users. And the other problem that it causes is for your own teams when you're trying to investigate these issues.

It's not a front end issue. What do we do now? What team's responsible for it? This view specifically makes it very easy to identify which one of your dependencies could be causing different problems.

And you'll also see on the right side there, it'll show different information like, packet loss, percentage of downtime. It makes it easier for your triage process when you have to solve bigger problems than just web page test alone.

Howard Beader

41:50 - 41:57

Yeah. And, Mikayla, this also ties in data from Internet sonar as well.

Isn't that right?

Mikayla Reddy

41:57 - 42:14

Yeah. Yeah.

Internet sonar, we have, a lot of different locations across the globe monitoring a lot of different, dependencies. So makes it, again, easier to triage and figure out where the problem actually is instead of you having to figure it out.

Howard Beader

42:14 - 42:31

Right. Because then with Internet sonar, you know whether it's something, that's you guys or something that's, you know, out of your control, like there's another outage, across the web that just hasn't maybe been updated yet.

‍

Mikayla Reddy

42:31 - 49:16

Mhmm. Yeah.

So that kind of concludes our demo unless there's, anything else that, we missed there. Cool.

Yeah. So now just gonna go over a couple of the key takeaways from that.

Right? So number one, you need to be continuously monitoring and optimizing your websites. Obviously, web page tests, as we went over, is a very valuable tool when it comes to getting very granular with looking at what your web performance looks like.

The waterfall is second to none. I talked to, again, a lot of web page test users, and a lot of them say even though I'm using x y z other tool, I still have to come to webpagetest.

org to actually figure out what the problem is. So that waterfall is a super powerful tool for you.

And, obviously, when we were showing the, opportunities and experiments too, being able to figure out what those changes are gonna impact when it comes to different metrics without actually having to change your code, huge time saver and better way to go about your CICD process. We also give you the ability to script different user journeys that you would maybe identify with things like RUM and also custom metrics too because of course core web vitals are important, but different companies rely on different metrics for success.

So we allow you to get very custom with the way that you're running these tests as well when it comes to those different, settings that Claudio Biselli was walking us through. But it's not enough to just use web page tests because you need to be proactive when it comes to web performance.

You don't want to fall behind your competitors, Howard was great with giving us examples as to why that's so important to your business. So, being able to schedule those tests, set those proactive alerts, getting ahead of those issues before it impacts your users is super important, and again with integrating with those different CICD tools too.

So pulling this data with an API to push it into a different tool that you rely on, make it very easy for you to, look at these different metrics in a way that makes sense for you. And then key takeaway number two is that effective strategy requires both synthetic and real user monitoring.

Again, synthetic is gonna give you that proactive view, but like we talked about with Core Web Vitals, those are both lab and fields data, so that requires real user monitoring. Real user monitoring is just a super lightweight JavaScript tag that you can add to your page that will collect that information from your real users.

It'll help you identify those long term trends. So, for example, slow user journeys that will negative negatively impact metrics like INP.

You wanna make sure that you know what those are. You need rum for that.

You can't do it with just synthetics alone, but then you can use synthetics after you identify what those journeys are to actually monitor and improve those as well and take that proactive approach. Key takeaway number three, scalability is key for your growth.

So, we always talk about the complexity of the Internet. I swear everybody's trying to keep us on our toes with the things that you have to keep paying attention to and monitor and make sure nothing's going down to be successful, have a great user experience.

You can see the Internet stack there just how many dependencies your services actually rely on for your users to get from A to B. So, performance is more than just the front end, you need a tool that's able to scale with your team as you grow too.

Maybe web page test is what you need for now, you need to make sure that your core web vitals are up to date, but what if there's something wrong with a CDN? What are you gonna do? You need to be able to have a tool that makes it really easy to just turn on the lights. Let's let's run a different type of test.

Makes it so much easier than having to go sign a contract with something else and figure it figure it out in a different way. And then just to reiterate that too with Internet stack map, it'll give you that complete and visibility into all of your internal and external dependencies.

This chart will look very different depending on what yours are. Everybody's looks different, it depends on what you use, but you'll be alerted on anything that could be going wrong in your entire Internet stack so you can monitor what matters, where it matters so that you can get to the issue faster.

And then we got a little poll, that we'll push out to you here if you'd be interested in seeing a personalized demo, with one of our technical experts. Odds are I'll probably be on that call too.

But we would love to kinda set up a couple tests and Catchpoint just to show you what that data can look like with your own websites and things like that so we can share that with you as well. So feel free to let us know if you'd be interested in a demo or if you would like more information in general, we're happy to get some info sent out to you as well.

And then this part I'm very excited for personally. We have an exclusive promo for our live attendees with our web page test expert plan.

So, this is a new plan that we came out with, that will enable you at the starting point. Of course, this can be changed based on requirements, but starting point is 30,000 web page test runs a month and 10,000,000 run page views a month.

So that will enable you to start testing, scheduling those tests using experiments, those instant tests that Claudio was showing us, and then also have rum in one single pane of glass. And the exclusive promo part is that you would be getting essentially 50% off where if you were to sign for $6,000 within the first ninety days of talking to us, we can give you that promo so that we can, get you into catch points, start using web page test and real user monitoring together.

And then as your use cases or requirements get a little bit more in-depth or change, you can easily start running other types of tests within the Catchpoint portal quite literally in a few minutes. It's very fast and easy to get it set up.

So, we'd love to have some of you take advantage of this. If it's something that you're interested in, we will definitely be in touch.

You getting all that value at half the cost. And yeah, I think that's essentially what we wanted to share with you today.

If there are any questions, I know that I saw some coming in. So when you're asking about LCP for soft navigation on single page applications, what are you needing from that?

Claudio Biselli

49:16 - 49:43

I saw that. Yeah.

Close. I mean yeah.

So about that, we are experimenting with it. So we should be able to add more support, for soft navigation, pretty soon.

So but, yeah, let's keep in touch. I think we can go together through through that maybe separately.

Howard Beader

49:43 - 49:52

Alright. If there's no more questions.

Alright. Thank you all.

Mikayla Reddy

49:52 - 50:00

Yeah. Thank you so much for joining us.

And, of course, if you have any questions, feel free to reach out to us, and we'll be sure to get back to you as soon as we can.  

‍