How to Reduce Unused JavaScript In Your PageBuilder Engine Bundle

Core Web Vitals metrics were created by Google to reward sites with more prominence in search results that follow certain web development practices. One metric that is included is Largest Contentful Paint (LCP). If this loading performance score is suffering, reducing code that isn’t even used can make the page feel faster for users, according to Google. First, we’ll look if your site is suffering from a slow LCP because of unused JavaScript. Next, we’ll discuss how to find the right solution for your team’s needs. Last, we’ll do the fun part of trying different strategies that fit with Arc’s Themes product. As an example, we’ll investigate what to do if a large library like Moment.js is included in the combinations/default.js file.

Run PageSpeed Insights

Google’s PageSpeed Insights (PSI) should be the first place you go. Go to Page Speed and copy-paste your site’s homepage in the input bar. (I’d also nudge you to bookmark this page.) After the inputted site and its real-life Chrome users’ experiences are measured, the tool will show recommendations for optimizing for Core Web Vitals as well as other metrics. For the purpose of this explainer, we’ll focus on LCP. As of June 15, 2021, PSI results looks like:

In the blue circle, you will see “Field Data” derived from real user experiences. In the orange circle, there is analysis of LCP of the page by Google’s Lighthouse tool. We’ll focus on improving the Lab Data with any solution. (Over time, Field Data may reflect a change.)

If LCP is not passing, we can investigate PSI’s recommendations then:

In the pink circle, you can select the opportunities relevant to optimizing for LCP. Then, in the orange circle, there’s the target audit for this document. To determine if this is related to PageBuilder Engine, expand the audit to check if combinations/default.js is one of the largest contributors.

To see an illustrated coverage per file, use the Dev Tools's coverage tool :

The red margin, circled in orange, shows which parts of the code are not used. In the Coverage tab, circled in blue, you can examine which other files may be unused after honing your investigation.

Now that we know a diagnosis, we can start looking for a solution.

Finding the right solution for your needs

Overall, I’ll recommend solutions that fit this example. However, these ideas are a good process for improving your site’s loading experience. We’ll need to think in terms of what amount of work this will involve versus the reward gained along with the scalability of that reward.

Replace with a native API

Many libraries were created before new functionality that’s now shipped in browsers existed. Even some libraries will recommend being replaced. Moment, for example, recommends the using modern browser and node’s Intl object (see Project Status).

For example,

moment(date).locale('es');

vs

new Intl.DateTimeFormat('es').format(date);

There are some limitations to customizing strings with the Intl object. But using functionality that’s already available is the most scalable option and the most light-weight.

Use an Arc-provided library

Using APIs provided by themes can be customized according to site and format. Plus, in this example, date-handling and formatting is already available and optimized for reducing unused JavaScript. see available APIs with blocks.json in your themes settings.

moment(date).locale('es');

vs

“dateLocalization”: {
  “language”: “es”
}
import { localizeDateTime } from '@wpmedia/engine-theme-sdk';

return localizeDateTime(date)

Arc is already optimizing based on the blocks.json picked. In this way, no additional timezones nor locales are shipped to the end user than necessary.

Arc already supports this library usage and will help you along the way.

Replace with a lighter library

Moment recommends its successor Luxon. According to its documentation, there is also a plugin to support timezones. However, we like Date-Fns for its light-weight size and readable documentation.

Migrating from one popular library to another one may be easier than other solutions. Yet there still may be some tradeoffs with size.

Use a postinstall script

If you do not want to migrate your current functionality, a more time-intensive and manual way to reduce size of a bundle is by utilizing a postinstall script. A postinstall script can remove node modules after packages are installed and before the bundle is compiled. During the post-install stage of npm a script can be configured to run within the package.json:

{
  “scripts” : {
    “postinstall” : “scripts/install.js”
  }
}

Here’s an example of one for reducing unused Moment timezones based on specifying the neededTimezone.

const fs = require('fs')
const timezoneData = require('moment-timezone/data/packed/latest')

const neededTimezone = 'Europe/Paris'
// remove all unused moment locales
const dirPath = 'node_modules/moment/locale/'
fs.readdirSync(dirPath).forEach(fileName => {
if (fileName === 'fr.js') return
fs.unlinkSync(`${dirPath}${fileName}`)
})

// remove all unused moment timezones
timezoneData.links = []
timezoneData.zones = timezoneData.zones.filter(value => value.startsWith(neededTimezone))
fs.writeFileSync('node_modules/moment-timezone/data/packed/latest.json', JSON.stringify(timezoneData, null, 2))

Conclusion

In conclusion, you can improve the search prominence of the site by reducing unused JavaScript if that is found to be an issue. Overall, most sites can be improved in this way. Yet it is one audit that can be improved without hurting your site’s features. Look into what’s important to your site and how it relates to Arc’s PageBuilder Engine when determining next steps. The library, like for dates, may already exist and be optimized for you.