DEV Community: anthonynsimon

5 Incident Communication Templates

anthonynsimon — Fri, 09 Dec 2022 15:00:00 +0000

There’s no such thing as 100% reliability. Downtime happens so it’s important you’re ready for it.

On one hand you have the pressure to fix the issue during the heat of an outage, and on the other hand you should keep customers and internal teams in the loop so they understand how they’re impacted and prevent confusion.

An example incident using Cronitor Status Pages.

In this blog post, you’ll find five incident communication templates that you can use in a variety of situations. They’re meant to provide some structure when writing an incident update, so feel free to edit them according to your needs.

Best practices when writing outage notifications

An outage notification is an important way to keep your customers informed about any disruptions to your services. We'll go over some key points to include when communicating a service disruption:

Affected services: Be sure to include details such as which services are affected, and to what extent. For example, if your website is down, you might want to specify whether only some pages are unavailable, or if the entire site is offline. Particularly, if the outage is affecting a critical business function it's important to let your customers know.
Expected duration: How long you expect the outage to last will help your customers plan around the disruption. If you don't have an exact timeline, it's okay to provide a best guess or a range of time. Just be sure to update your customers if the situation changes and the outage ends up lasting longer than expected.
Current status: As your team works on resolving the incident, it’s helpful to provide updates about the current status of the outage. That way customers won’t need to go through your support team just to ask what’s the latest update.
Ways to get help: Finally, make sure you provide a way for your customers to get in touch with someone who can provide more information about the outage or to get notified when there’s an update. It's important to have someone available to answer questions and provide updates, as this will help to keep your customers informed and reduce frustration.

It’s important to be transparent with customers and all stakeholders when communicating a major service disruption. That way, you can turn every outage into an opportunity to build trust in your service.

Template #1 - Investigating an incident

Here’s a template for communicating a newly discovered incident:

We are currently investigating an incident that is impacting [Impacted Service]. We apologize for any inconvenience this may cause and are working to resolve the issue as quickly as possible.

At this time, we do not have any further details on the cause of the incident or an estimated time for resolution. We will provide updates as we have them, and appreciate your patience while we work to resolve the issue.

Template #2 - Monitoring an ongoing incident

Below is a template for communicating an incident update. This assumes a fix has already been implemented but it’s not confirmed whether the incident has been resolved yet:

We have identified the cause of the incident on [Impacted Service] and are implementing a solution. We are closely monitoring the situation to ensure the issue is fully resolved.

We apologize for any inconvenience and will keep you informed as we have more information. Thank you for your understanding as we work to fix the problem.

Template #3 - The issue has been resolved

Here’s a template for communicating that an incident has been resolved and no further updates will be provided:

We are pleased to inform you that the issue has been resolved. [Brief description of what happened]. The issue mainly impacted our [Impacted Service] service.

Thank you for your patience during this time. Please do not hesitate to contact us if you have any concerns or questions.

Template #4 - Scheduled maintenance

The template below communicates a scheduled maintenance period. For example, when you need to upgrade a database or to temporarily take down a section of your website or API:

We wanted to let you know that we will be performing scheduled maintenance on [date and relevant times]. During this time, [affected services] may be unavailable.

We apologize for any inconvenience this may cause, and we will do our best to minimize any disruption to your service.

If you have any further questions or concerns, please do not hesitate to contact us.

Template #5 - Potential security breach

The template below communicates a potential security breach which may have exposed personal data:

We wanted to make you aware of a potential security breach that may have occurred on [date and time] and possibly exposed the following personal data: [Brief description of personal data involved].

While we are still investigating the issue, we want to inform you as soon as possible so that you can take steps to protect your information. We recommend that you change your password for any accounts that may have been affected and monitor your accounts for any unusual activity.

We apologize for any inconvenience this may cause, and we are working quickly to investigate and resolve the issue.

If you have any questions or concerns, please do not hesitate to contact us.

Use a status page for simpler communication

Customers and internal stakeholders expect timely updates whenever there’s a service disruption. Cronitor offers beautiful Status Pages so you can easily provide real-time updates and information about the status of your services, helping to reduce confusion and frustration for your customers.

You can create a status page for free or upgrade to a paid plan when you need more advanced features such as private pages for your internal teams or your company branding.

We hope this guide has been helpful to you, let us know if there’s any other templates you find useful!

5 Best Status Page Tools - Free & Open Source

anthonynsimon — Wed, 28 Sep 2022 13:47:59 +0000

Having a status page is essential for any online business. It enables you to communicate with your users when you need it most: during the heat of an incident.

You can publish updates on any ongoing incidents, showcase historical uptime and performance, and notify about maintenance windows all from a single page.

Here’s a list of free & open source status page tools you can use for your next project:

1. Cronitor

Cronitor Status Page is simple, fast and comes with active monitoring built-in. That means you can set up uptime monitoring for your websites and APIs, and also create your status page using a single service.

Cronitor has a free tier which includes 5 monitors, 1 user and free basic status pages. Once you need more you can upgrade to the business plan in which you only pay for what you use (eg. $25/mo for branded status pages).

Why pick Cronitor Status Pages?

Generous free tier includes status pages and uptime monitoring.
You can easily add a custom domain, your company logo and support links.
Private pages for your internal teams (IP and password protection).
Real-time uptime and performance graphs.

Check out the live demo.

2. Atlassian Statuspage

Atlassian Statuspage is a well-known alternative which has been in the market for many years. It offers a free tier which might be enough for the needs of many businesses, but do consider that as your requirements grow the price tag grows substantially too.

The free plan gives you 100 subscribers, 2 team members, 2 metrics, and email or Slack notifications.

Their paid plans start at $29/mo and go all the way up to $1,499 depending on the number of subscribers, team members and customization features needed. For example, for custom CSS/HTML/JS you’d need the $399/mo plan.

Why pick Atlassian Statuspage?

You need specific features such as custom CSS/HTML/JS, and can afford the price tag.
You're already using Atlassian's products and would like to remain within their platform.
The free plan is enough for your needs.

3. Instatus

Instatus is a hosted status page service that focuses on simple and fast pages. It includes features such as custom CSS and Javascript, multi-language support and status widgets for your website.

Why pick Instatus?

Offers free tier and competitive paid plans.
Unlimited subscribers and teammates.
Your project requires localization features.
You don't need built-in monitoring and want to use external tools for this.

4. Vigil

Vigil is an open source alternative that combines status pages with uptime monitoring. It's useful if you want to have even more control over your monitoring infrastructure and feel comfortable managing your own servers.

As of September 2022 it's still actively maintained. Which is why we've chosen to recommend this project over other popular open source alternatives such as Staytus, Cachet or Statusfy.

It's important a project is being actively developed, particularly when it comes to security patches and bug fixes. Please do your own research before self-hosting any solution in your own infrastructure.

Why pick Vigil?

Open source and actively maintained.
Uptime monitoring built-in.
Clean dashboards.
Lots of configuration options.

5. Freshstatus

Freshstatus is a status page service by Freshworks. You can sign up for free and it comes with various integrations such as Twitter, Slack, Webhooks, and even Freshworks own services: Freshping, Freshdesk, Freshservice. If you're already on their platform it's a great way to get a status page.

Why pick Freshstatus?

You're already using other products by Freshworks and want to remain within their platform.
You'd like to use their Freshping, Freshdesk or Freshservice integrations.
Supports customizing the alert emails.

Where to go from here

In this article we've explored our top picks when it comes to free and open source status page tools. We hope this proves useful in your search for which tool is best for your needs.

Last but not least, be sure to check out real-world examples of status pages. It's a great way to understand how various companies make use of their page and how to make the most out of yours.

9 Real World Examples of Great Status Pages

anthonynsimon — Tue, 27 Sep 2022 21:08:11 +0000

A status page is essential if you have a website, API or any internet-based service. It provides visibility into the current state of your software, and helps you communicate ongoing incidents and maintenance windows with your customers.

But not every status page is the same. That's why we've hand-picked various examples of what we consider great status pages to learn from.

Let's take a look at each of them.

Flare

Status page: status.flare.systems

What they do: Flare is a digital footprint monitoring solution. It monitors your systems for security threats, technical leaks, and provides visibility to external attack surfaces.

What makes it a great status page: Ease of use. Flare's status page is well-structured and is easy to understand. It clearly displays the current health of their services as well as historical uptime and performance, plus any past incidents.

These features help their customers quickly understand the impact of any ongoing outage, and expected resolution time. Additionally, potential customers are able to quickly assess how they handled past outages and understand the reliability of their services.

Discord

Status page: discordstatus.com

What they do: Discord is a hugely popular platform for chat, voice and video calls. They handle millions of concurrent connections for their users - every second of downtime has a big impact on their service.

What makes it a great status page: Branding. The custom domain "discordstatus.com" makes it super easy to find their status page and differentiate it from unofficial websites. Additionally, the in-page logo and brand colors help users know they're looking at the right status page.

Cloudflare

Status page: cloudflarestatus.com

What they do: Cloudflare is used by millions of websites around the world for its content delivery network and DDoS protection service.

What makes it a great status page: Their status page shows the current status for hundreds of server locations from around the world. As such, it can easily become complex and difficult to navigate. However, they group statuses by region and make it easy to collapse these groups so users can quickly find the relevant services.

Postmark

Status page: status.postmarkapp.com

What they do: Postmark is a transactional and marketing email SaaS. It makes it easy to send and receive emails via their API, and it's well known for its delivery success rates.

What makes it a great status page: From custom branding to ease of use, Postmark's status page gets many things right. Something to highlight about this example is that they include links to their FAQs and quick help. This makes it easy for users to find relevant information when they need it most.

GitHub

Status page: githubstatus.com

What they do: GitHub is a hugely popular version control platform for Git repositories. Millions of developers around the world rely on their service to store, build and deploy their software.

What makes it a great status page: GitHub's status page is quite minimalistic without sacrificing usability. Everything you need to know about their system status is presented in a one-page format. One detail we especially like is that you can hover over the service names to reveal useful contextual information about them. Additionally, their subtle use of branding and easy to find support links make it a great status page.

Amazon Web Services

Status page: health.aws.amazon.com

What they do: AWS is a major cloud provider which arguably handles a huge proportion of internet traffic. Their services are mission-critical to thousands of companies around the world, and as such transparency around incidents and SLAs is vital for any business relying on them.

What makes it a great status page: AWS has 27 regions, 87 availability zones and 400+ points of presence around the world. Without even considering the number of services available in each region, it's fair to say their status page contains a lot of information. But that doesn't mean it's difficult to understand. They've organized their services by region and provide search functionality so users can quickly find what they're looking for.

Twilio

Status page: status.twilio.com

What they do: Twilio is an API for sending and receiving calls and text messages. It's very popular among developers for their easy to use API and vast documentation.

What makes it a great status page: As the bridge between internet-based apps and countless network carriers around the world, there's plenty of moving pieces and ways in which the service performance can be temporarily degraded. Twilio presents their status page with a focus on active incidents by highlighting them at the very top of their page. This is valuable to developers looking to troubleshoot any issues in their integration, as they can quickly gauge if the outage is impacting their own apps and services.

Shopify

Status page: shopifystatus.com

What they do: Shopify is an e-commerce platform used by millions of businesses around the world. You can create an online shop, upload your product catalog, manage orders and sales from one central place.

What makes it a great status page: As many businesses rely on Shopify as the center-piece for their operations, their uptime and performance is critical to them. Their status page is another great example of keeping it simple while providing all the relevant information in one place. If you're a customer, they also make it easy to subscribe for notifications whenever there's an outage or planned maintenance window.

DigitalOcean

Status page: status.digitalocean.com

What they do: DigitalOcean is a cloud infrastructure platform, popular for its focus in being easy to use and competitive pricing.

What makes it a great status page: As other cloud platforms, the number of services and locations they operate in makes for a lot of information to pack in one page. However, they present a summary of their services in a sidebar format, which makes it really easy to gauge the overall status of their platform.

Final words

In this article we took a look at a selection of real-world status pages and what makes them great examples. We hope the highlights mentioned in this list are useful to you when building your status page.

Looking to create your own status page? At Cronitor we've put together The Complete Guide to Status Pages so you can create a beautiful status page in minutes. Check it out!

The Complete Guide to Status Pages

anthonynsimon — Tue, 09 Aug 2022 14:04:00 +0000

Picture this: Your phone is ringing, you received an on-call alert.

Turns out, production is down and your customers want to know why they can’t access the site. There’s a flood of support tickets. People would like to get notified as soon as you resolve the incident.

Your team is focused on fixing the issue. After all, the first rule of incident response is: stop the bleeding.

But it’s difficult to keep everyone in the loop during the heat of the outage. There’s too many support channels and everyone is confused about the current status.

Wouldn't it be nice to have a single page where anyone could check what’s the current status and any relevant information?

Enter status pages.

In this guide we'll explore what status pages are and why you should have one. We’ll then create a status page from scratch and explore everything you need to know to make the most out of them.

What is a status page

A status page provides visibility into the current health of your software. It's a single page where anyone can view the latest status, any ongoing or past incidents.

Incidents happen. Whether you’re a startup or a global enterprise what matters the most is how you handle them. Status pages help you turn every outage into an opportunity to build trust in your service.

With a status page, your customers can answer questions such as:

Is your site up and running?
How reliable is your service?
What kind of performance can I expect from your API?
Is there an ongoing outage?
Where can I contact you in case of an emergency?

Check out this demo status page for a real-world example of what they look like in action.

Benefits of having a status page

A status page is of great help before and during downtime. Being transparent about how your team has handled incidents in the past is a great way to build trust.

When your service is up, they help you showcase historical reliability. During downtime, they help your team communicate status updates with all stakeholders.

Status pages enable your team to:

Showcase your reliability. Help your users see how reliable and performant your services are. This builds trust and sets the right expectations on what your SLAs are.
Share incident updates. Simplify incident management by publishing updates from one place. Your team doesn't have to use different platforms to communicate incidents.
Automate incident creation and resolution. Monitoring platforms - such as Cronitor - create and resolve incidents for you. This frees up time for your team and ensures the status on your page is always accurate.
Reduce support tickets. Be transparent about past and ongoing outages. Your customers can answer their questions without going through support first.

It's not only tech-savvy customers that find them useful. More than ever our daily interactions happen over the internet and downtime happens. That's why many users now look for a company's status page whenever they think there's an issue.

Let’s see it in action. Next, we’ll create a status page and cover some of the most common use cases for it.

Create your first status page

We’re using Cronitor to create our example status page. It’s a simple monitoring platform for your websites, APIs or cron jobs. The free tier includes up to 5 monitors and a basic status page, so feel free to follow along.

To start, open your Cronitor dashboard and on the left-side menu, click on Status Pages.

You can name your status page anything you’d like. You're asked for your website URL so that users can find your official website too.

You should also pick a hosted subdomain of your choice. This is important as it enables you to view and share the status page right away. Note that the subdomain should be unique across all status pages on Cronitor.

Click on Create - the status page is live!

You can preview it by clicking on the View Status Page button on the top right side of the screen. You can always access it via the hosted subdomain you picked earlier. For example: panelbear.cronitorstatus.com.

Right now our status page is empty. Let's fix that by adding some page components.

Add page components

Next let’s add some components to our status page. A component could be a check, job, heartbeat or even a group of monitors. You should create a few monitors if you haven’t already so you can attach them to your page.

Once you have created some monitors, head back into your status page admin panel. Click on the “Add any monitor or group” search box to open the dropdown.

This dropdown lets you attach any existing monitor as a component to your status page. Let’s pick a few of our monitors so that our status page is not empty.

You can re-order and rename the components as you’d like. Renaming is useful in case you'd like to have more control over what’s presented to your end users.

Finally, let’s check out the status page with the components we added.

Publish your first incident

Now that we have created a status page, let's publish an incident to it to see how it all comes together.

To start, go to your Cronitor dashboard and head into the Incidents page. Click on "Create Incident", you should now see the incident form.

Fill in the incident details. Don't forget to select your status page in the Publish to Status Page dropdown. In case you'd like to publish to several status pages too, you can select them here.

Under Incident Updates you can add any relevant updates. For example, when your team is investigating an incident, they could create update such as:

"Investigating: We have detected a server outage, the team is investigating the issue."

Once your team finds the issue and deploys a fix, they could publish another update:

"Monitoring: We identified the issue and deployed the fix. We're monitoring the servers to ensure the incident has been resolved."

This helps your users understand the current status of an incident as well as the timeline of events.

Once you've added any incident updates you deem relevant, hit Save.

Next, open the status page. You should be able to see the active incident at the top of the page.

Resolve an active incident

Next, let’s resolve the incident so our users know we resolved the issue.

Click on the one we created earlier, then Edit and add an update with the status “Resolved” to close this incident. You can optionally provide a description of the update.

The incident will no longer appear at the top of the status page. But we can always find it again in the incident history page.

Cronitor comes with built-in active monitoring and automated incidents. It can open an incident whenever your site, API or cron job is down. It will also resolve the incident when the monitor becomes healthy once again.

Automated incidents are not published to status pages by default. This gives you total control over what you communicate to your users. They are only visible to your team in the Cronitor dashboard. In case you’d like them to appear on your page, you should attach them manually.

Of course, you can publish an incident manually as we did earlier. An incident doesn’t have to have originated from an existing monitor. This is useful when you want to publish a general outage, or maintenance window.

View past incidents

Your status page also makes it possible to view past incidents. This is useful to show how your team handled a previous outage and to be able to share incident details.

To view past incidents, go to your status page and click on Incident History.

You can share individual incident URLs as they are permanent links. That means the URL does not change even if you resolve the incident or its details change. This makes it easier to collaborate both during and after the outage.

View historical uptime and performance

Every status page showcases your historical reliability with uptime and performance charts. They are automatically computed and kept up-to-date for you.

Providing historical uptime charts is a great way for your users to understand how reliable your service is. For example, this is what the uptime chart looks like.

Performance charts are great to showcase your team SLAs and the typical performance of your APIs or cron jobs. This helps you set expectations with any users wanting to make use of your APIs. They can better understand what constraints or guarantees they’re working with.

Here’s an example of what performance charts look like.

Right now only monitors of type Check and Job support these charts. Group components and heartbeats will display a simpler status without charts instead.

Add your company branding

The status page is fully functional. However, it's lacking some company branding to make it clear to our users that they've found the official page.

We should add a company logo, some helpful links, and host the page under our own company domain.

Let’s start by adding a company logo.

First, in the Cronitor dashboard, go to your status page settings. Then under “Brand logo” you can upload the logo you wish to display on the page.

Hit Save and reload your status page. It now showcases our company logo - it looks great!

Serve from your own domain

Every status page comes with a cronitorstatus.com subdomain of your choice. The free subdomain makes it easy to quickly preview the page.

However, most companies prefer to serve the status page from their own domain, eg. status.panelbear.com. This makes it easier for your customers to find your status page and know it's the official one.

Cronitor makes it super easy to use your own domain. It comes down to two steps:

1) Set your custom domain in the status page settings.
2) Configure your DNS records to point to cname.cronitorstatus.com.

Let’s add a custom domain for our example page.

First, in the Cronitor dashboard go to your page settings and input the desired domain. It must be unique across all status pages in Cronitor. We’ll go with status.panelbear.com.

Hit Save, and now go to your domain DNS records. These instructions depend on which third-party provider you’re using. We’ll use CloudFlare as it’s a popular one.

Add a CNAME record for status.panelbear.com with a value of cname.cronitorstatus.com. Important note for CloudFlare: be sure to select “DNS-only” mode or the custom domain might not work.

You should now be able to view the status page via the custom domain at status.panelbear.com.

When configuring DNS records it can take some time for our changes to propagate around the world. If you see any errors such as "DNS_PROBE_FINISHED_NXDOMAIN", it might be that the records haven’t propagated yet. This process can take anywhere from a few minutes to 24 hours.

In case you’re having persistent issues remember support is always an email away - we’re happy to help out!

Add customer support links

Next let’s include a link to our customer support page. This way users know how to get in touch or find your docs when they need them the most.

To do this, in the Cronitor admin panel, open your status page and click on Edit. Next fill-in a support URL and click on Save.

Open your status page and notice the new “Support” button on the top right corner.

Password protect your internal status pages

It’s important to have control over who can access our status page. Most status pages are public, anyone who opens the page can see the components and incidents.

However, many companies also use status pages for internal teams. These pages are not meant for external users as they can contain sensitive data. That's why Cronitor status pages support password protection and IP/network based protection.

Let’s enable password protection to see this feature in action.

First, in your Cronitor dashboard go to Status Pages, find your page and click on Edit. Under Deployment, click on Access, and select Password Protected. A new field should appear where you can input your desired password.

Save your changes. If you open your status page you should see that a password is now required to access the page.

Control access with IP allowlists

Companies usually prefer to protect access to their status page by only allowing a set of specific IPs or office networks to access it.

This is convenient for larger teams, as you'd no longer need to share the page password with everyone who needs access to it.

It also increases security by completely removing the possibility of leaking the password (there is no password!). It also helps you ensure that people who no longer work at the company no longer have access to the page.

Here’s how to limit who can access your page based on their IP or network:

First, in your Cronitor dashboard, go to your status page settings and under Deployment you’ll see a field called IP Allowlist.

Here you can enter one or more IP addresses or CIDR networks. It supports both IPv4 and IPv6. Let’s add our fictional office network to see it in action.

Only devices that match an IP or network listed in this allowlist should be able to view the page contents.

Try it out with your own IP. You should be able to view the status page - except it no longer requires a password!

However, if the device IP is not granted access by the IP allowlist, the page won't disclose the content. That means components, metrics and incident details are not shown.

Add contextual info to your components

You can optionally add contextual information to each of your status page components.

This helps your users understand:

Which URL is being monitored by an uptime check.
What to do in case of a failing component.
What SLAs they can expect out of your service.
Any additional information you consider important.

To add component descriptions, in your Cronitor dashboard go to your status page and click on the edit button next to any component.

Add a component description and hit Save. For our example, we just want to clarify which endpoint is being monitored by this component. But you could add any other information you deem useful.

Once you've added a component description, head back to the status page and reload it. You should now be able to see the description by hovering over the info tooltip next to the component name.

Subscribe to RSS feeds

A really useful feature of status pages is for your customers to be able to subscribe to updates.

That way, your users can get notified whenever the status changes, instead of having to constantly refresh the page to see if there's any update.

Every status page comes with its own RSS feed out of the box. To access it, simply click on the RSS Feed button on the top right corner of your status page.

Being able to subscribe to updates is a really powerful feature. This also enables your internal teams to get notified in their platform of choice. For example via email, webhooks or even by subscribing a Slack channel for updates.

Try status pages for free

In this guide we explained what status pages are and how they benefit anyone running mission critical software.

We also covered how to create a status page using Cronitor. We then explored how to customize the page, publish and resolve incidents, and how to get the most out of it.

Cronitor is the simple, yet powerful monitoring platform. It’s trusted by thousands of developers from around the world. Create your free account and launch a status page in minutes.

25 Website Performance Metrics to Watch in 2022

anthonynsimon — Wed, 08 Dec 2021 12:32:52 +0000

Website performance is not about having high scores in some artificial benchmark. It's about ensuring you delight every visitor with a great experience.

If you’re building a product or business, it’s crucial to always deliver a great end user experience. Frustrated visitors are more likely to abandon the site, and it has a direct impact on conversions and retention.

But with hundreds of metrics available, it's often difficult to know where to focus your efforts and avoid wasting time on vanity metrics.

In this guide I'll cover some of the most important website performance metrics to keep an eye on, and how to make the most out of them.

Why website performance matters

Many companies have found that a fast, responsive website can significantly boost your conversion rate and sales. For example, Amazon found that for every 100 milliseconds it reduced on page load time, it increased sales by 1%.

A 1% increase in annual sales for Amazon translates into billions of dollars in additional revenue alone, not to mention that faster websites lead to less frustrating experiences, which may in turn translate into more returning users down the line.

Also, Google has incorporated many of these metrics as part of its ranking algorithm, as they are directly related to how frustrated a visitor might be when sent to your website.

That's why, I believe that ensuring a great end user experience will be more important than ever in 2022 and beyond.

How to interpret website performance metrics

I recommend a top down approach to website performance monitoring. Focus on the metrics most impactful to user experience first, and only dive into page load time optimization once you've done that.

For example:

Start by measuring your Core Web Vitals. This helps you understand your page experience from the perspective of your end users.
Then look at your Lighthouse scores and its suggestions. They're often very actionable and pragmatic.
Once you understand which factors impact your page experience the most. Deep dive into technical metrics such as page load time in order to troubleshoot performance bottlenecks, and what might be causing issues on your site.

Next, let's look at the complete list of metrics and what they mean.

Core Web Vitals

Core Web Vitals are some of the most important metrics to measure for page experience. They were first proposed by Google as a way to measure how visitors experience a website.

If you want to have the best chance to rank higher than your competitors on search results, you should ensure that your site's Core Web Vitals fall within the recommended thresholds:

Core Web Vitals best practices.

The key insight is that Web Vitals measure the page experience, as opposed to just load time figures. Page load time often measures site speed from a purely technical perspective, and may not be representative of what really happened from the perspective of the user.

What does that mean?

For example, if the main content of a page has already loaded (eg. the blog post and images), but some background Javascript resources are still loading, one could argue that the page experience hasn't been significantly impacted by that script which hasn't yet loaded.

In this example, the page load time would look very high, while in practice the visitor has already started reading the main piece of content, so there's no material impact on the experience.

1. Largest Contentful Paint (LCP)

Largest Contentful Paint is a metric that measures how long it takes for the main piece of content to load on the screen.

A LCP of 2.5 seconds or less is considered good, while a score of 4 seconds or more may lead to a poor experience.

2. Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) measures the visual stability of a website. In other words, it measures by how much the main elements shift around as the page loads.

Google recommends a CLS of 0.1 or less. Usually the lower the better. If this score is too high it can lead to frustrated visitors, who may attempt to click on one button only for the element to move around as the rest of the page loads.

3. First Input Delay (FID)

First Input Delay measures input delay. In other words, it measures how quickly a user can start interacting with a website, even if it’s still loading.

To make your site feel snappy, a FID of 100 milliseconds or less is advisable, while an input delay larger than 300 milliseconds may lead to a degraded experience.

By the way, I also wrote a more detailed post on Core Web Vitals, check it out here.

Lighthouse Scores

Lighthouse is an open source tool often used in Chrome DevTools to create automated reports on the quality of a web page. What makes this tool particularly useful is that it gives you suggestions on how to improve your scores.

Why is this important? It's generally a good enough indicator of what search engines such as Google might evaluate when ranking your site.

Even if your performance is great, you want to ensure your site is accessible, follows best practices, and has good SEO scores. This not only helps search engines understand the content on your site better, but directly affects how people interact with your site.

Example Lighthouse report.

4. Performance Score

The Lighthouse Performance score is a weighted average of all performance audits. It's a number between 0 and 100, where higher means a better score.

This score is determined by aggregating the following audits:

First Contentful Paint
Speed Index
Largest Contentful Pain
Time to Interactive
Total Blocking Time
Cumulative Layout Shift

You can read more on how Lighthouse weights these audits here.

5. Accessibility Score

The Lighthouse Performance score is a weighted average of all accessibility audits on your site. It's also a number between 0 and 100, where higher means a better score.

It aggregates a large number of accessibility audits including:

aria attributes
Images with alt text
Valid values for the lang attribute

To see the full list of accessibility audits, and how Lighthouse weights these audits, here is an article on the topic.

6. SEO Score

The Lighthouse SEO score tells you how well search engines can understand your content. It's a weighted average of all SEO audits on your site.

Again, it's a number between 0 and 100, where higher means a better score.

Some audits included in this score are:

A valid <title> element
A valid robots.txt file
A valid rel=cannonical attribute

There's plenty more audits that fall within the scope of this score. To read the full list, check out this article.

7. Best Practices Score

The Lighthouse Best Practices score tells you about the code health of your web page. As with all other scores, it also shows you opportunities to improve the health of your site.

It's a weighted average, in which 0 is the lowest score and 100 the highest (better), and includes various technical audits such as:

Correct aspect ratio for images
Using HTTP/2 for all resources
Using HTTPS to serve the site
Not using deprecated browser APIs

To read all audits included in this score, read this article by the Lighthouse team.

8. PWA Score

The Lighthouse PWA score tells you if your site is compatible with the requirements for a Progressive Web App. At a high level, that means it should be fast, reliable and installable.

It's a weighted average, in which 0 is the lowest score and 100 the highest (better), and includes various technical audits such as:

Page load should be fast even on mobile networks
Use HTTPS to serve the website
Registers a service worker that controls page and start_url
The web app manifest meets the installability requirements

You can find the rest of the audits for this score in this article.

Page Load Metrics

When you click a link, your web browser starts a multi-step process to load all synchronous resources required for this web page. The longer this process takes, the longer you must wait to interact with a website.

A simplified page load time process.

How long this process takes is what the Page Load Time measures. It involves multiple steps, and can be broken into multiple parts such as DNS lookup time, SSL/TLS, download size and many more.

Let's look into each one individually.

9. Page Load Time

Page load time measures the amount of time it takes for a complete web page to show up on your screen.

It's measured from the point a user initiates it - such as clicking on a link or typing the website URL - to when the page has fully loaded in the browser.

Various page load time measurements in Panelbear

10. Domain Lookup Time

The Domain Lookup Time is the time spent resolving the server address for a given domain.

For example, when you type google.com your browser must first resolve that domain name into an IP address (the server which will serve the page HTML for our request). The duration of this process is what this metric measures.

11. Server Connection Time

Once the browser has resolved the domain name into an IP address, it now needs to connect to the web server. The Server Connection Time measures how long it took to establish a TCP connection to the server.

12. Establish SSL/TLS Time

Transport Layer Security (TLS) is an encryption protocol designed to secure communications over the Internet.

Establish SSL/TLS Time measures how long it takes to perform a TLS handshake. During a TLS handshake, the two sides exchange messages to acknowledge and verify each other, establish which encryption algorithm will be used, and agree on session keys.

This process is a foundational part of how HTTPS works, and is vital to ensure privacy and security while you browse the web.

Various network timings in Panelbear.

13. Time to First Byte (TTFB)

Time to First Byte (TTFB) is how long it takes from when a browser requests a page to when it receives the first byte of information from the server. This usually includes the time spent on DNS lookup, establishing the TCP connection, and the SSL/TLS handshake if the request was made over HTTPS.

It's a good metric to approximate the performance of a backend server, from the perspective of the end user.

Inspecting the median TTFB for a website.

Why is this metric important?

If you measure the response time of your server from the server itself, you would only account for the time your server spent processing the request. In other words, the journey from your server to the user's browser would be unaccounted for.

For example, say you are located in California and your server is located in an AWS data center in North Virginia. You measure your TTFB and you're happy to see a result of 25 ms. However, when a user from the EU or Australia opens your website, the TTFB is now 200-500 ms.

The conclusion here might be that no matter if you scale your servers vertically or horizontally, the real issue is that the server is too far away from the end users. So you probably want to deploy servers in those regions too - assuming it makes sense for your product or business.

14. HTML Download Time

HTML Download Time measures the time it takes to download the initial document for a website. This document normally references various other resources (images, stylesheets, scripts) which are queued for download too.

15. Render Time

The Render Time measures how long it takes for the browser to paint the HTML document after downloading and parsing. This can vary a lot as it highly depends on the complexity of your site and the performance capabilities of the users device (eg. some mobile devices can take longer to render a complex website vs a powerful development machine).

16. Request Count

The Request Count refers to the number of resources required to load a web page. The impact of this metric on end user experience is highly dependent on other factors too.

For example, if you have a website which requires 50 requests to load but most of them are small resources which do not block rendering, it may not negatively impact how the user interacts with the site.

On the other hand, if you have a web page which requires a single request to load, but that request takes 10 seconds to complete and loads several megabytes of data, it's likely the user will abandon the site before the request completes.

As with most other metrics, it's useful to measure request count in relation to the other characteristics of your web page.

17. Transfer Size

Transfer Size measures the total size of all assets transferred during page load. This includes every request for HTML, images, stylesheets, scripts, and JSON documents.

It's a good measurement of how heavy your web page is.

18. HTML Transfer Size

The HTML Transfer Size tells you the size of all HTML assets transferred on page load.

19. Image Transfer Size

The Image Transfer Size tells you the size of all image assets transferred during page load.

The following are examples of common image assets:

Format name	Extension	MIME type
Graphics Interchange Format (GIF)	.gif	image/gif
Web Picture format (WEBP)	.webp	image/webp
Portable Network Graphics (PNG)	.png	image/png
AV1 Image File Format (AVIF)	.avif	image/avif
Joint Photographic Expert Group image (JPEG)	.jpeg, .jpg	image/jpeg
Scalable Vector Graphics (SVG)	.svg	image/svg+xml

20. CSS Transfer Size

CSS Transfer Size measures the total size of all stylesheet (CSS) assets transferred during page load.

21. Font Transfer Size

The Font Transfer Size tells you the size of all font assets transferred during page load.

The following are examples of font assets:

Format name	Extension	MIME type
TrueType	.ttf	font/ttf
Web Open Font Format	.woff, .woff2	font/woff, font/woff2
OpenType	.otf	font/otf

22. Javascript Transfer Size

The Javascript Transfer Size measures the total size of all Javascript (JS) assets transferred during page load.

For many modern web apps, this asset type has become a considerable chunk of the page load process. Large Javascript files may not only lead to longer download times, but also increase the time the browser needs to parse and render the site. This can negatively affect how long it takes for the site to become interactive too.

In order to improve load times, many applications now rely on techniques such as tree shaking (automatically remove unused code), asset bundling (package related assets together) and code splitting (split files and only load as required for specific pages). A popular tool for these purposes is Webpack.

23. JSON Transfer Size

JSON Transfer Size measures the total size of all JSON assets transferred during page load.

24. Video Transfer Size

Video Transfer Size measures the total size of all video assets transferred during page load.

Here are some examples of common video assets:

Format name	Extension	MIME type
WebM	.webm	video/webm
Ogg	.ogg	video/ogg
MPEG-4	.mp4	video/mp4
iPhone Index	.m3u8	application/x-mpegURL
iPhone Segment	.ts	video/MP2T
Flash	.flv	video/x-flv
3GP Mobile	.3gp	video/3gpp
QuickTime	.mov	video/quicktime
A/V Interleave	.avi	video/x-msvideo
Windows Media	.wmv	video/x-ms-wmv

25. Javascript Error Count

The Javascript Error Count tells you how many runtime errors the browser encountered while loading your web page.

While on its own it's not enough to troubleshoot and debug errors, it's very helpful to track this metric in aggregate to ensure no deployments or configuration changes cause unintended issues during runtime.

This metric is most useful when monitored in conjunction with error tracking software. That way, if the total error count goes beyond your tolerance threshold, your team would be able to troubleshoot the issue by inspecting the reported stack traces, and breadcrumbs to understand why the issue happened and fix it early.

In Conclusion

As previously mentioned, a faster website not only helps deliver a great user experience, but can also significantly boost your conversion rate and sales.

Monitoring your website's performance over time is more important than ever in order to prevent unintended consequences when deploying bug fixes, adding third party scripts and making improvements to the site.

That way you can make changes with confidence that you're not breaking stuff without realizing, and ensuring you always deliver a great experience on your website.

I hope this guide comes useful to you. Also, be sure to check out my guide on website monitoring tools for various alternative tools you can use to monitor your frontend applications.

Monitoring Next.js Apps in Production

anthonynsimon — Fri, 17 Sep 2021 10:43:05 +0000

I've been using Next.js for various new projects over the past year, and immediately fell in love with its development experience. Out of the box, it includes goodies such as client-side routing, fast refresh, code splitting, static generation (SSG) and server-side rendering (SSR).

However, over time I've learned that building an application and running it in production are wildly different things. When you run a website in production visitors have certain expectations about its uptime, reliability and performance, and each aspect comes with its own set of challenges.

That's why, whether you're launching a new site or running a mission-critical service, you probably want to have some form of monitoring in place to ensure things are running smoothly.

In this guide I'll be showing you how to monitor your Next.js app's live traffic and performance, track custom events, and even set up Slack alerts to get notified when something's up.

I'll be using Panelbear, which has a free tier so you can follow along. By the way, I'm the founder and also wrote a blog post on the tech stack in case you're interested.

Let's get started!

Set up your Next.js project

First things first, let's create a repo and initialize our Next.js app.

npx create-next-app panelbear-example-nextjs --use-npm --example "https://github.com/vercel/next-learn-starter/tree/master/learn-starter"

Next let's cd into the directory, and start the development server.

cd panelbear-example-nextjs

npm run dev

> learn-starter@0.1.0 dev
> next dev
> ready - started server on 0.0.0.0:3000, url: http://localhost:3000

If you now open http://localhost:3000 on your browser, you should see the example Next.js starter app appear.

Next.js has compiled our app and generated all the assets needed to serve it - pretty standard stuff so far. This is usually where you start building your actual project, but we'll stick to the starter template since we're more interested in the monitoring aspects for this guide.

Now let's move on to adding the analytics script.

Add the tracking code

Assuming you already created your Panelbear account, let's register a new site. We'll call it "Next.js Example App" so we can easily recognise it later.

You can register new sites on the overview page.

Let's give our new site a name.

Panelbear will show you a snippet of code to integrate with any web application framework.

Normally you just put this snippet on your HTML head section, but since there's an official Next.js integration, we'll use that instead. For now simply take note of your site ID (you can always find it later in your site settings page).

Simply install the following dependency on your project:

npm install @panelbear/panelbear-nextjs

This package includes a React hook that can be added to the lifecycle of your Next.js app. To do this, create a file in the pages directory of your project, and call it _app.js. The custom Next.js app is what controls the initialisation of each page, and it's always located at pages/_app.js.

For the purposes of this tutorial, it should have the following contents:

// ./pages/_app.js

import { usePanelbear } from "@panelbear/panelbear-nextjs";

function CustomApp({ Component, pageProps }) {

  // Load Panelbear on app init
  usePanelbear("YOUR_SITE_ID");

  return <Component {...pageProps} />;
}

export default CustomApp;

Now simply replace "YOUR_SITE_ID" with the site ID that we got from Panelbear earlier.

That's all that's needed! Next, let's try it locally.

Test the analytics locally

By default, Panelbear does not track events in localhost to prevent using up your plan quota. When you enable debug mode, it will send the events and also log them to the console. Just don't forget to disable it again when deploying to production.

Tip: You could also set the debug option based on an environment variable such as NODE_ENV or load it from a configuration file - it's completely up to you!

This is what your pages/_app.js file should look like at this point:

// ./pages/_app.js

import { usePanelbear } from "@panelbear/panelbear-nextjs";

function CustomApp({ Component, pageProps }) {

  // Load Panelbear on app init
  usePanelbear("YOUR_SITE_ID", {
    debug: true
  });

  return <Component {...pageProps} />;
}

export default CustomApp;

Since we made changes to our Next.js main app, we'll need to restart the development server. Let's do that and refresh the page at http://localhost:3000/. If you open the console, you should see that an event is being triggered.

Also, if you now head to the Panelbear dashboard, you should see the page impression appearing shortly after it happened.

You can also simply click on anything to filter for it. For example, on a dashboard with a lot of data I can filter for visits coming from the United States who found my site via Google.

That's great! Next let's review some useful features we could make use of in our application.

Track custom events

A really useful feature available in Panelbear is being able to record custom events. Events are simply data points collected during a visit. For example, a Pageview is the most common type of event, but you could also track Signup events or ButtonClick events if you wanted.

To send custom events, all you have to do is to call the Panelbear.track(...) function anywhere in your client-side code.

For example, here's how you would record a NewsletterSignup event as a form submit.

import * as Panelbear from "@panelbear/panelbear-js";
import { useState } from "react";

export function SignupForm(props) {
  const [email, setEmail] = useState("");

  const handleSubmit = (event) => {
    event.preventDefault();

    // Handle form submit
    alert(`Handling newsletter signup: ${email}`);

    // Record custom event on submit
    Panelbear.track("SignupNewsletter");
  };

  return (
    <form onSubmit={handleSubmit}>
      <label>
        Email:
        <input
          type="text"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
        />
      </label>
      <input type="submit" value="Submit" />
    </form>
  );
}

Notice it's simply a matter of calling the function with the desired event name.

Here's what custom events look like on one of my dashboards:

What's interesting is that you can filter for one of them - say newsletter sign ups - and plot the conversion rate over time. For example:

You can use custom events for pretty much anything you can think of, but most applications use it to track product-related metrics (eg. signups, modals, which features are being used the most).

Monitor your app usage and performance

Out of the box, Panelbear records usage and performance stats on every visit. These stats include things such as the session country, referrers, page load time, and various timings such as time spent on the frontend, backend and network.

For example, here's what one of my site's performance dashboard looks like:

The data collection approach uses no tracking cookies, there's no way to trace the session data back to an individual, and Panelbear is funded by paid subscriptions, not by selling personal data to anyone.

To achieve this, all interactions made by a visitor are stripped out of personal data and grouped into short lived sessions. These sessions are isolated per site, only collect what is necessary, and automatically expire after a short period of inactivity.

Anonymizing specific URLs

Panelbear already strips out the most common places where sensitive data appears. Things like the IP-address, cookies, query parameters, and various other data points are already handled.

However, sometimes there's sensitive data being reported in the page URL. For example, in user setting pages such as /users/123456789/settings , the user ID is clearly visible in the page URL which will appear on the analytics dashboards. This could leak information about the session and some of the interactions this visitor performed on our site.

To modify the event data before it even reaches Panelbear's servers, we can make use of the beforeSend feature on the tracking snippet. It's a small hook that lets you transform or filter out events right before being sent.

Let's add this functionality to our Panelbear hook in the pages/_app.js file.

// ./pages/_app.js

import { usePanelbear } from "./../hooks/panelbear";

function CustomApp({ Component, pageProps }) {

    usePanelbear("YOUR_SITE_ID", {
        // Enable debug mode to send events locally
        debug: false,

        // Transform events before sending
        beforeSend: function (event) {
            if (event.url) {
                // Replace user ID with placeholder
                let match = /.*\/users\/([a-z-A-Z0-9]*)(\/.*)/gm.exec(event.url);
                if (match && match[1]) {
                    event.url = event.url.replace(match[1], "user_id");
                }
            }
            return event;
        }
    });

    return <Component {...pageProps} />;
}

export default CustomApp;

This will check if the event has a URL component, and try to search and replace user IDs into some placeholder value. For example, the /users/123456789/settings URL from earlier will be reported as /users/user_id/settings instead.

Receive alerts when something's up

Now that we have set up analytics and performance monitoring on our Next.js app, let's configure some alerts to get notified when our site is getting increased traffic.

But first, we'll need to configure a couple of notification channels. These are the integrations that should be notified when any alert triggers. It could be anything from the email of the marketing team to a Slack or Discord channel.

To do so, simply head to your Account Settings and click on Integrations.

Next, you can add any integrations you wish. For example you could use the email notification to send alerts to a "developers" or "on-call" team inbox, or you could even add a Slack or Discord channel dedicated to alerts - it's completely up to you!

Finally, now that we configured a couple of integrations let's setup our first alert. Simply go to the Alerts tab on your website's dashboard and click on New Alert.

You should now configure the alert to trigger when the number of visits in the past hour exceeds a desired threshold. You should also pick one or more integrations that should be notified.

Save it, and we’re done! In order to test the alert, you can click on the "Test" button to send an example alert.

You can of course create more alerts and different notification channels. Optionally you can also create page speed alerts, it's not only limited to traffic spikes.

Where to go from here

We've covered how to set up traffic and performance monitoring for our Next.js app. Additionally we saw how to track custom events, and anonymize sensitive pages to protect visitor privacy.

Of course, there's plenty more we could monitor about our application. For example there's uptime monitoring, runtime errors, and perceived performance with Core Web Vitals.

You can monitor pretty much every aspect about your application, and there's hundreds of tools available. That's why I also wrote a guide on the various website monitoring tools available, feel free to check it out too.

I hope you enjoyed this post, and it comes useful to you. Have any comments or questions? Feel free to shoot me a message on Twitter - I'm happy to help.

A Tour of Website Monitoring Tools

anthonynsimon — Fri, 06 Aug 2021 16:11:05 +0000

How would you know your website or app is running smoothly if you're not even looking for problems? Without monitoring software you're essentially flying an aircraft without navigation instruments.

That's why, whether you're just getting started, or running a mission-critical website, you'll probably want some form of monitoring in place to ensure things are working as expected, and to continuously improve your end-user experience.

In this article I'll be walking you through the various types of frontend monitoring tools out there, and how they can help you ship better software.

Error tracking and crash reporting

Error tracking software lets you identify and troubleshoot runtime issues for your application. It works by installing an agent in your application which then listens for errors in the background, and sends them to a backend service for aggregation and alerting you when something's up.

Sentry is a great option for surfacing and troubleshooting errors.

This type of monitoring software has been incredibly useful to me. It has helped me spot countless bugs in the past that would only surface during real world usage and the testing suite completely missed.

When it comes to privacy, many of them offer anonymization features which can either redact or completely drop information from an error which can potentially identify a user.

There's many alternatives, some even open source in case you're looking for self hosted software. Here's some of my personal picks:

Sentry, well known for its open source offering and my current tool of choice for error tracking. It's more than just error tracking, since it also includes things like performance monitoring and distributed tracing.
Honeybadger, it also bundles additional features such as uptime monitoring which can come quite handy if you're looking for this combo.
Rollbar, another great alternative which is quite popular with enterprise companies.

Synthetic monitoring

Synthetic monitoring refers to a set of tools which automatically perform checks on your website or API at regular intervals - say, every minute- and notify you when something might be off.

Transaction monitoring on Checkly.

These tools include everything from uptime monitoring services to load testing software to transaction monitoring to security scans.

They're commonly used since it's usually the most straightforward way to know if your website is down, perform benchmarks, measure SLAs and even perform end-to-end tests on user transactions (eg. arrive on the landing page, go to the signup page, submit form).

The tool you need depends on which checks you're looking to automate, but I'll mention some of the alternatives:

NodePing, a less known website monitoring service, but previous teams I've worked at used to monitor some pretty mission-critical sites and it was rock solid throughout the 5 years we depended on it. Not affiliated in any way, just happy with their service.
Cronitor, while focused on cron job monitoring, also includes uptime monitoring for websites, APIs, S3 Buckets and more.
Better Uptime, one of the newer alternatives, combines incident management and monitoring in one tool.
Uptime Robot, a very popular uptime monitoring service with a free plan.
Checkly, automated end-to-end testing of website or API transactions. Integrates with CI workflows on GitHub and has a generous free tier.

In addition to these there's plenty others, sometimes larger platforms include uptime monitoring too, for example New Relic and Datadog both have some of these features built-in.

Marketing analytics

Marketing analytics software gives you reports and statistics to help you understand where visitors are coming from, which pages they visit, and which marketing efforts convert better.

Google Analytics is a well-known marketing analytics solution.

They're commonly used by marketing professionals, rather than product development teams, but since most website owners want to measure basic metrics such as unique visitors, top pages and referrers, they're used quite extensively across the web.

There's plenty of tools in this space, which deserve their own blog post, but here's some alternatives to get you started:

Google Analytics, a well-known analytics product. It offers hundreds of metrics and reports, and while it's free to get started it can get prohibitively expensive once you reach a certain level of traffic.
Matomo, a popular open source alternative to Google Analytics. You can either self-host or let them manage a cloud instance for you.
Plausible, another open source alternative, but focused on privacy. Their cloud offering is affordable and based in the EU.
Splitbee, focused on simple analytics while offering some distinct automation and conversion optimization features.
Fathom, a well-known alternative with a focus on simplicity and privacy.
Simple Analytics, a popular alternative from the Netherlands with some pretty distinctive features such as a "tweet viewer" and social share banners. Also highly focused on privacy and simplicity.
Panelbear, while it's not entirely focused on being a marketing analytics tool, I think it's a great alternative if you're looking for analytics without cookies. Full disclosure: I'm currently building this tool. In case you check it out, let me know what you think!

Product analytics

Product analytics is often confused with marketing analytics software. The difference is that product analytics helps you understand how your website or app is being used in terms of its features, while marketing analytics focuses on giving you statistics about how visitors arrive at your website and which content is most engaging.

Amplitude is a popular product analytics tool.

For example, product analytics would be best if you want to track which product features are being used, identify user experience problems, and which customers are most likely to churn based on their usage.

This information helps product teams make decisions on how to improve on existing features or what to build next. Without it, it's difficult to understand what's working and what isn't about your product.

Here's a list of product analytics software that is used quite often:

Mixpanel, a very popular tool focused on event and conversion tracking. Something interesting is that they have an EU Data Residency program, which lets you pick whether to store the data in the US or Europe to simplify compliance.
Heap, a cool feature is that integrating it on your website is relatively simple, it just tracks every interaction so you can more easily understand product usage with little effort.
Amplitude, another popular alternative which focuses on segmentation and user journeys. It groups similar to users so you can analyse usage patterns rather than individual actions.

Application performance monitoring (APM)

Application performance monitoring tools help you debug issues and identify performance bottlenecks. Many of these tools can trace request timings from the frontend to the backend and all the way to the database requests.

If you're using the ELK stack you might want to check out the Elastic APM.

These traces can be valuable if you're trying to understand which requests are slowing down your application, and whether the bottleneck is the frontend, network, backend or the database.

Which one works best for you depends highly on how detailed you want these metrics to be. There are countless tools, both SaaS and open source which can help you here, with varying levels of complexity and cost.

Here's some of the commonly used APM software I've encountered with in the wild:

Sentry, while Sentry is well known for its error tracking product, they recently released performance monitoring features which pair well with the rest of their offering. I've been testing it for a few months now and I like what I see.
Elastic APM, from the guys behind Elasticsearch and Kibana, it's a popular open source stack for logs and metrics which includes an APM product.
New Relic, their APM is one of the most popular out there and integrates well with the rest of their stack.
Datadog, this one is among my favourites. It's a comprehensive product with lots of integrations, which has served the teams I've worked with well over the years.

Real user monitoring (RUM)

Real user monitoring measures your application's usage and performance from the perspective of your end users. It's sometimes also called browser monitoring, since it can detect performance issues, Javascript errors, and other on-device information.

Panelbear provides traffic and performance insights in a simple dashboard.

Why should you care about this? It's tempting to think that access logs or measuring response times on your servers is enough, but that's only half the picture. Your end user's device, connection speed, and geographical location play a vital role in your application's real performance.

Metrics such as browser timings, the page load time, and new standards such as Core Web Vitals are best measured from the perspective of the end user under real world conditions. It's about understanding the end-to-end experience, and what your real users perceive as opposed to testing things on a powerful development workstation.

Here's some great alternatives to consider if you're looking to add real user monitoring to your application:

SpeedCurve, while it's mainly focused on performance metrics, it's a solid product with some unique features such as page load filmstrips.
Datadog, I've used it for several years and it's honestly great. It can get a bit expensive, but they also offer so much more. It's a complete monitoring platform.
Raygun, which also offers others error reporting and an APM product.
Pingdom, while it's mainly known for its uptime monitoring service, it also offers a RUM product.
Panelbear, it includes real time traffic and performance insights, and it's free to get started. Again, I'm building this tool, and while it's still in the early stages, I'm happy to hear what you think!

Conclusion

While some teams do just fine using marketing analytics software - such as Google Analytics - it's not enough to get a complete picture over your application's usage, performance, and uptime.

At some point, most teams rely on some combination of monitoring tools which help them build and improve their software over time.

I hope this guide helped paint a more complete picture of the frontend monitoring landscape. Did you enjoy it? You can find me on Twitter in case you have any questions or comments.

An Introduction to Core Web Vitals

anthonynsimon — Wed, 28 Jul 2021 15:38:23 +0000

Ever noticed that some websites appear to load quickly, but then suddenly become unresponsive when you try to click on a button or image? Turns out, page load time is not the only metric that matters when it comes to delivering a great end-user experience.

In the past, website owners relied on technical measurements such as the page load time to understand how fast a website loads on a visitor's device. Site speed is a useful metric to track, but does not tell the full story when it comes to user experience.

For example, even though the page might have loaded quickly, it's likely the visitor would be frustrated when multiple popups suddenly appear and block the view of the main content. A frustrated visitor is more likely to leave, regardless of the quality of the content in the website, as it matters more than ever how pleasant it is to use a website.

Web Vitals are a set of standardised metrics proposed by Google, that help understand how visitors are really experiencing a website, rather than relying on performance scores and artificial benchmarks.

Core Web Vitals

While Web Vitals consist of various different metrics, let's explore a subset of them called Core Web Vitals. These are three metrics that tend to have the largest impact on user experience, and the ones which I'll focus on for this purposes of this article:

Largest Contentful Paint (LCP), how fast the main content on a website loads.
First Input Delay (FID), how quickly can a visitor start interacting with a site.
Cumulative Layout Shift (CLS), how visually stable is the website layout as content loads.

Largest Contentful Paint

Largest Contentful Paint (LCP) is a metric that measures how long it takes for the main piece of content to load on the screen, as opposed to the time it took for the entire page to load.

It's different from the page load time, as it measures what the visitor perceives instead of the actual number on paper. For example, while a page might load in 5 seconds, the main piece of content, such as a big image, or block of text might have already loaded 2 seconds in. That means that the remaining 3 seconds are just spent on loading secondary content which does not prevent the visitor from already looking at the site.

What exactly is the main piece of content depends on the page in question. Most tools that measure this metric will automatically identify the largest block of content presented on the website as it loads.

Things that might affect LCP include large images, video players, website backgrounds, large blocks of text, and other render blocking resources. Essentially, anything that might cover a large portion of the initial viewport.

It's generally a good idea to keep LCP within 2.5 seconds to ensure your website feels fast, and visitors don't leave while waiting for something to appear on screen. An LCP of 4 seconds or more is considered to lead to a poor experience.

First Input Delay

First Input Delay (FID) measures input delay. In other words, it measures how quickly a user can start interacting with a website, even if it’s still loading.

For example, maybe a page is still loading, but the visitor wants to click on a button or expand an image that is already visible on screen. There's no need to wait around in order to be able to perform an action. If the site immediately reacts to these interactions, it feels snappy and responsive.

Unlike the other two Core Web Vitals, FID is difficult to measure using "offline" tools. It's best to measure it using real-user monitoring tools. The reason being that it requires actual user input in order to measure it.

Field data tools (or real-user monitoring) perform continuous measurements on a website's live traffic, painting a much more accurate picture of a website's performance under real world scenarios.

That's why FID is best measured using field data tools, as it depends highly on what is being clicked, how much of the website has loaded so far, the internet connection speed, and various different scenarios which are not easy to replicate in artificial tests.

Google recommends a FID of 100 milliseconds or less, while an input delay larger than 300 milliseconds can lead to a poor user experience.

It may be tempting to try and reduce input delay to a minimum, but it's important to consider that there's a practical limit on how much better it can be. While most humans can notice the difference between 800 milliseconds and 100 milliseconds, a 10 millisecond difference might be just barely noticeable.

Cumulative Layout Shift

Cumulative Layout Shift (CLS) measures the visual stability of a website. In other words, it measures by how much the main elements shift around as the page loads.

To understand it, you have to put yourself in the shoes of the visitor. It can be highly frustrating when a button or image moves around while you're trying to focus on it. Even worse when you end up clicking on something you didn't want because the content moved around as the page continued to load. That's why striving for visual stability as the page loads is important.

CLS can be affected by lazy loading images, delayed popups, banners, and wrongly-sized placeholder blocks or images. Essentially anything that can cause significant layout changes as a page loads.

Keeping your CLS score to a minimum can greatly improve your website's usability. Google recommends a CLS of 0.1 or less, which can help reduce frustrated visitors which may just be leaving your site due to having a poor experience.

How do Web Vitals affect search ranking

Having a fast, responsive website is more important than ever. Besides leading to a better experience for your website visitors, search engines such as Google now officially use Web Vitals as a ranking signal.

This makes sense, search engines generally want to rank websites higher when they offer more relevant, useful content for a given user search. If the content is good, but the website which presents it is unusable or bounces off a lot of visitors, Google may interpret this as a signal that visitors are not satisfied with the proposed search result.

In other words, delivering a great user experience is just as important as having good, quality content. It's about the entire user experience, and optimising for it may help website owners get more relevant search traffic, and a higher ranking position.

How to measure Web Vitals

You can use a variety of tools to measure your Core Web Vitals. While some metrics are easy to measure using lab tools which perform checks in a simulated environment, some of them are best measured using real traffic samples of how visitors interact with each page.

The distinction between the two types of tools is in how they take the measurements. On one hand there is lab data (or synthetic monitoring), which performs checks in a simulated environment, and on the other hand there's field data (or real-user monitoring), which takes measures from the real visitor traffic on a website.

No tool will be best suited for every possible scenario, so it's advisable to start with the simplest ones and add more advanced monitoring and reporting as you actually need it.

To help get started, here's some of my favourite tools to measure Web Vitals:

Recommendations

Peter Drucker is often quoted as saying that "if you can’t measure it, you can’t improve it". The point being that you can't know with certainty whether something worked or not just by guessing. Without data, all we have are opinions, which may differ from the truth.

On that principle, the first step towards delivering a great experience on your website should be to start measuring the metrics that matter. That way you'll know where you stand, and whether any changes you perform have a positive effect on the end-user experience.

You can start by performing synthetic checks on your website using lab tools such as Lighthouse in order to understand the current state of your website.

Once you have identified existing issues, and possible improvements. You could add a monitoring solution, either lab-based (offline checks) or field-based (using real traffic), in order to continuously monitor the metrics that matter for you.

In order to achieve the best results, most websites use a combination of tools as part of their monitoring stack. It's often recommended to measure at least three things: overall visitor traffic, performance, and uptime. After all, you don't want to be the last to know when your website is trending, unresponsive, or even worse, having downtime.

Did you enjoy this article? Let me know if you have any questions or feedback. I hope it's been a useful introduction to Web Vitals and the different kinds of monitoring tools available for your website.