Schema App JavaScript Page Impact Overview

Modified on Tue, 21 Mar 2023 at 04:47 PM

Introduction

At Schema App, we integrate with your website to add structured data. We know that part of your consideration on integration methods is the page performance impact or what is more specifically called impact to rendering time. To help you with this decision, we’ve put together details on how our JavaScript works and the impact to common metrics. We’ve also included the test results we’ve done to help estimate the impact to your page.

Schema App JavaScript Overview

Among the Schema App integration options, the primary method of deploying Schema App Highlighter markup is through a JavaScript library Highlight.js. Highlight.js deploys markup configured in Schema App’s Highlighter by mapping HTML elements to schema.org markup. The library runs on page load, generating and rendering the markup.

Highlight.js and its data is loaded asynchronously and does not impact the customer experience, specifically the First Paint, Time to First Byte, Largest Contentful Paint. The script is designed to run in the background and does not block other browser requests on page load, allowing browsers to load other resources at the same time. When the script executes its functionality, render blocking time, does have some impact on First Input Delay.

JavaScript Integration Method

In addition to directly including the JavaScript library in your page templates, you may use Tag Managers such as Tealium, Adobe Tag Manager or Google Tag Manager to add the JavaScript highlight.js to your website. Over time, Schema App is adding CMS plugins with options to integrate JavaScript as well.

When choosing your integration method, you should consider some of the benefits that Schema App offers through our Javascript, such as: availability of markup for Google’s robots (or other crawler consumers), the immediacy of the markup when content changes, and its impact to the page.

What is the actual impact? Render Blocking Time.

The highlight.js script blocks other components from rendering while it is building the schema markup JSON-LD. This is necessary because to evaluate xpaths we need to have the page in a steady state so any scripts mutating the DOM must be stalled otherwise we can’t accurately pull in the content you have marked up. When we say the script is asynchronous we are referring to how highlight.js is loaded and how highlight.js makes any network request (some examples are: the highlighter configuration, Linked Entity Recognition, and video markup). This means that while other scripts and items are loading on your page the highlight.js script isn’t blocking anything.

Will it impact page performance key metrics?

Below are some common metrics that are used to measure page performance. As a general rule of thumb the faster these metrics are the better highlight.js performs so it’s beneficial to our scripts as well if a site performs well. We try to reduce our impact but we do have some impact on certain metrics.

Metric	Comments on Impact
First Paint	Highlight.js will not impact this metric, by loading the script async it will load in the background and not block other elements.
First Input Delay	Highlight.js will have some impact on this measure because it does block when it executes (see table below)
Time to First Byte	Highlight.js will not have an impact on this metric.
Largest Contentful Paint (the render time of the largest image or text block isible, relative to when the page first started loading).	Highlight.js does not affect this metric because it does not affect the appearance of your pages.

Total Rendering Time Impact of Integration Methods

The way to read the numbers below is in terms of the total time the highlight.js will block DOM mutations. The number does not necessarily indicate it will block all at once, rather it will perform xpath evaluations and in between doing that, other scripts can execute. Similarly, the highlighter leaves a few hundred milliseconds in between its subsequent executions, allowing other scripts to execute. Subsequent executions will only have an impact if areas marked up have mutated or if highlights evaluated prior did not produce a value.

Below is the analysis of the different Integration methods available with Schema App. We’ve outlined some of these considerations in the Pros and Cons below.

At Schema App, we are committed to working with your teams to identify the best integration for your unique tech stack.

Integration Method	Pros	Cons	Total Rendering Time
JavaScript / Google Tag Manager	Immediate updates to schema markup Durable integration method (most commonly used)	AMP third party JavaScript not supported	Initial attempt: 5 - 20 ms Retries: 3-5ms Tested example total time: 5-35ms
JavaScript + Caching	Quick loading Schema Markup for slower page speeds. Nearly up to date schema markup (realtime - 1 page load) No requirement for Webhooks as content is loaded from Schema App's CDN.	AMP third party JavaScript not supported. Updates less frequently than the JavaScript Rendering option.	Loading cached Json-ld 1-3ms Initial attempt 5 - 20ms Retries 3-5ms Tested example total time: 5-35ms
Crawler + Server-side Integration	Fastest HTML rendering Schema App pre-generates data with a crawler Supports AMP Supported by Schema App CMS integrations	Requires backend integration (unless using Schema App CMS integration) Less frequently updated schema markup	0ms
Js + Webhook Hybrid	Nearly up to date schema markup (realtime - 1 page load) Supported by Schema App CMS integrations Supports AMP	Requires backend integration (unless using Schema App CMS integration)	Initial attempt 5 - 20ms Retries 3-5ms Tested example total time: 5-35ms
CMS Integrations
Drupal Module	Works with crawler and JavaScript	Requires IT setup	Tested example total time: <50ms
AEM Connector	Coupled with highlight.js enables fast markup delivery, server side. Automatic webhook setup.	Requires IT setup	Initial attempt 5 - 20ms Retries 3-5ms Tested example total time: <59ms
Wordpress Plugin	Automatic webhook setup	Requires IT setup	<10ms

Our Testing Approach

Below is the approach we took to measure the page speed impact.

Collect a sample of page URLs for various client sites that use Highlight JS, and a list that use Highlight JS + Caching (i.e. view the window.schema_highlighter contents in the console, and if it contains 'output:false' this is a JS + Caching page).
For each URL, open an incognito session in your Google Chrome, and navigate the Performance tab in Developer tools
Press the record button in the top left, and paste the contents of highlight.js into the console below.
Monitor the console to see when the markup has been logged (i.e., at the sendPageStateToFirehose() step), and stop recording.
Find the length in ms of each task performed by highlight.js by scrolling through the Performance tab timeline, and get the sum of each task. Please note that depending on the template and URL, there may be many additional calls to evaluateTemplates().
Repeat steps 3-5 a few times for each URL you test, and record the average of each URL.
Collect each result and calculate the average overall.

Ways to reduce page speed impact

If Highlight.js fails to match when evaluating a Highlighter template on the first attempt, the library continues to monitor the page in case the content is loaded asynchronously by JavaScript after highlight.js has run. In this process, there is a wait time that retries several times, decaying over time. This may cause an impact on page performance if the library needs to retry often. Here are a number of ways our Customer Success team reduces the number of retries, thereby reducing page speed impact.

Conditional tags: The use of conditional tags checks the existence of certain content before marking it up. If the content does not exist, the page is not marked up, and there will be no need for retries.
Avoid marking up slow-loading content such as widgets and embedded reviews.
Ensure markup is always up to date. If the content has been removed or the template for a page has been changed on the website, please notify your Customer Success Manager so we can remove the associated content. This can be found during Maintenance and Monitoring based on errors, warnings, or missing properties.

Where an initial attempt to evaluate Highlighter templates may take a given amount of time (e.g. 5 - 20ms), each retry duration would be a fraction of the initial attempt (e.g. 1 - 3 ms).