Learn how to take advantage of ⚡ Firebase Performance Monitoring on the web in this quick overview and tutorial. https://fireship.io/lessons/firebase-performance-quickstart/

#firebase #web #io19

Don't forget to take the quiz 🤓

iOS https://itunes.apple.com/us/app/fireship/id1462592372?mt=8
Android https://play.google.com/store/apps/details?id=io.fireship.quizapp

Official docs https://firebase.google.com/docs/perf-mon/get-started-web
I/O announcement https://youtu.be/LoLqSbV1ELU?t=3071

Upgrade to Fireship PRO at https://fireship.io/pro
Use code lORhwXd2 for 25% off your first payment.
2024-02-04T06:47:08.102Z
nova-2
2-general-nova
2024-01-09.29447
30089e05-99d1-4376-b32e-c263170674af
d2738800-b57f-4b4f-8d71-02fcbedbf3d8
cde8bde032ca15eeab816fed491c0bfae4bc710041aeb092918b6f13d46247c9
67875a7f-c9c4-48a0-aa55-5bdb8a91c34a
deprecated
There were a whole bunch of awesome announcements at Google IO 2019, but my personal favorite is definitely Firebase Performance for the web.
Well, today, we're expanding performance monitoring to the web.
This is a tool that can benefit any website that cares about performance, even if that site isn't already using other Firebase products.
By simply adding a script tag to your site or including Firebase Perf in your JavaScript bundle, you'll get insights about how your web app performs out in the real world in terms of initial page load performance and HTTP calls over the network.
In today's video, we'll look at the basics of Firebase Performance and take things a few steps further by implementing our own custom traces.
And we'll look at some awesome upcoming features in AngularFire to integrate with Angular and RxJS.
If you're new here, like and subscribe and make sure to download the mobile app on iOS Android to take the Firebase Performance quiz after you're done watching this video.
Now there's a few different ways we can use Firebase Performance.
The most basic way is to use it as just standalone tool in an existing website.
This approach will insert a lightweight script into your HTML document, and then you'll automatically get all kinds of performance reporting on the Firebase console.
This is a great option if you have an existing website and you want some performance reporting, but you don't wanna use any other Firebase products.
The next option is to use it in combination with Firebase Hosting.
If you're already using Firebase Hosting, you can use these magic script tags to easily import it into your project.
But I think the vast majority of people will use it in combination with a module bundler like Webpack.
That's how we're going to use it today in the context of an Angular application, but the process is very similar for all JavaScript frameworks.
The first thing you wanna do is install the latest version of Firebase, making sure that version 6.0 or greater.
Now most of the code that we'll look at is relevant to any JavaScript app, but at the end of the video, we're going to look at some really cool new bleeding edge stuff from the AngularFire library.
At the time of this video, you can use it by installing AngularFire with the next tag.
From there, you'll want to go to the Firebase console and go to the settings tab, And you'll see an option to now add your app as a web app.
You'll wanna do this even if you have an existing app because there's a new property that you need to have in your Firebase config in order to work with Firebase Performance.
Populate, so don't be worried if you don't see any data after deploying initially.
I was lucky enough to be able to test Firebase Performance before it was officially released, so I have quite a bit of data built up here for Fireship IO.
Actual data that you see on the dashboard is similar to what you would see on a Lighthouse performance score that you run locally in your Chrome browser, except this data is being collected and across all your users in the real world.
On the dashboard, I can see the aggregate performance for things like First Paint, First Contentful Paint, DOM Interactive, how they're distributed across the entire user base.
By looking at this distribution, I can see that the majority of my users are seeing page load times in less than 2 seconds, so that's pretty good.
But I'm always pushing new code to my web app.
So what if I do something that makes the performance decline?
I can easily determine if my performance is getting better or worse by looking at the trend over time.
Ideally, you wanna see this chart have a negative slope because faster is always better.
And on top of that, we can filter this data by region, by device, and even whether or not the user has a service worker installed.
This allows us to figure out what users are being affected by a performance bottleneck and what the root cause might be.
In addition to page loads, it will also keep track of HTTP calls over the network.
If you have some sort of async activity that's causing a performance bottleneck, you'll be able to find it here.
Now everything I've showed you so far will just work out of the box when you include Firebase Performance in your app.
But you can also write your own custom traces within your app's code, and that opens the door to all kinds of cool possibilities.
For example, I have a custom trace here on a login model that users click to log in to the app.
And this allows me to see exactly how long it takes a user on average to log in to the app.
But one thing I do wanna point out at this point is that you should never use any personally identifiable information inside of a trace, things like email addresses or phone numbers.
Not only is that a bad practice for user privacy, but Google will for automatic deletion anyway.
We'll be writing our own custom traces in just a minute.
And once you've collected some data, you'll have a screen that looks like this that you can filter by different attributes.
You can even create your own custom attributes in your code, and you can also set up your own custom thresholds to signify a certain point that a metric would be considered poor performance.
My case, I've already gotten valuable insight from this trace because I found out that users on Safari take way longer to log in than users on Chrome or Firefox.
The reason I detected that is because Firebase is smart enough to warn me about it with this little orange icon here.
So it'll automatically tell you when a certain segment seems out of the ordinary, And that's all based on real world data from Fireship.
Let's go ahead and jump into the code and write our own custom traces.
Back in our Angular app, we'll go into the app module and then set up the Firebase config making sure that it contains the app ID.
I've already included Firestore and AngularFire auth in here and then we can go ahead and include the AngularFire performance module.
In the component, we'll go ahead and import Firebase from Firebase app and then initialize Firebase performance.
On iOS and Android, FirePerf will automatically track how long a screen has been opened, but we can also do that in a single page application by using the life cycle hooks in the framework.
Now the trace itself, you can think of like a stopwatch.
Time, but we can also add custom attributes and metrics in between as we'll see later.
So in this case here, we'll start our trace during ng on init, and then we'll end the trace during ng on destroy.
Now we'll have an understanding of exactly how much time our users are spending on the login page.
So that represents your most simple use case for a custom trace, but there's a whole lot we can do in between the start and stop point.
This is the function that we would call after the user submits a form with their email and password.
The first thing we'll do is create an instance of a trace called user login and start it.
Then stop it at the end of the function and add a try catch block in between the start and stop point.
What we'll try to do is log in the user with email and password, strings that allow you to segment your data in different ways.
Setting really good attributes will result in really good performance reporting on the Firebase console.
Let's imagine we have a function here that loads user data that makes multiple queries to different Firestore collections, and we wanna know how long that query takes and also how many documents are read in the process.
Read is complete, we'll call trace increment metric, and we'll set a metric as total size.
That will keep track of the total size of all reads that we perform in this function.
We can also create another metric that's just based on the size of the items collection only.
If we wanna do that, we can call trace put metric, And this will add a metric to this trace that doesn't really change over the life cycle of the trace.
So increment metric is really useful when you have data that might change, like incrementing the score on a game or something like that.
Our case here, we'll read from another collection called things.
And then this time, we'll use the total size of that collection to increment our total size metric.
So if there were 10 documents in the first query and then 15 documents in the second query, our total value would be 25 for this particular trace.
Now I like this code for an async function, but if this were an observable, it means we would have to pipe in the tap operator all over the place to start and stop the trace.
Thankfully, James Daniels, who's the lead maintainer of AngularFire, has put in some work to make this a lot easier, especially for Angular RxJS developers.
And then give it a name, and that will automatically give you the latency of a collection read.
You don't even need to call start or stop because it automatically knows to do that when you subscribe to the observable.
In this case, it will automatically stop the trace when the observable emits data, but there's also several more operators in there that allow you to handle more advanced use cases.
My favorite is trace and till.
This allows you to set up a trace but only stop the trace when a certain condition has been met.
For example, say you have a game running and then you're making multiple updates to that document based on the state of the game.
Once the game over property is set to true, then it ends the trace here.
And then there's also a third option for trace options that allow you to do things like set attributes and metrics like we did before.
Overall, this is a very promising update for AngularFire, but more importantly, Firebase Performance is pretty much a no brainer for every app.
It's free, easy to set up, Lightweight and it will help you catch problems that you didn't even know existed.
I'm gonna go ahead and wrap things up there.
If this video helped you, please like and subscribe.
And if you want even more content, consider becoming a pro member at FireShip IO.
And don't forget to take the quiz on the FireShip mobile app to see if you learned anything.
Thanks for watching, and I will talk to you soon.

Speaker 0: There were a whole bunch of awesome announcements at Google IO 2019, but my personal favorite is definitely Firebase Performance for the web. Well, today, we're expanding performance monitoring to the web. This is a tool that can benefit any website that cares about performance, even if that site isn't already using other Firebase products. By simply adding a script tag to your site or including Firebase Perf in your JavaScript bundle, you'll get insights about how your web app performs out in the real world in terms of initial page load performance and HTTP calls over the network. In today's video, we'll look at the basics of Firebase Performance and take things a few steps further by implementing our own custom traces.

And we'll look at some awesome upcoming features in AngularFire to integrate with Angular and RxJS. If you're new here, like and subscribe and make sure to download the mobile app on iOS Android to take the Firebase Performance quiz after you're done watching this video. Now there's a few different ways we can use Firebase Performance. The most basic way is to use it as just standalone tool in an existing website. This approach will insert a lightweight script into your HTML document, and then you'll automatically get all kinds of performance reporting on the Firebase console.

This is a great option if you have an existing website and you want some performance reporting, but you don't wanna use any other Firebase products. The next option is to use it in combination with Firebase Hosting. If you're already using Firebase Hosting, you can use these magic script tags to easily import it into your project. But I think the vast majority of people will use it in combination with a module bundler like Webpack. That's how we're going to use it today in the context of an Angular application, but the process is very similar for all JavaScript frameworks.

The first thing you wanna do is install the latest version of Firebase, making sure that version 6.0 or greater. Now most of the code that we'll look at is relevant to any JavaScript app, but at the end of the video, we're going to look at some really cool new bleeding edge stuff from the AngularFire library. At the time of this video, you can use it by installing AngularFire with the next tag. From there, you'll want to go to the Firebase console and go to the settings tab, And you'll see an option to now add your app as a web app. You'll wanna do this even if you have an existing app because there's a new property that you need to have in your Firebase config in order to work with Firebase Performance.

Populate, so don't be worried if you don't see any data after deploying initially. I was lucky enough to be able to test Firebase Performance before it was officially released, so I have quite a bit of data built up here for Fireship IO. Actual data that you see on the dashboard is similar to what you would see on a Lighthouse performance score that you run locally in your Chrome browser, except this data is being collected and across all your users in the real world. On the dashboard, I can see the aggregate performance for things like First Paint, First Contentful Paint, DOM Interactive, how they're distributed across the entire user base. By looking at this distribution, I can see that the majority of my users are seeing page load times in less than 2 seconds, so that's pretty good.

But I'm always pushing new code to my web app. So what if I do something that makes the performance decline? I can easily determine if my performance is getting better or worse by looking at the trend over time. Ideally, you wanna see this chart have a negative slope because faster is always better. And on top of that, we can filter this data by region, by device, and even whether or not the user has a service worker installed.

This allows us to figure out what users are being affected by a performance bottleneck and what the root cause might be. In addition to page loads, it will also keep track of HTTP calls over the network. If you have some sort of async activity that's causing a performance bottleneck, you'll be able to find it here. Now everything I've showed you so far will just work out of the box when you include Firebase Performance in your app. But you can also write your own custom traces within your app's code, and that opens the door to all kinds of cool possibilities.

For example, I have a custom trace here on a login model that users click to log in to the app. And this allows me to see exactly how long it takes a user on average to log in to the app. But one thing I do wanna point out at this point is that you should never use any personally identifiable information inside of a trace, things like email addresses or phone numbers. Not only is that a bad practice for user privacy, but Google will for automatic deletion anyway. We'll be writing our own custom traces in just a minute.

And once you've collected some data, you'll have a screen that looks like this that you can filter by different attributes. You can even create your own custom attributes in your code, and you can also set up your own custom thresholds to signify a certain point that a metric would be considered poor performance. My case, I've already gotten valuable insight from this trace because I found out that users on Safari take way longer to log in than users on Chrome or Firefox. The reason I detected that is because Firebase is smart enough to warn me about it with this little orange icon here. So it'll automatically tell you when a certain segment seems out of the ordinary, And that's all based on real world data from Fireship.

Let's go ahead and jump into the code and write our own custom traces. Back in our Angular app, we'll go into the app module and then set up the Firebase config making sure that it contains the app ID. I've already included Firestore and AngularFire auth in here and then we can go ahead and include the AngularFire performance module. In the component, we'll go ahead and import Firebase from Firebase app and then initialize Firebase performance. On iOS and Android, FirePerf will automatically track how long a screen has been opened, but we can also do that in a single page application by using the life cycle hooks in the framework.

Now the trace itself, you can think of like a stopwatch. Time, but we can also add custom attributes and metrics in between as we'll see later. So in this case here, we'll start our trace during ng on init, and then we'll end the trace during ng on destroy. Now we'll have an understanding of exactly how much time our users are spending on the login page. So that represents your most simple use case for a custom trace, but there's a whole lot we can do in between the start and stop point.

This is the function that we would call after the user submits a form with their email and password. The first thing we'll do is create an instance of a trace called user login and start it. Then stop it at the end of the function and add a try catch block in between the start and stop point. What we'll try to do is log in the user with email and password, strings that allow you to segment your data in different ways. Setting really good attributes will result in really good performance reporting on the Firebase console.

Let's imagine we have a function here that loads user data that makes multiple queries to different Firestore collections, and we wanna know how long that query takes and also how many documents are read in the process. Read is complete, we'll call trace increment metric, and we'll set a metric as total size. That will keep track of the total size of all reads that we perform in this function. We can also create another metric that's just based on the size of the items collection only. If we wanna do that, we can call trace put metric, And this will add a metric to this trace that doesn't really change over the life cycle of the trace.

So increment metric is really useful when you have data that might change, like incrementing the score on a game or something like that. Our case here, we'll read from another collection called things. And then this time, we'll use the total size of that collection to increment our total size metric. So if there were 10 documents in the first query and then 15 documents in the second query, our total value would be 25 for this particular trace. Now I like this code for an async function, but if this were an observable, it means we would have to pipe in the tap operator all over the place to start and stop the trace.

Thankfully, James Daniels, who's the lead maintainer of AngularFire, has put in some work to make this a lot easier, especially for Angular RxJS developers. And then give it a name, and that will automatically give you the latency of a collection read. You don't even need to call start or stop because it automatically knows to do that when you subscribe to the observable. In this case, it will automatically stop the trace when the observable emits data, but there's also several more operators in there that allow you to handle more advanced use cases. My favorite is trace and till.

This allows you to set up a trace but only stop the trace when a certain condition has been met. For example, say you have a game running and then you're making multiple updates to that document based on the state of the game. Once the game over property is set to true, then it ends the trace here. And then there's also a third option for trace options that allow you to do things like set attributes and metrics like we did before. Overall, this is a very promising update for AngularFire, but more importantly, Firebase Performance is pretty much a no brainer for every app.

It's free, easy to set up, Lightweight and it will help you catch problems that you didn't even know existed. I'm gonna go ahead and wrap things up there. If this video helped you, please like and subscribe. And if you want even more content, consider becoming a pro member at FireShip IO. And don't forget to take the quiz on the FireShip mobile app to see if you learned anything.

Thanks for watching, and I will talk to you soon.
There were a whole bunch of awesome announcements at Google IO 2019, but my personal favorite is definitely Firebase Performance for the web. Well, today, we're expanding performance monitoring to the web. This is a tool that can benefit any website that cares about performance, even if that site isn't already using other Firebase products.
google
internet
By simply adding a script tag to your site or including Firebase Perf in your JavaScript bundle, you'll get insights about how your web app performs out in the real world in terms of initial page load performance and HTTP calls over the network. In today's video, we'll look at the basics of Firebase Performance and take things a few steps further by implementing our own custom traces. And we'll look at some awesome upcoming features in AngularFire to integrate with Angular and RxJS. If you're new here, like and subscribe and make sure to download the mobile app on iOS Android to take the Firebase Performance quiz after you're done watching this video. Now there's a few different ways we can use Firebase Performance. The most basic way is to use it as just standalone tool in an existing website. This approach will insert a lightweight script into your HTML document, and then you'll automatically get all kinds of performance reporting on the Firebase console. This is a great option if you have an existing website and you want some performance reporting, but you don't wanna use any other Firebase products. The next option is to use it in combination with Firebase Hosting. If you're already using Firebase Hosting, you can use these magic script tags to easily import it into your project. But I think the vast majority of people will use it in combination with a module bundler like Webpack. That's how we're going to use it today in the context of an Angular application, but the process is very similar for all JavaScript frameworks.
The first thing you wanna do is install the latest version of Firebase, making sure that version 6.0 or greater. Now most of the code that we'll look at is relevant to any JavaScript app, but at the end of the video, we're going to look at some really cool new bleeding edge stuff from the AngularFire library.
youtube
At the time of this video, you can use it by installing AngularFire with the next tag. From there, you'll want to go to the Firebase console and go to the settings tab, And you'll see an option to now add your app as a web app. You'll wanna do this even if you have an existing app because there's a new property that you need to have in your Firebase config in order to work with Firebase Performance. Populate, so don't be worried if you don't see any data after deploying initially. I was lucky enough to be able to test Firebase Performance before it was officially released, so I have quite a bit of data built up here for Fireship IO.
Actual data that you see on the dashboard is similar to what you would see on a Lighthouse performance score that you run locally in your Chrome browser, except this data is being collected and across all your users in the real world. On the dashboard, I can see the aggregate performance for things like First Paint, First Contentful Paint, DOM Interactive, how they're distributed across the entire user base.
data
statistics
By looking at this distribution, I can see that the majority of my users are seeing page load times in less than 2 seconds, so that's pretty good. But I'm always pushing new code to my web app. So what if I do something that makes the performance decline? I can easily determine if my performance is getting better or worse by looking at the trend over time.
Ideally, you wanna see this chart have a negative slope because faster is always better. And on top of that, we can filter this data by region, by device, and even whether or not the user has a service worker installed. This allows us to figure out what users are being affected by a performance bottleneck and what the root cause might be. In addition to page loads, it will also keep track of HTTP calls over the network. If you have some sort of async activity that's causing a performance bottleneck, you'll be able to find it here.
data analysis
data management
networking
data
Now everything I've showed you so far will just work out of the box when you include Firebase Performance in your app. But you can also write your own custom traces within your app's code, and that opens the door to all kinds of cool possibilities. For example, I have a custom trace here on a login model that users click to log in to the app. And this allows me to see exactly how long it takes a user on average to log in to the app. But one thing I do wanna point out at this point is that you should never use any personally identifiable information inside of a trace, things like email addresses or phone numbers.
Not only is that a bad practice for user privacy, but Google will for automatic deletion anyway. We'll be writing our own custom traces in just a minute. And once you've collected some data, you'll have a screen that looks like this that you can filter by different attributes. You can even create your own custom attributes in your code, and you can also set up your own custom thresholds to signify a certain point that a metric would be considered poor performance.
google
data
My case, I've already gotten valuable insight from this trace because I found out that users on Safari take way longer to log in than users on Chrome or Firefox. The reason I detected that is because Firebase is smart enough to warn me about it with this little orange icon here. So it'll automatically tell you when a certain segment seems out of the ordinary, And that's all based on real world data from Fireship. Let's go ahead and jump into the code and write our own custom traces. Back in our Angular app, we'll go into the app module and then set up the Firebase config making sure that it contains the app ID. I've already included Firestore and AngularFire auth in here and then we can go ahead and include the AngularFire performance module. In the component, we'll go ahead and import Firebase from Firebase app and then initialize Firebase performance. On iOS and Android, FirePerf will automatically track how long a screen has been opened, but we can also do that in a single page application by using the life cycle hooks in the framework.
Now the trace itself, you can think of like a stopwatch. Time, but we can also add custom attributes and metrics in between as we'll see later. So in this case here, we'll start our trace during ng on init, and then we'll end the trace during ng on destroy.
hunting
Now we'll have an understanding of exactly how much time our users are spending on the login page. So that represents your most simple use case for a custom trace, but there's a whole lot we can do in between the start and stop point. This is the function that we would call after the user submits a form with their email and password. The first thing we'll do is create an instance of a trace called user login and start it. Then stop it at the end of the function and add a try catch block in between the start and stop point. What we'll try to do is log in the user with email and password, strings that allow you to segment your data in different ways. Setting really good attributes will result in really good performance reporting on the Firebase console. Let's imagine we have a function here that loads user data that makes multiple queries to different Firestore collections, and we wanna know how long that query takes and also how many documents are read in the process. Read is complete, we'll call trace increment metric, and we'll set a metric as total size. That will keep track of the total size of all reads that we perform in this function.
We can also create another metric that's just based on the size of the items collection only. If we wanna do that, we can call trace put metric, And this will add a metric to this trace that doesn't really change over the life cycle of the trace. So increment metric is really useful when you have data that might change, like incrementing the score on a game or something like that. Our case here, we'll read from another collection called things. And then this time, we'll use the total size of that collection to increment our total size metric.
data
measurement
So if there were 10 documents in the first query and then 15 documents in the second query, our total value would be 25 for this particular trace. Now I like this code for an async function, but if this were an observable, it means we would have to pipe in the tap operator all over the place to start and stop the trace. Thankfully, James Daniels, who's the lead maintainer of AngularFire, has put in some work to make this a lot easier, especially for Angular RxJS developers. And then give it a name, and that will automatically give you the latency of a collection read. You don't even need to call start or stop because it automatically knows to do that when you subscribe to the observable. In this case, it will automatically stop the trace when the observable emits data, but there's also several more operators in there that allow you to handle more advanced use cases.
My favorite is trace and till. This allows you to set up a trace but only stop the trace when a certain condition has been met. For example, say you have a game running and then you're making multiple updates to that document based on the state of the game. Once the game over property is set to true, then it ends the trace here. And then there's also a third option for trace options that allow you to do things like set attributes and metrics like we did before.
games
mining
hunting
Overall, this is a very promising update for AngularFire, but more importantly, Firebase Performance is pretty much a no brainer for every app. It's free, easy to set up, Lightweight and it will help you catch problems that you didn't even know existed.
I'm gonna go ahead and wrap things up there. If this video helped you, please like and subscribe. And if you want even more content, consider becoming a pro member at FireShip IO. And don't forget to take the quiz on the FireShip mobile app to see if you learned anything.
youtube
Thanks for watching, and I will talk to you soon.
There were a whole bunch of awesome announcements at Google IO 2019, but my personal favorite is definitely Firebase Performance for the web. Well, today, we're expanding performance monitoring to the web. This is a tool that can benefit any website that cares about performance, even if that site isn't already using other Firebase products. By simply adding a script tag to your site or including Firebase Perf in your JavaScript bundle, you'll get insights about how your web app performs out in the real world in terms of initial page load performance and HTTP calls over the network. In today's video, we'll look at the basics of Firebase Performance and take things a few steps further by implementing our own custom traces. And we'll look at some awesome upcoming features in AngularFire to integrate with Angular and RxJS. If you're new here, like and subscribe and make sure to download the mobile app on iOS Android to take the Firebase Performance quiz after you're done watching this video. Now there's a few different ways we can use Firebase Performance. The most basic way is to use it as just standalone tool in an existing website. This approach will insert a lightweight script into your HTML document, and then you'll automatically get all kinds of performance reporting on the Firebase console. This is a great option if you have an existing website and you want some performance reporting, but you don't wanna use any other Firebase products. The next option is to use it in combination with Firebase Hosting. If you're already using Firebase Hosting, you can use these magic script tags to easily import it into your project. But I think the vast majority of people will use it in combination with a module bundler like Webpack. That's how we're going to use it today in the context of an Angular application, but the process is very similar for all JavaScript frameworks. The first thing you wanna do is install the latest version of Firebase, making sure that version 6.0 or greater. Now most of the code that we'll look at is relevant to any JavaScript app, but at the end of the video, we're going to look at some really cool new bleeding edge stuff from the AngularFire library. At the time of this video, you can use it by installing AngularFire with the next tag. From there, you'll want to go to the Firebase console and go to the settings tab, And you'll see an option to now add your app as a web app. You'll wanna do this even if you have an existing app because there's a new property that you need to have in your Firebase config in order to work with Firebase Performance. Populate, so don't be worried if you don't see any data after deploying initially. I was lucky enough to be able to test Firebase Performance before it was officially released, so I have quite a bit of data built up here for Fireship IO. Actual data that you see on the dashboard is similar to what you would see on a Lighthouse performance score that you run locally in your Chrome browser, except this data is being collected and across all your users in the real world. On the dashboard, I can see the aggregate performance for things like First Paint, First Contentful Paint, DOM Interactive, how they're distributed across the entire user base. By looking at this distribution, I can see that the majority of my users are seeing page load times in less than 2 seconds, so that's pretty good. But I'm always pushing new code to my web app. So what if I do something that makes the performance decline? I can easily determine if my performance is getting better or worse by looking at the trend over time. Ideally, you wanna see this chart have a negative slope because faster is always better. And on top of that, we can filter this data by region, by device, and even whether or not the user has a service worker installed. This allows us to figure out what users are being affected by a performance bottleneck and what the root cause might be. In addition to page loads, it will also keep track of HTTP calls over the network. If you have some sort of async activity that's causing a performance bottleneck, you'll be able to find it here. Now everything I've showed you so far will just work out of the box when you include Firebase Performance in your app. But you can also write your own custom traces within your app's code, and that opens the door to all kinds of cool possibilities. For example, I have a custom trace here on a login model that users click to log in to the app. And this allows me to see exactly how long it takes a user on average to log in to the app. But one thing I do wanna point out at this point is that you should never use any personally identifiable information inside of a trace, things like email addresses or phone numbers. Not only is that a bad practice for user privacy, but Google will for automatic deletion anyway. We'll be writing our own custom traces in just a minute. And once you've collected some data, you'll have a screen that looks like this that you can filter by different attributes. You can even create your own custom attributes in your code, and you can also set up your own custom thresholds to signify a certain point that a metric would be considered poor performance. My case, I've already gotten valuable insight from this trace because I found out that users on Safari take way longer to log in than users on Chrome or Firefox. The reason I detected that is because Firebase is smart enough to warn me about it with this little orange icon here. So it'll automatically tell you when a certain segment seems out of the ordinary, And that's all based on real world data from Fireship. Let's go ahead and jump into the code and write our own custom traces. Back in our Angular app, we'll go into the app module and then set up the Firebase config making sure that it contains the app ID. I've already included Firestore and AngularFire auth in here and then we can go ahead and include the AngularFire performance module. In the component, we'll go ahead and import Firebase from Firebase app and then initialize Firebase performance. On iOS and Android, FirePerf will automatically track how long a screen has been opened, but we can also do that in a single page application by using the life cycle hooks in the framework. Now the trace itself, you can think of like a stopwatch. Time, but we can also add custom attributes and metrics in between as we'll see later. So in this case here, we'll start our trace during ng on init, and then we'll end the trace during ng on destroy. Now we'll have an understanding of exactly how much time our users are spending on the login page. So that represents your most simple use case for a custom trace, but there's a whole lot we can do in between the start and stop point. This is the function that we would call after the user submits a form with their email and password. The first thing we'll do is create an instance of a trace called user login and start it. Then stop it at the end of the function and add a try catch block in between the start and stop point. What we'll try to do is log in the user with email and password, strings that allow you to segment your data in different ways. Setting really good attributes will result in really good performance reporting on the Firebase console. Let's imagine we have a function here that loads user data that makes multiple queries to different Firestore collections, and we wanna know how long that query takes and also how many documents are read in the process. Read is complete, we'll call trace increment metric, and we'll set a metric as total size. That will keep track of the total size of all reads that we perform in this function. We can also create another metric that's just based on the size of the items collection only. If we wanna do that, we can call trace put metric, And this will add a metric to this trace that doesn't really change over the life cycle of the trace. So increment metric is really useful when you have data that might change, like incrementing the score on a game or something like that. Our case here, we'll read from another collection called things. And then this time, we'll use the total size of that collection to increment our total size metric. So if there were 10 documents in the first query and then 15 documents in the second query, our total value would be 25 for this particular trace. Now I like this code for an async function, but if this were an observable, it means we would have to pipe in the tap operator all over the place to start and stop the trace. Thankfully, James Daniels, who's the lead maintainer of AngularFire, has put in some work to make this a lot easier, especially for Angular RxJS developers. And then give it a name, and that will automatically give you the latency of a collection read. You don't even need to call start or stop because it automatically knows to do that when you subscribe to the observable. In this case, it will automatically stop the trace when the observable emits data, but there's also several more operators in there that allow you to handle more advanced use cases. My favorite is trace and till. This allows you to set up a trace but only stop the trace when a certain condition has been met. For example, say you have a game running and then you're making multiple updates to that document based on the state of the game. Once the game over property is set to true, then it ends the trace here. And then there's also a third option for trace options that allow you to do things like set attributes and metrics like we did before. Overall, this is a very promising update for AngularFire, but more importantly, Firebase Performance is pretty much a no brainer for every app. It's free, easy to set up, Lightweight and it will help you catch problems that you didn't even know existed. I'm gonna go ahead and wrap things up there. If this video helped you, please like and subscribe. And if you want even more content, consider becoming a pro member at FireShip IO. And don't forget to take the quiz on the FireShip mobile app to see if you learned anything. Thanks for watching, and I will talk to you soon.
There
there
were
were
a
a
whole
whole
bunch
bunch
of
of
awesome
awesome
announcements
announcements
at
at
Google
google
IO
io
2019,
2019
but
but
my
my
personal
personal
favorite
favorite
is
is
definitely
definitely
Firebase
firebase
Performance
performance
for
for
the
the
web.
web
Well,
well
today,
today
we're
we're
expanding
expanding
performance
performance
monitoring
monitoring
to
to
the
the
web.
web
This
this
is
is
a
a
tool
tool
that
that
can
can
benefit
benefit
any
any
website
website
that
that
cares
cares
about
about
performance,
performance
even
even
if
if
that
that
site
site
isn't
isn't
already
already
using
using
other
other
Firebase
firebase
products.
products
By
by
simply
simply
adding
adding
a
a
script
script
tag
tag
to
to
your
your
site
site
or
or
including
including
Firebase
firebase
Perf
perf
in
in
your
your
JavaScript
javascript
bundle,
bundle
you'll
you'll
get
get
insights
insights
about
about
how
how
your
your
web
web
app
app
performs
performs
out
out
in
in
the
the
real
real
world
world
in
in
terms
terms
of
of
initial
initial
page
page
load
load
performance
performance
and
and
HTTP
http
calls
calls
over
over
the
the
network.
network
In
in
today's
today's
video,
video
we'll
we'll
look
look
at
at
the
the
basics
basics
of
of
Firebase
firebase
Performance
performance
and
and
take
take
things
things
a
a
few
few
steps
steps
further
further
by
by
implementing
implementing
our
our
own
own
custom
custom
traces.
traces
And
and
we'll
we'll
look
look
at
at
some
some
awesome
awesome
upcoming
upcoming
features
features
in
in
AngularFire
angularfire
to
to
integrate
integrate
with
with
Angular
angular
and
and
RxJS.
rxjs
If
if
you're
you're
new
new
here,
here
like
like
and
and
subscribe
subscribe
and
and
make
make
sure
sure
to
to
download
download
the
the
mobile
mobile
app
app
on
on
iOS
ios
Android
android
to
to
take
take
the
the
Firebase
firebase
Performance
performance
quiz
quiz
after
after
you're
you're
done
done
watching
watching
this
this
video.
video
Now
now
there's
there's
a
a
few
few
different
different
ways
ways
we
we
can
can
use
use
Firebase
firebase
Performance.
performance
The
the
most
most
basic
basic
way
way
is
is
to
to
use
use
it
it
as
as
just
just
standalone
standalone
tool
tool
in
in
an
an
existing
existing
website.
website
This
this
approach
approach
will
will
insert
insert
a
a
lightweight
lightweight
script
script
into
into
your
your
HTML
html
document,
document
and
and
then
then
you'll
you'll
automatically
automatically
get
get
all
all
kinds
kinds
of
of
performance
performance
reporting
reporting
on
on
the
the
Firebase
firebase
console.
console
This
this
is
is
a
a
great
great
option
option
if
if
you
you
have
have
an
an
existing
existing
website
website
and
and
you
you
want
want
some
some
performance
performance
reporting,
reporting
but
but
you
you
don't
don't
wanna
wanna
use
use
any
any
other
other
Firebase
firebase
products.
products
The
the
next
next
option
option
is
is
to
to
use
use
it
it
in
in
combination
combination
with
with
Firebase
firebase
Hosting.
hosting
If
if
you're
you're
already
already
using
using
Firebase
firebase
Hosting,
hosting
you
you
can
can
use
use
these
these
magic
magic
script
script
tags
tags
to
to
easily
easily
import
import
it
it
into
into
your
your
project.
project
But
but
I
i
think
think
the
the
vast
vast
majority
majority
of
of
people
people
will
will
use
use
it
it
in
in
combination
combination
with
with
a
a
module
module
bundler
bundler
like
like
Webpack.
webpack
That's
that's
how
how
we're
we're
going
going
to
to
use
use
it
it
today
today
in
in
the
the
context
context
of
of
an
an
Angular
angular
application,
application
but
but
the
the
process
process
is
is
very
very
similar
similar
for
for
all
all
JavaScript
javascript
frameworks.
frameworks
The
the
first
first
thing
thing
you
you
wanna
wanna
do
do
is
is
install
install
the
the
latest
latest
version
version
of
of
Firebase,
firebase
making
making
sure
sure
that
that
version
version
6.0
6.0
or
or
greater.
greater
Now
now
most
most
of
of
the
the
code
code
that
that
we'll
we'll
look
look
at
at
is
is
relevant
relevant
to
to
any
any
JavaScript
javascript
app,
app
but
but
at
at
the
the
end
end
of
of
the
the
video,
video
we're
we're
going
going
to
to
look
look
at
at
some
some
really
really
cool
cool
new
new
bleeding
bleeding
edge
edge
stuff
stuff
from
from
the
the
AngularFire
angularfire
library.
library
At
at
the
the
time
time
of
of
this
this
video,
video
you
you
can
can
use
use
it
it
by
by
installing
installing
AngularFire
angularfire
with
with
the
the
next
next
tag.
tag
From
from
there,
there
you'll
you'll
want
want
to
to
go
go
to
to
the
the
Firebase
firebase
console
console
and
and
go
go
to
to
the
the
settings
settings
tab,
tab
And
and
you'll
you'll
see
see
an
an
option
option
to
to
now
now
add
add
your
your
app
app
as
as
a
a
web
web
app.
app
You'll
you'll
wanna
wanna
do
do
this
this
even
even
if
if
you
you
have
have
an
an
existing
existing
app
app
because
because
there's
there's
a
a
new
new
property
property
that
that
you
you
need
need
to
to
have
have
in
in
your
your
Firebase
firebase
config
config
in
in
order
order
to
to
work
work
with
with
Firebase
firebase
Performance.
performance
Populate,
populate
so
so
don't
don't
be
be
worried
worried
if
if
you
you
don't
don't
see
see
any
any
data
data
after
after
deploying
deploying
initially.
initially
I
i
was
was
lucky
lucky
enough
enough
to
to
be
be
able
able
to
to
test
test
Firebase
firebase
Performance
performance
before
before
it
it
was
was
officially
officially
released,
released
so
so
I
i
have
have
quite
quite
a
a
bit
bit
of
of
data
data
built
built
up
up
here
here
for
for
Fireship
fireship
IO.
io
Actual
actual
data
data
that
that
you
you
see
see
on
on
the
the
dashboard
dashboard
is
is
similar
similar
to
to
what
what
you
you
would
would
see
see
on
on
a
a
Lighthouse
lighthouse
performance
performance
score
score
that
that
you
you
run
run
locally
locally
in
in
your
your
Chrome
chrome
browser,
browser
except
except
this
this
data
data
is
is
being
being
collected
collected
and
and
across
across
all
all
your
your
users
users
in
in
the
the
real
real
world.
world
On
on
the
the
dashboard,
dashboard
I
i
can
can
see
see
the
the
aggregate
aggregate
performance
performance
for
for
things
things
like
like
First
first
Paint,
paint
First
first
Contentful
contentful
Paint,
paint
DOM
dom
Interactive,
interactive
how
how
they're
they're
distributed
distributed
across
across
the
the
entire
entire
user
user
base.
base
By
by
looking
looking
at
at
this
this
distribution,
distribution
I
i
can
can
see
see
that
that
the
the
majority
majority
of
of
my
my
users
users
are
are
seeing
seeing
page
page
load
load
times
times
in
in
less
less
than
than
2
2
seconds,
seconds
so
so
that's
that's
pretty
pretty
good.
good
But
but
I'm
i'm
always
always
pushing
pushing
new
new
code
code
to
to
my
my
web
web
app.
app
So
so
what
what
if
if
I
i
do
do
something
something
that
that
makes
makes
the
the
performance
performance
decline?
decline
I
i
can
can
easily
easily
determine
determine
if
if
my
my
performance
performance
is
is
getting
getting
better
better
or
or
worse
worse
by
by
looking
looking
at
at
the
the
trend
trend
over
over
time.
time
Ideally,
ideally
you
you
wanna
wanna
see
see
this
this
chart
chart
have
have
a
a
negative
negative
slope
slope
because
because
faster
faster
is
is
always
always
better.
better
And
and
on
on
top
top
of
of
that,
that
we
we
can
can
filter
filter
this
this
data
data
by
by
region,
region
by
by
device,
device
and
and
even
even
whether
whether
or
or
not
not
the
the
user
user
has
has
a
a
service
service
worker
worker
installed.
installed
This
this
allows
allows
us
us
to
to
figure
figure
out
out
what
what
users
users
are
are
being
being
affected
affected
by
by
a
a
performance
performance
bottleneck
bottleneck
and
and
what
what
the
the
root
root
cause
cause
might
might
be.
be
In
in
addition
addition
to
to
page
page
loads,
loads
it
it
will
will
also
also
keep
keep
track
track
of
of
HTTP
http
calls
calls
over
over
the
the
network.
network
If
if
you
you
have
have
some
some
sort
sort
of
of
async
async
activity
activity
that's
that's
causing
causing
a
a
performance
performance
bottleneck,
bottleneck
you'll
you'll
be
be
able
able
to
to
find
find
it
it
here.
here
Now
now
everything
everything
I've
i've
showed
showed
you
you
so
so
far
far
will
will
just
just
work
work
out
out
of
of
the
the
box
box
when
when
you
you
include
include
Firebase
firebase
Performance
performance
in
in
your
your
app.
app
But
but
you
you
can
can
also
also
write
write
your
your
own
own
custom
custom
traces
traces
within
within
your
your
app's
app's
code,
code
and
and
that
that
opens
opens
the
the
door
door
to
to
all
all
kinds
kinds
of
of
cool
cool
possibilities.
possibilities
For
for
example,
example
I
i
have
have
a
a
custom
custom
trace
trace
here
here
on
on
a
a
login
login
model
model
that
that
users
users
click
click
to
to
log
log
in
in
to
to
the
the
app.
app
And
and
this
this
allows
allows
me
me
to
to
see
see
exactly
exactly
how
how
long
long
it
it
takes
takes
a
a
user
user
on
on
average
average
to
to
log
log
in
in
to
to
the
the
app.
app
But
but
one
one
thing
thing
I
i
do
do
wanna
wanna
point
point
out
out
at
at
this
this
point
point
is
is
that
that
you
you
should
should
never
never
use
use
any
any
personally
personally
identifiable
identifiable
information
information
inside
inside
of
of
a
a
trace,
trace
things
things
like
like
email
email
addresses
addresses
or
or
phone
phone
numbers.
numbers
Not
not
only
only
is
is
that
that
a
a
bad
bad
practice
practice
for
for
user
user
privacy,
privacy
but
but
Google
google
will
will
for
for
automatic
automatic
deletion
deletion
anyway.
anyway
We'll
we'll
be
be
writing
writing
our
our
own
own
custom
custom
traces
traces
in
in
just
just
a
a
minute.
minute
And
and
once
once
you've
you've
collected
collected
some
some
data,
data
you'll
you'll
have
have
a
a
screen
screen
that
that
looks
looks
like
like
this
this
that
that
you
you
can
can
filter
filter
by
by
different
different
attributes.
attributes
You
you
can
can
even
even
create
create
your
your
own
own
custom
custom
attributes
attributes
in
in
your
your
code,
code
and
and
you
you
can
can
also
also
set
set
up
up
your
your
own
own
custom
custom
thresholds
thresholds
to
to
signify
signify
a
a
certain
certain
point
point
that
that
a
a
metric
metric
would
would
be
be
considered
considered
poor
poor
performance.
performance
My
my
case,
case
I've
i've
already
already
gotten
gotten
valuable
valuable
insight
insight
from
from
this
this
trace
trace
because
because
I
i
found
found
out
out
that
that
users
users
on
on
Safari
safari
take
take
way
way
longer
longer
to
to
log
log
in
in
than
than
users
users
on
on
Chrome
chrome
or
or
Firefox.
firefox
The
the
reason
reason
I
i
detected
detected
that
that
is
is
because
because
Firebase
firebase
is
is
smart
smart
enough
enough
to
to
warn
warn
me
me
about
about
it
it
with
with
this
this
little
little
orange
orange
icon
icon
here.
here
So
so
it'll
it'll
automatically
automatically
tell
tell
you
you
when
when
a
a
certain
certain
segment
segment
seems
seems
out
out
of
of
the
the
ordinary,
ordinary
And
and
that's
that's
all
all
based
based
on
on
real
real
world
world
data
data
from
from
Fireship.
fireship
Let's
let's
go
go
ahead
ahead
and
and
jump
jump
into
into
the
the
code
code
and
and
write
write
our
our
own
own
custom
custom
traces.
traces
Back
back
in
in
our
our
Angular
angular
app,
app
we'll
we'll
go
go
into
into
the
the
app
app
module
module
and
and
then
then
set
set
up
up
the
the
Firebase
firebase
config
config
making
making
sure
sure
that
that
it
it
contains
contains
the
the
app
app
ID.
id
I've
i've
already
already
included
included
Firestore
firestore
and
and
AngularFire
angularfire
auth
auth
in
in
here
here
and
and
then
then
we
we
can
can
go
go
ahead
ahead
and
and
include
include
the
the
AngularFire
angularfire
performance
performance
module.
module
In
in
the
the
component,
component
we'll
we'll
go
go
ahead
ahead
and
and
import
import
Firebase
firebase
from
from
Firebase
firebase
app
app
and
and
then
then
initialize
initialize
Firebase
firebase
performance.
performance
On
on
iOS
ios
and
and
Android,
android
FirePerf
fireperf
will
will
automatically
automatically
track
track
how
how
long
long
a
a
screen
screen
has
has
been
been
opened,
opened
but
but
we
we
can
can
also
also
do
do
that
that
in
in
a
a
single
single
page
page
application
application
by
by
using
using
the
the
life
life
cycle
cycle
hooks
hooks
in
in
the
the
framework.
framework
Now
now
the
the
trace
trace
itself,
itself
you
you
can
can
think
think
of
of
like
like
a
a
stopwatch.
stopwatch
Time,
time
but
but
we
we
can
can
also
also
add
add
custom
custom
attributes
attributes
and
and
metrics
metrics
in
in
between
between
as
as
we'll
we'll
see
see
later.
later
So
so
in
in
this
this
case
case
here,
here
we'll
we'll
start
start
our
our
trace
trace
during
during
ng
ng
on
on
init,
init
and
and
then
then
we'll
we'll
end
end
the
the
trace
trace
during
during
ng
ng
on
on
destroy.
destroy
Now
now
we'll
we'll
have
have
an
an
understanding
understanding
of
of
exactly
exactly
how
how
much
much
time
time
our
our
users
users
are
are
spending
spending
on
on
the
the
login
login
page.
page
So
so
that
that
represents
represents
your
your
most
most
simple
simple
use
use
case
case
for
for
a
a
custom
custom
trace,
trace
but
but
there's
there's
a
a
whole
whole
lot
lot
we
we
can
can
do
do
in
in
between
between
the
the
start
start
and
and
stop
stop
point.
point
This
this
is
is
the
the
function
function
that
that
we
we
would
would
call
call
after
after
the
the
user
user
submits
submits
a
a
form
form
with
with
their
their
email
email
and
and
password.
password
The
the
first
first
thing
thing
we'll
we'll
do
do
is
is
create
create
an
an
instance
instance
of
of
a
a
trace
trace
called
called
user
user
login
login
and
and
start
start
it.
it
Then
then
stop
stop
it
it
at
at
the
the
end
end
of
of
the
the
function
function
and
and
add
add
a
a
try
try
catch
catch
block
block
in
in
between
between
the
the
start
start
and
and
stop
stop
point.
point
What
what
we'll
we'll
try
try
to
to
do
do
is
is
log
log
in
in
the
the
user
user
with
with
email
email
and
and
password,
password
strings
strings
that
that
allow
allow
you
you
to
to
segment
segment
your
your
data
data
in
in
different
different
ways.
ways
Setting
setting
really
really
good
good
attributes
attributes
will
will
result
result
in
in
really
really
good
good
performance
performance
reporting
reporting
on
on
the
the
Firebase
firebase
console.
console
Let's
let's
imagine
imagine
we
we
have
have
a
a
function
function
here
here
that
that
loads
loads
user
user
data
data
that
that
makes
makes
multiple
multiple
queries
queries
to
to
different
different
Firestore
firestore
collections,
collections
and
and
we
we
wanna
wanna
know
know
how
how
long
long
that
that
query
query
takes
takes
and
and
also
also
how
how
many
many
documents
documents
are
are
read
read
in
in
the
the
process.
process
Read
read
is
is
complete,
complete
we'll
we'll
call
call
trace
trace
increment
increment
metric,
metric
and
and
we'll
we'll
set
set
a
a
metric
metric
as
as
total
total
size.
size
That
that
will
will
keep
keep
track
track
of
of
the
the
total
total
size
size
of
of
all
all
reads
reads
that
that
we
we
perform
perform
in
in
this
this
function.
function
We
we
can
can
also
also
create
create
another
another
metric
metric
that's
that's
just
just
based
based
on
on
the
the
size
size
of
of
the
the
items
items
collection
collection
only.
only
If
if
we
we
wanna
wanna
do
do
that,
that
we
we
can
can
call
call
trace
trace
put
put
metric,
metric
And
and
this
this
will
will
add
add
a
a
metric
metric
to
to
this
this
trace
trace
that
that
doesn't
doesn't
really
really
change
change
over
over
the
the
life
life
cycle
cycle
of
of
the
the
trace.
trace
So
so
increment
increment
metric
metric
is
is
really
really
useful
useful
when
when
you
you
have
have
data
data
that
that
might
might
change,
change
like
like
incrementing
incrementing
the
the
score
score
on
on
a
a
game
game
or
or
something
something
like
like
that.
that
Our
our
case
case
here,
here
we'll
we'll
read
read
from
from
another
another
collection
collection
called
called
things.
things
And
and
then
then
this
this
time,
time
we'll
we'll
use
use
the
the
total
total
size
size
of
of
that
that
collection
collection
to
to
increment
increment
our
our
total
total
size
size
metric.
metric
So
so
if
if
there
there
were
were
10
10
documents
documents
in
in
the
the
first
first
query
query
and
and
then
then
15
15
documents
documents
in
in
the
the
second
second
query,
query
our
our
total
total
value
value
would
would
be
be
25
25
for
for
this
this
particular
particular
trace.
trace
Now
now
I
i
like
like
this
this
code
code
for
for
an
an
async
async
function,
function
but
but
if
if
this
this
were
were
an
an
observable,
observable
it
it
means
means
we
we
would
would
have
have
to
to
pipe
pipe
in
in
the
the
tap
tap
operator
operator
all
all
over
over
the
the
place
place
to
to
start
start
and
and
stop
stop
the
the
trace.
trace
Thankfully,
thankfully
James
james
Daniels,
daniels
who's
who's
the
the
lead
lead
maintainer
maintainer
of
of
AngularFire,
angularfire
has
has
put
put
in
in
some
some
work
work
to
to
make
make
this
this
a
a
lot
lot
easier,
easier
especially
especially
for
for
Angular
angular
RxJS
rxjs
developers.
developers
And
and
then
then
give
give
it
it
a
a
name,
name
and
and
that
that
will
will
automatically
automatically
give
give
you
you
the
the
latency
latency
of
of
a
a
collection
collection
read.
read
You
you
don't
don't
even
even
need
need
to
to
call
call
start
start
or
or
stop
stop
because
because
it
it
automatically
automatically
knows
knows
to
to
do
do
that
that
when
when
you
you
subscribe
subscribe
to
to
the
the
observable.
observable
In
in
this
this
case,
case
it
it
will
will
automatically
automatically
stop
stop
the
the
trace
trace
when
when
the
the
observable
observable
emits
emits
data,
data
but
but
there's
there's
also
also
several
several
more
more
operators
operators
in
in
there
there
that
that
allow
allow
you
you
to
to
handle
handle
more
more
advanced
advanced
use
use
cases.
cases
My
my
favorite
favorite
is
is
trace
trace
and
and
till.
till
This
this
allows
allows
you
you
to
to
set
set
up
up
a
a
trace
trace
but
but
only
only
stop
stop
the
the
trace
trace
when
when
a
a
certain
certain
condition
condition
has
has
been
been
met.
met
For
for
example,
example
say
say
you
you
have
have
a
a
game
game
running
running
and
and
then
then
you're
you're
making
making
multiple
multiple
updates
updates
to
to
that
that
document
document
based
based
on
on
the
the
state
state
of
of
the
the
game.
game
Once
once
the
the
game
game
over
over
property
property
is
is
set
set
to
to
true,
true
then
then
it
it
ends
ends
the
the
trace
trace
here.
here
And
and
then
then
there's
there's
also
also
a
a
third
third
option
option
for
for
trace
trace
options
options
that
that
allow
allow
you
you
to
to
do
do
things
things
like
like
set
set
attributes
attributes
and
and
metrics
metrics
like
like
we
we
did
did
before.
before
Overall,
overall
this
this
is
is
a
a
very
very
promising
promising
update
update
for
for
AngularFire,
angularfire
but
but
more
more
importantly,
importantly
Firebase
firebase
Performance
performance
is
is
pretty
pretty
much
much
a
a
no
no
brainer
brainer
for
for
every
every
app.
app
It's
it's
free,
free
easy
easy
to
to
set
set
up,
up
Lightweight
lightweight
and
and
it
it
will
will
help
help
you
you
catch
catch
problems
problems
that
that
you
you
didn't
didn't
even
even
know
know
existed.
existed
I'm
i'm
gonna
gonna
go
go
ahead
ahead
and
and
wrap
wrap
things
things
up
up
there.
there
If
if
this
this
video
video
helped
helped
you,
you
please
please
like
like
and
and
subscribe.
subscribe
And
and
if
if
you
you
want
want
even
even
more
more
content,
content
consider
consider
becoming
becoming
a
a
pro
pro
member
member
at
at
FireShip
fireship
IO.
io
And
and
don't
don't
forget
forget
to
to
take
take
the
the
quiz
quiz
on
on
the
the
FireShip
fireship
mobile
mobile
app
app
to
to
see
see
if
if
you
you
learned
learned
anything.
anything
Thanks
thanks
for
for
watching,
watching
and
and
I
i
will
will
talk
talk
to
to
you
you
soon.
soon
success
The speaker discusses usingdial Performance, a web performance monitoring tool, in combination with Angular Hosting and provides information on how to use it in the context of an Angular application. They also explain how to use the tool in the context of an Angular application and suggest setting up custom attributes and metrics. The use of a custom trace in Angular app can help identify outages and provide insight into user behavior, and the code is free and easy to set up.
Firebase Performance on the Web QuickStart
There were a whole bunch of awesome announcements at Google IO 2019, but my personal favorite is definitely Firebase Performance for the web. Well, today, we're expanding performance monitoring to the web. This is a tool that can benefit any website that cares about performance, even if that site isn't already using other Firebase products. By simply adding a script tag to your site or including Firebase Perf in your JavaScript bundle, you'll get insights about how your web app performs out in the real world in terms of initial page load performance and HTTP calls over the network. In today's video, we'll look at the basics of Firebase Performance and take things a few steps further by implementing our own custom traces. And we'll look at some awesome upcoming features in AngularFire to integrate with Angular and RxJS. If you're new here, like and subscribe and make sure to download the mobile app on iOS Android to take the Firebase Performance quiz after you're done watching this video. Now there's a few different ways we can use Firebase Performance. The most basic way is to use it as just standalone tool in an existing website. This approach will insert a lightweight script into your HTML document, and then you'll automatically get all kinds of performance reporting on the Firebase console. This is a great option if you have an existing website and you want some performance reporting, but you don't wanna use any other Firebase products. The next option is to use it in combination with Firebase Hosting. If you're already using Firebase Hosting, you can use these magic script tags to easily import it into your project. But I think the vast majority of people will use it in combination with a module bundler like Webpack. That's how we're going to use it today in the context of an Angular application, but the process is very similar for all JavaScript frameworks. The first thing you wanna do is install the latest version of Firebase, making sure that version 6.0 or greater. Now most of the code that we'll look at is relevant to any JavaScript app, but at the end of the video, we're going to look at some really cool new bleeding edge stuff from the AngularFire library. At the time of this video, you can use it by installing AngularFire with the next tag. From there, you'll want to go to the Firebase console and go to the settings tab, And you'll see an option to now add your app as a web app. You'll wanna do this even if you have an existing app because there's a new property that you need to have in your Firebase config in order to work with Firebase Performance. Populate, so don't be worried if you don't see any data after deploying initially. I was lucky enough to be able to test Firebase Performance before it was officially released, so I have quite a bit of data built up here for Fireship IO. Actual data that you see on the dashboard is similar to what you would see on a Lighthouse performance score that you run locally in your Chrome browser, except this data is being collected and across all your users in the real world. On the dashboard, I can see the aggregate performance for things like First Paint, First Contentful Paint, DOM Interactive, how they're distributed across the entire user base. By looking at this distribution, I can see that the majority of my users are seeing page load times in less than 2 seconds, so that's pretty good. But I'm always pushing new code to my web app. So what if I do something that makes the performance decline? I can easily determine if my performance is getting better or worse by looking at the trend over time. Ideally, you wanna see this chart have a negative slope because faster is always better. And on top of that, we can filter this data by region, by device, and even whether or not the user has a service worker installed. This allows us to figure out what users are being affected by a performance bottleneck and what the root cause might be. In addition to page loads, it will also keep track of HTTP calls over the network. If you have some sort of async activity that's causing a performance bottleneck, you'll be able to find it here. Now everything I've showed you so far will just work out of the box when you include Firebase Performance in your app. But you can also write your own custom traces within your app's code, and that opens the door to all kinds of cool possibilities. For example, I have a custom trace here on a login model that users click to log in to the app. And this allows me to see exactly how long it takes a user on average to log in to the app. But one thing I do wanna point out at this point is that you should never use any personally identifiable information inside of a trace, things like email addresses or phone numbers. Not only is that a bad practice for user privacy, but Google will for automatic deletion anyway. We'll be writing our own custom traces in just a minute. And once you've collected some data, you'll have a screen that looks like this that you can filter by different attributes. You can even create your own custom attributes in your code, and you can also set up your own custom thresholds to signify a certain point that a metric would be considered poor performance. My case, I've already gotten valuable insight from this trace because I found out that users on Safari take way longer to log in than users on Chrome or Firefox. The reason I detected that is because Firebase is smart enough to warn me about it with this little orange icon here. So it'll automatically tell you when a certain segment seems out of the ordinary, And that's all based on real world data from Fireship. Let's go ahead and jump into the code and write our own custom traces. Back in our Angular app, we'll go into the app module and then set up the Firebase config making sure that it contains the app ID. I've already included Firestore and AngularFire auth in here and then we can go ahead and include the AngularFire performance module. In the component, we'll go ahead and import Firebase from Firebase app and then initialize Firebase performance. On iOS and Android, FirePerf will automatically track how long a screen has been opened, but we can also do that in a single page application by using the life cycle hooks in the framework. Now the trace itself, you can think of like a stopwatch. Time, but we can also add custom attributes and metrics in between as we'll see later. So in this case here, we'll start our trace during ng on init, and then we'll end the trace during ng on destroy. Now we'll have an understanding of exactly how much time our users are spending on the login page. So that represents your most simple use case for a custom trace, but there's a whole lot we can do in between the start and stop point. This is the function that we would call after the user submits a form with their email and password. The first thing we'll do is create an instance of a trace called user login and start it. Then stop it at the end of the function and add a try catch block in between the start and stop point. What we'll try to do is log in the user with email and password, strings that allow you to segment your data in different ways. Setting really good attributes will result in really good performance reporting on the Firebase console. Let's imagine we have a function here that loads user data that makes multiple queries to different Firestore collections, and we wanna know how long that query takes and also how many documents are read in the process. Read is complete, we'll call trace increment metric, and we'll set a metric as total size. That will keep track of the total size of all reads that we perform in this function. We can also create another metric that's just based on the size of the items collection only. If we wanna do that, we can call trace put metric, And this will add a metric to this trace that doesn't really change over the life cycle of the trace. So increment metric is really useful when you have data that might change, like incrementing the score on a game or something like that. Our case here, we'll read from another collection called things. And then this time, we'll use the total size of that collection to increment our total size metric. So if there were 10 documents in the first query and then 15 documents in the second query, our total value would be 25 for this particular trace. Now I like this code for an async function, but if this were an observable, it means we would have to pipe in the tap operator all over the place to start and stop the trace. Thankfully, James Daniels, who's the lead maintainer of AngularFire, has put in some work to make this a lot easier, especially for Angular RxJS developers. And then give it a name, and that will automatically give you the latency of a collection read. You don't even need to call start or stop because it automatically knows to do that when you subscribe to the observable. In this case, it will automatically stop the trace when the observable emits data, but there's also several more operators in there that allow you to handle more advanced use cases. My favorite is trace and till. This allows you to set up a trace but only stop the trace when a certain condition has been met. For example, say you have a game running and then you're making multiple updates to that document based on the state of the game. Once the game over property is set to true, then it ends the trace here. And then there's also a third option for trace options that allow you to do things like set attributes and metrics like we did before. Overall, this is a very promising update for AngularFire, but more importantly, Firebase Performance is pretty much a no brainer for every app. It's free, easy to set up, Lightweight and it will help you catch problems that you didn't even know existed. I'm gonna go ahead and wrap things up there. If this video helped you, please like and subscribe. And if you want even more content, consider becoming a pro member at FireShip IO. And don't forget to take the quiz on the FireShip mobile app to see if you learned anything. Thanks for watching, and I will talk to you soon.
The speaker discusses usingdial Performance, a web performance monitoring tool, in combination with Angular Hosting and provides information on how to use it in the context of an Angular application. They also explain how to use the tool in the context of an Angular application and suggest setting up custom attributes and metrics. The use of a custom trace in Angular app can help identify outages and provide insight into user behavior, and the code is free and easy to set up.

        [INST]
        You are youtuber called Fireship you make engaging high-intensity and entertaining coding tutorials and tech news. 
        you covers a wide range of topics relevant to programmers, aiming to help them learn and improve their skills quickly.
        
        Given the title of the video : Firebase Performance on the Web QuickStart 
        and a small summary : The speaker discusses usingdial Performance, a web performance monitoring tool, in combination with Angular Hosting and provides information on how to use it in the context of an Angular application. They also explain how to use the tool in the context of an Angular application and suggest setting up custom attributes and metrics. The use of a custom trace in Angular app can help identify outages and provide insight into user behavior, and the code is free and easy to set up.
        [/INST]
        
        Generate the video : There were a whole bunch of awesome announcements at Google IO 2019, but my personal favorite is definitely Firebase Performance for the web. Well, today, we're expanding performance monitoring to the web. This is a tool that can benefit any website that cares about performance, even if that site isn't already using other Firebase products. By simply adding a script tag to your site or including Firebase Perf in your JavaScript bundle, you'll get insights about how your web app performs out in the real world in terms of initial page load performance and HTTP calls over the network. In today's video, we'll look at the basics of Firebase Performance and take things a few steps further by implementing our own custom traces. And we'll look at some awesome upcoming features in AngularFire to integrate with Angular and RxJS. If you're new here, like and subscribe and make sure to download the mobile app on iOS Android to take the Firebase Performance quiz after you're done watching this video. Now there's a few different ways we can use Firebase Performance. The most basic way is to use it as just standalone tool in an existing website. This approach will insert a lightweight script into your HTML document, and then you'll automatically get all kinds of performance reporting on the Firebase console. This is a great option if you have an existing website and you want some performance reporting, but you don't wanna use any other Firebase products. The next option is to use it in combination with Firebase Hosting. If you're already using Firebase Hosting, you can use these magic script tags to easily import it into your project. But I think the vast majority of people will use it in combination with a module bundler like Webpack. That's how we're going to use it today in the context of an Angular application, but the process is very similar for all JavaScript frameworks. The first thing you wanna do is install the latest version of Firebase, making sure that version 6.0 or greater. Now most of the code that we'll look at is relevant to any JavaScript app, but at the end of the video, we're going to look at some really cool new bleeding edge stuff from the AngularFire library. At the time of this video, you can use it by installing AngularFire with the next tag. From there, you'll want to go to the Firebase console and go to the settings tab, And you'll see an option to now add your app as a web app. You'll wanna do this even if you have an existing app because there's a new property that you need to have in your Firebase config in order to work with Firebase Performance. Populate, so don't be worried if you don't see any data after deploying initially. I was lucky enough to be able to test Firebase Performance before it was officially released, so I have quite a bit of data built up here for Fireship IO. Actual data that you see on the dashboard is similar to what you would see on a Lighthouse performance score that you run locally in your Chrome browser, except this data is being collected and across all your users in the real world. On the dashboard, I can see the aggregate performance for things like First Paint, First Contentful Paint, DOM Interactive, how they're distributed across the entire user base. By looking at this distribution, I can see that the majority of my users are seeing page load times in less than 2 seconds, so that's pretty good. But I'm always pushing new code to my web app. So what if I do something that makes the performance decline? I can easily determine if my performance is getting better or worse by looking at the trend over time. Ideally, you wanna see this chart have a negative slope because faster is always better. And on top of that, we can filter this data by region, by device, and even whether or not the user has a service worker installed. This allows us to figure out what users are being affected by a performance bottleneck and what the root cause might be. In addition to page loads, it will also keep track of HTTP calls over the network. If you have some sort of async activity that's causing a performance bottleneck, you'll be able to find it here. Now everything I've showed you so far will just work out of the box when you include Firebase Performance in your app. But you can also write your own custom traces within your app's code, and that opens the door to all kinds of cool possibilities. For example, I have a custom trace here on a login model that users click to log in to the app. And this allows me to see exactly how long it takes a user on average to log in to the app. But one thing I do wanna point out at this point is that you should never use any personally identifiable information inside of a trace, things like email addresses or phone numbers. Not only is that a bad practice for user privacy, but Google will for automatic deletion anyway. We'll be writing our own custom traces in just a minute. And once you've collected some data, you'll have a screen that looks like this that you can filter by different attributes. You can even create your own custom attributes in your code, and you can also set up your own custom thresholds to signify a certain point that a metric would be considered poor performance. My case, I've already gotten valuable insight from this trace because I found out that users on Safari take way longer to log in than users on Chrome or Firefox. The reason I detected that is because Firebase is smart enough to warn me about it with this little orange icon here. So it'll automatically tell you when a certain segment seems out of the ordinary, And that's all based on real world data from Fireship. Let's go ahead and jump into the code and write our own custom traces. Back in our Angular app, we'll go into the app module and then set up the Firebase config making sure that it contains the app ID. I've already included Firestore and AngularFire auth in here and then we can go ahead and include the AngularFire performance module. In the component, we'll go ahead and import Firebase from Firebase app and then initialize Firebase performance. On iOS and Android, FirePerf will automatically track how long a screen has been opened, but we can also do that in a single page application by using the life cycle hooks in the framework. Now the trace itself, you can think of like a stopwatch. Time, but we can also add custom attributes and metrics in between as we'll see later. So in this case here, we'll start our trace during ng on init, and then we'll end the trace during ng on destroy. Now we'll have an understanding of exactly how much time our users are spending on the login page. So that represents your most simple use case for a custom trace, but there's a whole lot we can do in between the start and stop point. This is the function that we would call after the user submits a form with their email and password. The first thing we'll do is create an instance of a trace called user login and start it. Then stop it at the end of the function and add a try catch block in between the start and stop point. What we'll try to do is log in the user with email and password, strings that allow you to segment your data in different ways. Setting really good attributes will result in really good performance reporting on the Firebase console. Let's imagine we have a function here that loads user data that makes multiple queries to different Firestore collections, and we wanna know how long that query takes and also how many documents are read in the process. Read is complete, we'll call trace increment metric, and we'll set a metric as total size. That will keep track of the total size of all reads that we perform in this function. We can also create another metric that's just based on the size of the items collection only. If we wanna do that, we can call trace put metric, And this will add a metric to this trace that doesn't really change over the life cycle of the trace. So increment metric is really useful when you have data that might change, like incrementing the score on a game or something like that. Our case here, we'll read from another collection called things. And then this time, we'll use the total size of that collection to increment our total size metric. So if there were 10 documents in the first query and then 15 documents in the second query, our total value would be 25 for this particular trace. Now I like this code for an async function, but if this were an observable, it means we would have to pipe in the tap operator all over the place to start and stop the trace. Thankfully, James Daniels, who's the lead maintainer of AngularFire, has put in some work to make this a lot easier, especially for Angular RxJS developers. And then give it a name, and that will automatically give you the latency of a collection read. You don't even need to call start or stop because it automatically knows to do that when you subscribe to the observable. In this case, it will automatically stop the trace when the observable emits data, but there's also several more operators in there that allow you to handle more advanced use cases. My favorite is trace and till. This allows you to set up a trace but only stop the trace when a certain condition has been met. For example, say you have a game running and then you're making multiple updates to that document based on the state of the game. Once the game over property is set to true, then it ends the trace here. And then there's also a third option for trace options that allow you to do things like set attributes and metrics like we did before. Overall, this is a very promising update for AngularFire, but more importantly, Firebase Performance is pretty much a no brainer for every app. It's free, easy to set up, Lightweight and it will help you catch problems that you didn't even know existed. I'm gonna go ahead and wrap things up there. If this video helped you, please like and subscribe. And if you want even more content, consider becoming a pro member at FireShip IO. And don't forget to take the quiz on the FireShip mobile app to see if you learned anything. Thanks for watching, and I will talk to you soon.
        