Schema App JavaScript Deployment Overview

Modified on Mon, 06 May 2024 at 12:38 PM


Among the Schema App integration options, the primary method of deploying Schema Markup is through a JavaScript library, highlight.js. Once the JavaScript is integrated, it deploys markup to:

  • Single URLs authored through the Schema App Editor
  • Multiple URLs configured in Schema App’s Highlighter

Schema App's Highlighter templates map HTML elements to types and properties on page load, generating and rendering markup dynamically. 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.

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 Methods

Schema App provides multiple JavaScript Integration Methods. In addition to directly including the JavaScript library in your page templates, you may use Tag Managers such as:

Over time, Schema App continues to add 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
  • Minimal impact to page performance
  • Access to features like Linked Entity Recognition and Conditional Tags

JavaScript Deployment Settings

To further reduce the JavaScript's impact on end user's Schema App offers the ability to deploy markup to Robots Only. No modifications to scripts are needed as this is controlled from within Schema App. This is recommended to enable by default since Structured Data isn't important for normal web users and even with our optimizations the markup has some impact in render blocking time, see the section "JavaScript Page Impact". If you'd like to learn more about how Robots only works we have a separate article on the subject. Below we will show the difference Robots only makes on a typical web user vs a search engine loading your pages. Below we will compare the impact of adding highlight.js with Robots only for a non search engine user. 

From the above the script adds ~1ms to the scripting time and this is from the async script loading that does not impact user interaction. In mamy cases it will not impact the scripting time metric at all as it typically takes less 1ms to evalute the script. Schema App is loading an empty script for non robot users so it will not take any actions, therefore there is no render blocking impact at all. 

JavaScript Page Impact

Render Blocking Time

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. 

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 requests (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.

Impact on page performance 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.


Comments on Impact

First Paint

Highlight.js does not impact this metric.

By loading the script asynchronously it will load in the background and not block other elements.

First Input Delay

Highlight.js has some impact on this metric.

It block when it executes (see table below).

Time to First Byte

Highlight.js does not impact this metric.

Largest Contentful Paint 

(render time of largest visible image/ text block, relative to when page first started loading)

Highlight.js does not impact this metric.

It does not affect the appearance of your pages.

Total Rendering Time Impact of JavaScript 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 JavaScript integration methods available with Schema App.  We’ve outlined some of these considerations in the Pros and Cons below. 

For a comprehensive comparison of all integrations, see Performance Impact of Integration Methods.

Rendering Time
JavaScript Rendering/ Tag Manager+ Immediate updates to markup
+ Durable (most commonly used)
- AMP third party JavaScript not supported• Initial attempt: 5-20 ms
• Retries: 3-5ms
• Tested example total time: 5-35ms
JavaScript Rendering \ Tag Manager + Robots Only Enabled+ Immediate updates to markup
+ Durable (most commonly used)
+ Very little impact to non robot (search engine) users 
- AMP third party JavaScript not supported
Loading the minimal script ~ 1ms
JavaScript + Caching+ Quick loading markup for slower page speeds
+ Nearly up-to-date markup (real time - 1 page load)
+ Content loaded from Schema App's CDN (no requirement for Webhooks)
- AMP third party JavaScript not supported
- Updates less frequently than JavaScript rendering
• Load cached JSON-LD: 1-3ms
• Initial attempt: 5-20ms
• Retries: 3-5ms
•Tested example total time: 5-35ms
JavaScript + Webhook Hybrid+ Nearly up-to-date markup (real time - 1 page load)
+ Supported by Schema App CMS integrations
+ Supports AMP
- Requires backend integration (unless using Schema App CMS integration, e.g. WordPress)• Initial attempt: 5-20 ms
• Retries: 3-5ms
• Tested example total time: 5-35ms

NOTE: JavaScript may not be the best integration option for websites with existing page performance issues. If the JavaScript options outlines above do not provide an adequate solution, you may want to consider the Crawler + Server-side Integration.

Rendering Time

Crawler + Server-side Integration

+ Fastest HTML rendering
+ Schema App pre-generates data with crawler
+ Supports AMP
+ Supported by Schema App CMS integrations
- Requires backend integration (unless using Schema App CMS integration)

- Less frequently updated schema markup (weekly)

• 0 ms

Our Testing Approach

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

  1. 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).

  2. For each URL, open an incognito session in your Google Chrome, and navigate to the Performance tab in Developer Tools 

  3. Go to and copy all the content on the page

  4. Press the record button in the top left, and paste the contents of highlight.js into the console below.

  5. Monitor the console to see when the markup has been logged (i.e., at the sendPageStateToFirehose() step), and stop recording.

  6. 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().

  7. Repeat steps 3-5 a few times for each URL you test, and record the average of each URL.

  8. Collect each result and calculate the average overall.

    If you're interested in assessing the impact of Schema App on page speed, you can go to the Performance tab and click the "Reload" button. Once the run is complete, go to the Bottom-Up tab and search for "Highlighter". The highlight.js activity will show you the total time.

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.

  1. 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. 

  2. Avoid marking up slow-loading content such as widgets and embedded reviews.

  3. 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). 

Additional Resources

Javascript Integration through Tag Manager


Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select atleast one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article