About Google's Page Experience Update & OneSignal's Web Push SDK
Tags: javascript, webdev, programming
Published: 2021-06-23 18:25:15

---
title: About Google's Page Experience Update & OneSignal's Web Push SDK
published: true
date: 2021-06-15 15:58:39 UTC
tags: javascript, webdev, programming
canonical_url: 
---

 ![About Google's Page Experience Update & OneSignal's Web Push SDK](https://onesignal.com/blog/content/images/2021/06/Google-page-experience-update-blog-post.png)

In November of 2020, Google announced [via their blog](https://developers.google.com/search/blog/2020/11/timing-for-page-experience) that a new metric is being added as a factor to the Google Search ranking — what they are calling the “page experience update.” This update will measure the quality of an experience a site provides to the end user and rank sites using this new factor. Core Web Vitals are at the very center of these new measurements.

Core Web Vitals are a set of [key metrics](https://web.dev/vitals/) that measure web app performance with a focus on the user experience. Currently, they consist of three primary metrics: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and First Input Delay (FID).

**Largest Contentful Paint** , or [LCP](https://web.dev/lcp/), is the load time for the web app up to a specific threshold of completeness. This threshold has been revised over the past few years, but the LCP focus speaks specifically to the user experience. Fast load times are critical to UX and LCP is a core metric to understanding user wait time.

**Cumulative Layout Shift** , or [CLS](https://web.dev/cls/), is defined as the extent to which the layout is required to shift during app interaction. Relayout is an expensive operation, and performant rendering minimizes layout changes.  It is weighted as five percent of the overall [performance score](https://web.dev/performance-scoring/#lighthouse-6) in Lighthouse.

**First Input Delay** , or [FID](https://web.dev/fid/), focuses on UI responsiveness to the user’s first interaction with the page.  This metric is impacted both by the page load, as well as the order of elements loaded, and the actions taken upon user interaction.

Each of these Core Web Vitals track and focus on the user experience.  When Google's search changes begin going into effect in June 2021, more performant sites will more easily climb in search rankings while less performant sites will be penalized.

We want to make sure that our web app developers are prepared to succeed and have taken steps to make sure OneSignal is streamlined and free of hiccups such as Cumulative Layout Shift issues.

## We’ve Eliminated Impacts to Cumulative Layout Shift

Previously, integrating the [Custom Link notification prompt](https://documentation.onesignal.com/docs/custom-link-prompt) button with OneSignal was causing any elements below it to shift slightly on page load (by several pixels). We have fixed this issue and made sure that using this feature will not result in any layout shift whatsoever.

To monitor CLS, we’ve introduced a PerformanceObserver into our SDK’s sandbox environment which is used in  SDK testing. The [PerformanceObserver API](https://developers.google.com/web/updates/2016/06/performance-observer) enables our team to log events that negatively affect user experience via CLS. This new API call helps us measure layout-shift of container elements for all of our prompts. This increases our confidence that our impact on CLS is negligible.

## Maintaining a Performant Web SDK

To minimize the impact of using the OneSignal SDK on page performance, the WebSDK was built from the very beginning with this in mind. The SDK is lightweight and loads asynchronously on websites — not impacting any of the other Core Web Vitals such as LCP and FID.

During the SDK development process, our CI guardrails help ensure that the SDK remains as small as possible. Whenever our CI detects the SDK bundle size to have exceeded our preset limits, the SDK rollout is halted until fixed. This may include a small limit bump to accommodate new features or a necessary reduction from refactoring existing SDK components to be lighter weight.

## Unused Javascript Opportunity

While the SDK is already performant, there is always room for improvement. One way we can further boost performance is by only loading what the integrating website needs. For example, if the site has not implemented the Category Slidedown prompt, any SDK code that makes this feature work can naturally be excluded.

<!--kg-card-begin: image-->

![About Google's Page Experience Update & OneSignal's Web Push SDK](https://lh5.googleusercontent.com/7kYtPS4BBEuQwk74L-KvOn-YF_fO3luWrkZMWhrl-S3Pe3X4_3b1GNZTXqrk4KTe4oQD814eaZOfphUWBEAdJfiRYu2fH7-l8A6GEzs8oOa84XA7udGcHY_XVjXzELOt5DGKdLWw)

<!--kg-card-end: image-->

The SDK’s modular design makes it possible to break up the SDK into smaller pieces that can be loaded if and only if they are needed. The same can be said about styles. While this functionality does not yet exist in the SDK, it presents an opportunity to further trim down load times and resource sizes which in turn helps OneSignal applications be more performant and edge out the competition in the Google Search Ranking arena.

### Additional Resources & Support

As you build your web apps with OneSignal and other SDKs and tools, keep the impact to Core Web Vitals in mind.  The [lighthouse-ci](https://github.com/GoogleChrome/lighthouse-ci) tool is an excellent way to prevent regressions and monitor performance in your Web Application.

Other [tools for measuring Core Web Vitals](https://web.dev/vitals-tools/) are available, and leveraging these tools is critical to building performant web apps.

At OneSignal, we’re taking similar steps to keep your apps snappy and your users happy. If you still have questions about our web SDK, reach out to us at **support@onesignal.com**.