DEV Community

Jen C.
Jen C.

Posted on • Edited on

Optimize Core Web Vitals - FCP and LCP: Tree-shaking Lodash

#webdev #tutorial #frontend #webperf

Resources

What is lodash-webpack-plugin?

Why should not use lodash-webpack-plugin?

You-Dont-Need-Lodash-Underscore

What is Module Transpilation?

Next.js setup related

Next.js Module Transpilation

Your Lodash Tutorial: How To Import Lodash Libraries

Background

Currently lodash usage in the project leads to huge bundle size

import _ from 'lodash';
Enter fullscreen mode Exit fullscreen mode

Solution 1: replace lodash with lodash-es

Step-by-steps

Remove existing lodash related packages use yarn remove 

"lodash": "^4.17.21",
"lodash-webpack-plugin": "^0.11.6",
"babel-plugin-lodash": "^3.3.4",
Enter fullscreen mode Exit fullscreen mode

Remove lodash config from babel plugin 

"babel": {
    "presets": [
      [
        "next/babel",
        {
          "env": {
            "corejs": "3",
            "useBuiltIns": "entry"
          }
        }
      ]
    ],
    "plugins": [
      "lodash"
    ]
  },
Enter fullscreen mode Exit fullscreen mode

Update next.config.js

Add "lodash-es" to transpilePackages, for example,

module.exports = {
  transpilePackages: [

      ...,

    'lodash-es'],
}
Enter fullscreen mode Exit fullscreen mode

Errors and solutions

After switching to lodash-es, Jest unit test is executed and an error is reported 

Jest encountered an unexpected token

    Jest failed to parse a file. This happens e.g. when your code or its dependencies use non-standard JavaScript syntax, or when Jest is not configured to support such syntax.
Enter fullscreen mode Exit fullscreen mode

Image description

Root cause

Jest does not support ESM

Solution
  1. Switch back to lodash and tree-shaking by changing the import method, and add eslint rules to consist the use of lodash

Choose this solution

  1. use babel-jest to only transpile jest unit test codes?
  2. https://nextjs.org/docs/14/pages/building-your-application/testing/jest

However, this solution does not work

Solution 2: Replace the current lodash import method with the correct one, and add ESlint rules to standardize the correct use of lodash import

Steps

Update the lodash import usage in the project

Change from

import _ from 'lodash';
Enter fullscreen mode Exit fullscreen mode

To

import find from 'lodash/find';
Enter fullscreen mode Exit fullscreen mode

Add ESlint no-restricted-imports for lodash

Make sure your team follows the same way when importing lodash

Add below into eslint config

 "no-restricted-imports": [
      "error",
      {
        "paths": [
          {
            "name": "lodash",
            "message": "Import [module] from lodash/[module] instead"
          }
        ],
        "patterns": [
          {
            "group": [
              "lodash/set"
            ],
            "message": "Import [module] from lodash/fp/[module] instead"
          }
        ]
      }
    ],
Enter fullscreen mode Exit fullscreen mode

Remove unneeded babel-plugin-lodash

Run yarn remove babel-plugin-lodash to remove the library.

Remove configuration from Babel config plugin

...

"plugins": [
      "lodash"
    ]

...
Enter fullscreen mode Exit fullscreen mode

Top comments (1)

Collapse
 
__116c3f profile image
Михаил Терновецкий •

Thanks for the detailed overview. This kind of optimization is extremely valuable, especially when you're trying to create a website that's both high-performing and scalable.

Using full lodash imports can really bloat your bundle size — we’ve seen the same in our projects. When you're building a modern site or app, especially with frameworks like Next.js, keeping performance budgets tight is essential, and tree-shaking plays a critical role.

Switching to lodash-es makes sense from a bundling perspective, but the issues with Jest and ESM can be blockers in CI pipelines. That’s why we also chose Solution 2: modular imports like import debounce from 'lodash/debounce' plus ESLint restrictions to enforce consistency across the team. It’s a great balance between performance and stability.

If you're in the process to create a website or optimize an existing one — this is exactly the kind of small refactor that can result in better Core Web Vitals, especially FCP and LCP. Thanks again for sharing these links — especially the one to you-dont-need-lodash, it’s a solid resource when trying to go vanilla JS wherever possible.