10 Common Next.js Mistakes That Hurt Core Web Vitals - Pagepro

## Common Next.js Mistakes That Affects CWV ## Mistake 1: CSS-in-JS Runtime Overhead Let’s start with one of the most simple and widespread common Nextjs mistakes. CSS-in-JS libraries like Styled Components run JavaScript on the client to hash class names and inject styles into the DOM. Each injection causes browser style recalculation for the entire page, significantly hurting **LCP, FCP, and INP**. CSS-in-JS libraries introduce significant client-side overhead: - JavaScript runs in the browser. - Class names are hashed at runtime. - Styles are injected into the HTML dynamically. - Each injection triggers style recalculations. All of this happens during runtime and directly affects INP and FCP. Utility-first approaches like Tailwind avoid this problem by compiling a single CSS file at build time, with no runtime JavaScript and no client-side style recalculations. ### Mistake 2: CSS Modules with Lazy-Loaded Components Even without CSS-in-JS, performance issues can appear when combining: - CSS Modules. - Lazy-loaded components. When a lazily loaded component is mounted, its styles are injected dynamically. If this happens during a user interaction (click, input, form submission), the browser must recalculate styles at a critical moment. This often leads to increased input delay and worse INP. This matters, because: - When a dynamically imported component imports CSS Modules, styles are injected on demand. - Each injection triggers expensive full-page style recalculation. - If this happens during user interaction (button click, typing), it increases **INP** significantly. … ### Mistake 3: Missing Dynamic Imports (next/dynamic) A common mistake is shipping too much JavaScript in the initial bundle. next/dynamic allows components to be loaded only when they are actually needed, which: - Reduces the initial bundle size. - Improves LCP, FCP, and INP. - Improves perceived performance. A typical example is modal dialogs. They are rarely visible on initial page load, yet often end up in the main bundle if dynamic imports are not used. … ### Mistake 4: Using Third-Party Font CDNs Web fonts loaded from third-party CDNs introduce a costly request chain: 1. DNS lookup. 2. Request for CSS with @font-face. 3. Request for the font files. Even on fast networks, these extra round trips add latency. **Key optimization recommendations: ** … ### Mistake 5: Not Using next/image Using regular <img> tags in Next.js means losing built-in image optimizations for the web. next/image provides: - Lazy loading by default. - Automatic image optimization. - Preloading for LCP images. - Responsive image sizes via srcset and sizes. Without proper sizes, the browser may download large desktop images even on mobile devices, which directly hurts LCP. … ### Mistake 6: Unoptimized Third-Party Scripts Many websites are bloated with third-party scripts, and the problem is rarely the scripts themselves, but **when and how they are loaded**. By default, the browser treats all JavaScript as equally important, which can easily block the main thread during critical rendering phases. To avoid this, Next.js provides fine-grained control over script execution timing. … next/script allows precise control over when scripts are loaded: - beforeInteractive – critical scripts - afterInteractive – analytics and widgets - lazyOnload – non-critical scripts - worker – heavy logic off the main thread Using the wrong strategy can severely impact INP and Total Blocking Time. … ### Mistake 8: Sending Too Much Data to the Client Any data passed to a client component is sent to the browser and parsed there. **Real-world example**: a page returning a 7 MB payload from getStaticProps, most of which was never used by the UI but still had to be transferred and parsed by the browser. **Rule: ** do as much filtering, mapping, and transformation as possible on the server. Send only what the component actually needs. … ### Mistake 9: Too Much Client-Side JavaScript Logic Excessive client-side logic such as filtering and sorting: - Slows down FCP and LCP. - Increases memory usage. - Forces repeated JavaScript execution. Even with React Compiler, memoization itself has a cost. If logic does not depend on browser APIs or direct user interaction, it should live on the server. ### Mistake 10: Heavy Middleware Logic Middleware runs on every request. Problems arise when middleware includes: - Large libraries. - Heavy imports. - Poorly tree-shaken dependencies. This increases TTFB, which directly affects both FCP and LCP. Middleware should do as little work as possible and import only what is strictly necessary.