Skip to content

Intro To Performance Analytics with Firebase

The Firebase suite includes multiple products, about which you can read more here. In this article, however, I'm going to talk about the Performance Monitoring product.

I'm going to show you how to use it in an Angular app, but the process for React, VueJS, etc, is very very similar.

What Is Performance Monitoring in Firebase?

Thanks to this product, you can observe the performance of your app. By using the product, you see the areas for improvement in your code. This product can help you avoid crashes by increasing your code quality.

Features Of Performance Monitoring

  • Customize monitoring for your app
  • Automatically measure app startup time, HTTP/S network requests, and more
  • Gain insight into situations where app performance could be improved

Let's get started

Note: I'm assuming you have a Firebase account, and any project there that can be used throughout this article

  1. On the left navbar, inside of a Firebase console, you will see Performance. Click it. This is where your data will be populated after 12-24hrs of monitoring.
Screen Shot 2019-12-17 at 12.26.36 PM
  1. Now, go to project settings: Screen Shot 2019-12-17 at 1.44.49 PM
Screen Shot 2019-12-17 at 1.46.11 PM
  1. Then, scroll all the way down, and copy/paste the JSON with all your project settings in a safe place. If you don't see those settings as shown on the screenshot, you might need to register a new web-app for the current project (instructions on how to do this are given on the same page in Project settings > General).
Screen Shot 2019-12-17 at 1.45.33 PM
  1. Navigate to your project directory in the command line, and run:
npm install firebase @angular/fire --save

5)Import the Firebase modules in your app.module.ts

import { AngularFireModule } from "@angular/fire";
import { AngularFirePerformanceModule } from "@angular/fire/performance";
  1. Inside of your app.module.ts, make sure you add the above modules into the imports array as follows:
imports: [
    ...
    // These are settings that you copied in step #3
    AngularFireModule.initializeApp({
      apiKey: "...",
      authDomain: "...",
      databaseURL: "...",
      projectId: "...",
      storageBucket: "...",
      messagingSenderId: "...",
      appId: "..."
    }),
    AngularFirePerformanceModule,
    ...
]
  1. Now, in your service, or wherever you are reading the data from Firebase, you can add a trace to trace the time it takes to load the data.
...
import { AngularFirestore } from "@angular/fire/firestore";
import { AngularFirePerformance } from "@angular/fire/performance";
...
constructor(
    private perf: AngularFirePerformance,
    private firestore: AngularFirestore
  ) {}
firestorePlacesCollection = this.firestore.collection("places");

  //READ
  places$ = this.firestorePlacesCollection.snapshotChanges().pipe(
    // HERE IS THE TRACE
    this.perf.trace("placesQuery"),
    map(actions => {
      return actions.map(p => {
        const place = p.payload.doc;
        const id = place.id;
        return { id, ...place.data() } as Place;
      });
    })
  );

Note: places is the name of my collection inside of Firebase, and placesQuery is the name I gave to my trace. You can name it however you want.

__Now your app is ready to start getting tracked by Firebase's performance tooling. __

Remember You can always write custom traces whether you are using Angular, React, or plain Vanilla JS.

Time to view our App Performance

Note: In order to see your app performance, you need to deploy your app and give Firebase approximately 24 hours to collect some data.

  1. Go back to Firebase-> Performance Tab, you should see something like this: Screen Shot 2020-01-02 at 10.02.27 AM

You will see this dashboard showing some basic data per country, and per enviroment you have used your app.

  1. Now, click on View Traces, and click on the enviroment you want to be the traces. You will see a metrics dashboard Screen Shot 2020-01-02 at 10.08.32 AM

If you click on View More, you will see more information about that specific metric. Check it out!

  1. Now go back to the previous page and click on device tab. Then click on the trace you created to view the performance data. In my case, my custom trace is placeQuery.
Screen Shot 2020-01-02 at 10.10.40 AM
  1. After clicking on the custom trace, you will see a dashboard that is similar to the one in the picture below. Click on View More.
Screen Shot 2020-01-02 at 10.13.13 AM
  1. After clicking on view more, you will see some specific traces realted to your custom trace. Screen Shot 2020-01-02 at 10.03.37 AM

As you can see, you have the option to see the metrics depending on different factors like the browser, country, etc.

  1. You can also set parameters to see when the performance on the page is below the average by setting a threshold.
Screen Shot 2020-01-02 at 2.10.03 PM
Screen Shot 2020-01-02 at 2.11.36 PM

All of these performance metrics will help you understand how your app performs in different conditions to improve the user experience for your customers.

This Dot Labs is a development consultancy that is trusted by top industry companies, including Stripe, Xero, Wikimedia, Docusign, and Twilio. This Dot takes a hands-on approach by providing tailored development strategies to help you approach your most pressing challenges with clarity and confidence. Whether it's bridging the gap between business and technology or modernizing legacy systems, you’ll find a breadth of experience and knowledge you need. Check out how This Dot Labs can empower your tech journey.

You might also like

3 Web Performance Concepts that Will Help Start a Conversation Around Performance cover image

3 Web Performance Concepts that Will Help Start a Conversation Around Performance

In 2021, This Dot Labs released PerfBuddy, the free online platform for testing web and mobile based sites. With the release of this tool, it was our sincere hope to simplify the conversation around web performance, helping team leaders develop easy to understand metrics that they can use to advocate for further investment into their various web technologies. But we also realize that many new to web development, or who work in software but not as developers, might need more clarification on some of the basic key terms to help them engage more actively in conversations surrounding web development. Below, I’ve defined three of the top terms in web performance to help readers better ascertain your site’s performance, and play an active role in refining their technologies to provide the best experience for their customers. First Contentful Paint Time (FCP) FCP__, or __First Contentful Paint Time__, is a critical metric that measures the time that users must wait in order for a page to load its first visible element. For some sites, this could be the entire page. However, for others, the FCP time might measure the seconds between a user navigating to a site, and any responsive element, such as a loading bar, appearing in front of them. This is not a measurement of backend nor even frontend script loading speed, but a metric that affords development teams the ability to infer the quality of their site’s initial UX. According to metrics published by Akamai in 2018, sites are liable to lose nearly half of their visitors if their page takes more than three seconds to load. In fact, just a single second of load time delay can result in a 7% decrease in sales conversions for eCommerce platforms. This is especially true when considering mobile users, whose likelihood of leaving a page increases 90% when made to wait 5 seconds for a page to load And as more eCommerce shoppers turn to using their mobile devices- with 53% of users accessing shopping sites via mobile platforms on 2019’s Cyber Monday, representing a 40% YOY increase- teams need to be acutely aware of their cross platform performance with respect to FCP. Time to First Byte (TTFB) Not to be confused with FCP, TTFB, or Time to First Byte, refers to the amount of time that the browser waits in order to receive initial data from its server. In order for a site to display any information, a browser must make dozens, if not more, data requests. Issues related either to the quality of the host, site functionality, or complexity can all contribute to a site’s latency, or the amount of time it takes for data to be passed between the server and the browser. Of course, reducing site latency will improve user experience by decreasing FCP, and generally increasing browsing speed. However, ensuring low TTFB will also boost your SEO by making your site more quickly crawlable by leading search engines. Page Weight As developers add features and functionality to support more advanced user experience, web pages get heavier. As of 2020, the average desktop webpage weighs 2080 KB, up from an average of 1532 KB in 2017, with the weight of mobile web pages slightly lower, but still seeing a near 40% increase in size when compared to stats from just four years ago. eCommerce websites need to maintain acute awareness of their page weight, and ensure that their latency is not overly impacted by it, due to the tendency for shopping sites to be especially complex, supporting large catalogs of products along with other features to promote customer engagement. And as this era of advanced digital transformation continues to expand, eCommerce sites must develop strategies to meet market expectations for performance without over burdening their sites with heavy plugins and functionalities. Finding Your Path to Performance It starts with equipping yourself with the right tools to test your site’s speed and weight. There are countless platforms used for testing sites, however, there are only a handful that are capable of unlocking the insight that you need to support your most critical websites. Though PerfBuddy is a great place to start in order to identify potential roadblocks, it cannot do the work of actually improving site performance. By leveraging testing platforms such as Lighthouse, and continuously improving your performance metrics with assets such as DevTools, and strategies like Google’s PRPL, eCommerce retailers can ensure that their sites meet user expectations and promote their most critical business objectives. Need help? Contact This Dot Labs to learn more about how developing the tools and strategies to ensure optimal site performance can support scalable growth as you continue refining user experience!...

7 Tips to be a Successful Developer in a Remote Company cover image

7 Tips to be a Successful Developer in a Remote Company

When the pandemic hit in March of 2020, most companies were forced to go remote and millions of workers had to learn how to work from home. Two years later, a lot people now prefer the work from home option, and many job seekers are looking for remote-only companies to work for. For software developers, there are many advantages to working from home and still effectively working as a team to produce high quality results. But how can you be successful in a remote company? In this article, I will provide 7 tips on what it takes to be a successful developer in a remote company. Communication is key It is now more important than ever to communicate effectively with your team. Now that everyone is working from home instead of being in one physical office, you have to be very conscious to reach out to teammates and share your progress on a project. In a physical office, you are surrounded by other co-workers all day, which makes it easier to walk over to someone's office and share what you have been working on. It also makes it easier to have impromptu meetings with other team members throughout the day. But in a remote setting, it is very easy to become isolated and get carried away with work without reaching out to anyone all day. This becomes an issue for your team, because now they are no longer keeping up to date on the latest changes you have been contributing to the project. My tip would be to post periodic updates throughout the day of what you have been working on. If your company is using something like Slack or another chat server, make sure to post a detailed update on what you have been up to the past few hours. Here is an example of one of the status updates I would post to my team. Status update: - finished making changes to xyz case study and put it up for review - reviewed a couple of PRs - ran accessibility audits for the homepage and working on increasing the performance score I would usually post this in the middle of the day to update the team on what I have been working on. I also try to ask questions throughout the day to ensure that I don't get blocked on a particular issue for to long. This method of communication helps me stay connected with the team and helps my manager know where I am at in the project. Find a separate space in your home just for work When you are working in an office, there is a clear separation between work and home. This makes it easier to end your day and leave your work at the office. But with remote work, sometimes these lines between work and home become a little bit blurry. This is why it is important to designate a separate work space in your home. In my situation, I have a small desk in another room where I do all of my work. That space is only used Monday through Friday for work purposes. I have found that by creating a work space, it allows me to be in the moment and fully concentrate on my duties. Then at the end of the day, I logout out of everything and leave the work space just like I would leave a physical business. That has given me freedom to relax in my home when I am not working and fully recharge for the next day. I understand that everyone's living situation is different, and you might not have room for a designated work area. In those cases, do the best you can to carve out some space in your living situation just for work. The more you can do to separate home and business, the more productive you will be at work. Set consistent work hours When you are working in an office, you have set hours for when you are going to be there. It might be 9-5 or 8-3 with breaks throughout the day. But when you are working from home, it is very easy to work without a set schedule and put in more time outside of the standard work hours. This can quickly lead to burnout which is a huge issue within the developer community. It is really important to set a consistent work schedule so your team knows when you are available, and when you are off work. This also forces you to work within a time frame which will lead to better focus, time management and productivity. I have personally found that setting that time frame from 8-5 with breaks helps me structure my day better and get more done than if I had an open schedule. Take breaks throughout the day Developer health is another huge issue within the community. Many developers, including myself have gone for hours hunched over their computers trying to get something to work. In these situations, it is very easy to lose track of time and develop back, neck, shoulder, and eye problems. One of the key advantages of working from home is being able to take breaks and leave your work space. Take ten minute breaks throughout the day and make sure to walk around, stretch, go outside, and drink water. Taking breaks from the computer will give your body and brain a chance to rest and recharge. When I first started working remotely, I would be glued to the computer for hours at a time. But I quickly felt the negative health effects and started becoming more intentional about taking breaks. Now, I have developed a healthier work situation and can see the difference in the quality of work I am producing. Dress appropriately for important meetings We all enjoy the relaxed dress code that often accompanies working from home. In an office, you will typically be in a more work appropriate attire especially when it comes to meetings with clients. But when you are at home, it is very easy to work in some sweatpants and a t shirt. If you don't have any meetings that day, then coding in your casual attire is fine. But if you are meeting with clients or interviewing remotely, it is important to dress appropriately. Remember that it is still a business and you want to be as professional as possible, even in a remote setting. Avoid mixing personal tasks and work tasks When you are in an office, you don't worry about personal chores like doing laundry or taking the trash out. But when you are working from home, it is very easy to get distracted and mix personal tasks with work tasks. It is very important that while you are working, you are focused on work. Then during breaks, you can take care of personal items. In my situation, I make sure to finish up the task I was working on and then take a break to put a load of laundry on or take care of another personal chore. There are definitely times where something has come up and I will make sure to communicate that with the team so they know I will be unavailable for a certain amount of time. But just try to do the best that you can separating personal tasks and issues from your work tasks. Time management and structuring your day In order to work productively, it is important to plan out your day as best you can and structure your time accordingly. For example, as I am writing this blog today, I made sure to set aside time for writing the first draft, revising it and submitting it for review. During that time block, I am not focused on other PR's or other work responsibilities. That ensures I am focused 100% on writing a high quality article. Once I complete a large task, then I make sure to take a break, hydrate, walk around and eat something. That allows me to energize and gear up for the next task in my day. I found that breaking up my day into manageable tasks has provided me the opportunity to focus and produce good work. Conclusion Those are my 7 tips on what it takes to be a successful developer in a remote company. I encourage you to give each of those tips a try and see how it affects your work productivity....

How to add Notifications to your PWA cover image

How to add Notifications to your PWA

Have you ever wondered how to add those annoying (but useful) notifications to your progressive web app? Well in this tutorial, I'm going to show you how! What are we building? Live Demo https://pwa-notification-td.firebaseapp.com/ Before We Start We will make use of the Notification API__ Notification API__: The Notification interface of the Notifications API is used to configure and display desktop notifications to the user. These notifications' appearances, and specific functionalities, vary across platforms, but generally provide a way to asynchronously provide information to the user. *Note: *__The notification API is not the same as the Push API. Time To Get Your Hands Dirty 1) Clone this repo: https://github.com/devpato/pwa-notifications 2) You will see 3 folders. The ones that matter are the START and the FINAL folder. In the FINAL folder, you can see the final code, but for the purpose of this tutorial, and for you to learn, just focus on the START folder. 3) Navigate to the main.js file inside of the scripts folder 4) add the following code ` javascript const notificationButton = document.getElementById('enableNotifications'); let swRegistration = null; ` The notificationButton__ is the button that will trigger the notification in our app. If you go to the index.html, you will see the button there that I've already created for you. The swRegistration__ is just a global variable that will store our service worker. 5) Now let's create a function called initializeApp__. This function will handle everything that needs to be triggered when the app first loads. `javascript //First, we check if having service workers and notifications are //supported. function initializeApp() { if ('serviceWorker' in navigator && 'PushManager' in window) { console.log('Service Worker and Push is supported'); //Register the service worker navigator.serviceWorker .register('./sw.js') .then(swReg => { console.log('Service Worker is registered', swReg); // We are storing the service worker, globally swRegistration = swReg; }) .catch(error => { console.error('Service Worker Error', error); }); } else { console.warn('Push messaging is not supported'); notificationButton.textContent = 'Push Not Supported'; } } ` To learn more about the PushManger, visit : https://developer.mozilla.org/en-US/docs/Web/API/PushManager 6) When the app first loads, we need to call the initializeApp()__. function. To accomplish this - add the call before the declartion of the function itself. 7) Now we need to create a new function called initializeUi__. This function will look as follows: `javascript function initializeUi() { notificationButton.addEventListener('click', () => { //Do something here }); } ` The only purpose of this function is to attach a click event to the notificationButton__. So when the user clicks on the button, something will happen. 8) Now inside of the initializeApp() (function we previously created), we invoke the initializeUi();__, right after the __swRegistration = swReg;__ expression: `javascript function initializeApp() { ... navigator.serviceWorker .register('./sw.js') .then(swReg => { .... // We are storing the service worker, globally swRegistration = swReg; initializeUi(); }) ... } ` By doing this, we will initilize the UI once the registration of the service worker has been successful. 9) Time to create a new function called displayNotification__. The function will look like this: `javascript function displayNotification() { //Ask user if we show notifications if (window.Notification && Notification.permission === 'granted') { //notification(); // We will crete this function in a further step. } // If the user hasn't told whether he wants to be notified or not // Note: because of Chrome, we cannot be sure the permission property // is set, therefore it's unsafe to check for the "default" value. else if (window.Notification && Notification.permission !== 'denied') { Notification.requestPermission(status => { if (status === 'granted') { //notification(); } else { alert('You denied or dismissed permissions to notifications.'); } }); } else { // If the user refuses to get notified alert( 'You denied permissions to notifications. Please go to your browser or phone setting to allow notifications.' ); } } ` 10) Go back to the initializeUi() inside of the click__ callback, where it says "Do something here". Replace that line with: `javascript displayNotification(); ` Your code will look like this: `javascript function initializeUi() { notificationButton.addEventListener('click', () => { displayNotification(); }); } ` 11) Finally, we are going to create a notification__ function that will contain the information we want to display in our notification. `javascript function notification() { const options = { body: 'Testing Our Notification', icon: './bell.png' }; swRegistration.showNotification('PWA Notification!', options); } ` 12) Inside of your displayNotification()__ function, you will see we are calling the __notification()__, but it's commented out. Simply uncomment it , so the code can be triggered. 13) The final code will look like this: https://github.com/devpato/pwa-notifications/blob/master/final/scripts/main.js 14) Test the notification in your browser. If you want to test it on a real device, you need to deploy it, and make sure that the deployed app gets served using https__. You can you use __firebase hosting__ for this. As you might have noticed, we registered a service worker, but we didn't add any code to it becaue it wasn't necessary. In the the next tutorial, we will actually be doing more with the service worker. In that tutorial, I will show you how to send push notifications from the server using Firebase Cloud Messaging__. So, wait a bit and we'll explore much more about Service Worker features ;)...

I Broke My Hand So You Don't Have To (First-Hand Accessibility Insights) cover image

I Broke My Hand So You Don't Have To (First-Hand Accessibility Insights)

We take accessibility quite seriously here at This Dot because we know it's important. Still, throughout my career, I've seen many projects where accessibility was brushed aside for reasons like "our users don't really use keyboard shortcuts" or "we need to ship fast; we can add accessibility later." The truth is, that "later" often means "never." And it turns out, anyone could break their hand, like I did. I broke my dominant hand and spent four weeks in a cast, effectively rendering it useless and forcing me to work left-handed. I must thus apologize for the misleading title; this post should more accurately be dubbed "second-hand" accessibility insights. The Perspective of a Developer Firstly, it's not the end of the world. I adapted quickly to my temporary disability, which was, for the most part, a minor inconvenience. I had to type with one hand, obviously slower than my usual pace, but isn't a significant part of a software engineer's work focused on thinking? Here's what I did and learned: - I moved my mouse to the left and started using it with my left hand. I adapted quickly, but the experience wasn't as smooth as using my right hand. I could perform most tasks, but I needed to be more careful and precise. - Many actions require holding a key while pressing a mouse button (e.g., visiting links from the IDE), which is hard to do with one hand. - This led me to explore trackpad options. Apart from the Apple Magic Trackpad, choices were limited. As a Windows user (I know, sorry), that wasn't an option for me. I settled for a cheap trackpad from Amazon. A lot of tasks became easier; however, the trackpad eventually malfunctioned, sending me back to the mouse. - I don't know a lot of IDE shortcuts. I realized how much I've been relying on a mouse for my work, subconsciously refusing to learn new keyboard shortcuts (I'll be returning my senior engineer license shortly). So I learned a few new ones, which is good, I guess. - Some keyboard shortcuts are hard to press with one hand. If you find yourself in a similar situation, you may need to remap some of them. - Copilot became my best friend, saving me from a lot of slow typing, although I did have to correct and rewrite many of its suggestions. The Perspective of a User As a developer, I was able to get by and figure things out to be able to work effectively. As a user, however, I got to experience the other side of the coin and really feel the accessibility (or lack thereof) on the web. Here are a few insights I gained: - A lot of websites apparently tried_ to implement keyboard navigation, but failed miserably. For example, a big e-commerce website I tried to use to shop for the aforementioned trackpad seemed to work fine with keyboard navigation at first, but once I focused on the search field, I found myself unable to tab out from it. When you make the effort to implement keyboard navigation, please make sure it works properly and it doesn't get broken with new changes. I wholeheartedly recommend having e2e tests (e.g. with Playwright) that verify the keyboard navigation works as expected. - A few websites and web apps I tried to use were completely unusable with the keyboard and were designed to be used with a mouse only. - Some sites had elaborate keyboard navigation, with custom keyboard shortcuts for different functionality. That took some time to figure out, and I reckon it's not as intuitive as the designers thought it would be. Once a user learns the shortcuts, however, it could make their life easier, I suppose. - A lot of interactive elements are much smaller than they should be, making it hard to accurately click on them with your weaker hand. Designers, I beg you, please make your buttons bigger. I once worked on an application that had a "gloves mode" for environments where the operators would be using gloves, and I feel like maybe the size we went with for the "gloves mode" should be the standard everywhere, especially as screens get bigger and bigger. - Misclicking is easy, especially using your weaker hand. Be it a mouse click or just hitting an Enter key on accident. Kudos to all the developers who thought about this and implemented a confirmation dialog or other safety measures to prevent users from accidentally deleting or posting something. I've however encountered a few apps that didn't have any of these, and those made me a bit anxious, to be honest. If this is something you haven't thought about when developing an app, please start doing so, you might save someone a lot of trouble. Some Second-Hand Insights I was only a little bit impaired by being temporarily one-handed and it was honestly a big pain. In this post, I've focused on my anecdotal experience as a developer and a user, covering mostly keyboard navigation and mouse usage. I can only imagine how frustrating it must be for visually impaired users, or users with other disabilities, to use the web. I must confess I haven't always been treating accessibility as a priority, but I've certainly learned my lesson. I will try to make sure all the apps I work on are accessible and inclusive, and I will try to test not only the keyboard navigation, ARIA attributes, and other accessibility features, but also the overall experience of using the app with a screen reader. I hope this post will at least plant a little seed in your head that makes you think about what it feels like to be disabled and what would the experience of a disabled person be like using the app you're working on. Conclusion: The Humbling Realities of Accessibility The past few weeks have been an eye-opening journey for me into the world of accessibility, exposing its importance not just in theory but in palpable, daily experiences. My short-term impairment allowed me to peek into a life where simple tasks aren't so simple, and convenient shortcuts are a maze of complications. It has been a humbling experience, but also an illuminating one. As developers and designers, we often get caught in the rush to innovate and to ship, leaving behind essential elements that make technology inclusive and humane. While my temporary disability was an inconvenience, it's permanent for many others. A broken hand made me realize how broken our approach towards accessibility often is. The key takeaway here isn't just a list of accessibility tips; it's an earnest appeal to empathize with your end-users. "Designing for all" is not a checkbox to tick off before a product launch; it's an ongoing commitment to the understanding that everyone interacts with technology differently. When being empathetic and sincerely thinking about accessibility, you never know whose life you could be making easier. After all, disability isn't a special condition; it's a part of the human condition. And if you still think "Our users don't really use keyboard shortcuts" or "We can add accessibility later," remember that you're not just failing a compliance checklist, you're failing real people....