Vite 4.3 Cold start is slower than Vite 4.2

[glekner]

Describe the bug

getting the following cold start in 4.3 - VITE v4.3.6 ready in 19148 ms Tried 4.2 and got VITE v4.2.2 ready in 2748 ms

Is there anything suspicious in our config? we are also using SWC.

Reproduction

no-repro

Steps to reproduce

No response

System Info

vite config

import reactPlugin from '@vitejs/plugin-react-swc';
import dotEnv from 'dotenv-flow';
import { compact } from 'lodash';
import { visualizer } from 'rollup-plugin-visualizer';
import { defineConfig, PluginOption, splitVendorChunkPlugin } from 'vite';
import checkerPlugin from 'vite-plugin-checker';
import comlink from 'vite-plugin-comlink';
import monacoEditorPlugin from 'vite-plugin-monaco-editor';
import preload from 'vite-plugin-preload';
import svgrPlugin from 'vite-plugin-svgr';

import { tunneledServicesProxyPlugin } from './config/tunneledServicesProxyPlugin';
import { watchGqlPlugins } from './config/watchGqlPlugins';

// Load environment variables from .env files, if they exist.
// Needed only for development, using `.env.*.local` files (usually not committed to git).
dotEnv.config();

// Temporary until we can figure out what's screwed up `import/no-cycle` - otherwise Vite takes forever to report on ESLint issues
process.env.DISABLE_ESLINT_NO_CYCLE_RULE = 'true';

/**
 * More docs here: https://vitejs.dev/config/.
 *
 * # Chunks & build-time memory management:
 * We do a bunch of things here and in the code to maintain sane(-ish) bundle-sizes.
 * This is because we both want to give a good UX to users, and also because having a single chunk with a lot of modules
 * means that during the build process we have to load the entire code into memory (unbundled, pre-compilation, unminified etc.)
 * which in some cases can cause an out of memory error (see https://github.com/vitejs/vite/issues/2433 for a related issue).
 * To combat that we split the code into multiple chunks, some of which are loaded on-demand, while others are loaded together with the main chunk.
 */
export default defineConfig({
  plugins: compact<PluginOption>([
    process.env.BUNDLE_SIZE_VISUALIZER === 'true'
      ? visualizer({
          open: true,
          sourcemap: true,
          filename: './build/stats.html',
        })
      : null,
    splitVendorChunkPlugin(),
    reactPlugin({
      plugins: [['@swc/plugin-styled-components', {}]],
    }),
    comlink(),
    svgrPlugin({
      svgrOptions: {
        icon: true,
      },
    }),
    checkerPlugin({
      // don't show overlay with error in browser.
      overlay: false,

      // check TS typing
      typescript: true,

      // Show eslint violations
      eslint: {
        lintCommand: 'eslint "src/**/*.{js,jsx,ts,tsx}"',
      },
      // don't check in build mode - we will do it in a parallel job
      enableBuild: false,
    }),
    {
      name: 'omit-monaco-editor-source-maps',
      renderChunk(code, chunk) {
        if (/(monaco)|(editor\.api)/i.test(chunk.fileName)) {
          return {
            code,
            // omit source maps for this chunk
            map: { mappings: '' },
          };
        }

        return null;
      },
    },
    monacoEditorPlugin({
      languageWorkers: ['editorWorkerService', 'json'],
      forceBuildCDN: true,
    }),
    preload(),
    process.env.EXPERIMENTAL_WATCH_GQL === 'true' ? watchGqlPlugins() : null,
    tunneledServicesProxyPlugin(),
  ]).flat(),
  resolve: {
    alias: {
      // some dependencies use `lodash-es`, but we use `lodash` because regraph requires it, so might as well deduplicate them
      'lodash-es': 'lodash',
      path: 'rollup-plugin-node-polyfills/polyfills/path', // monaco-languageclient depend on node's `path` and this is the recommended solution for that
    },
  },
  worker: {
    plugins: [comlink()],
  },
  server: {
    port: 8000,
  },
  build: {
    outDir: 'build',
    // output sourcemaps, but without "sourceMappingURL=" comments in the bundled files
    sourcemap: 'hidden',
    modulePreload: {
      // this is the default, but we use it - so explicitly declare it
      polyfill: true,
    },
    rollupOptions: {
      output: {
        // we have to use a function for vite's `splitVendorChunkPlugin` to work correctly (see https://cs.github.com/vitejs/vite/blob/2a9bc6dda4be0b8a0cdbcc20878c18197dabfc4e/packages/vite/src/node/plugins/splitVendorChunk.ts#L113)
        manualChunks: id => {
          // codemirror is a big package and you don't need it from the get-go, so move it to a separate chunk
          // this is not done using dynamic imports as those are harder to do, UX-wise, and caused some issues with how codemirror is implemented/structured.
          if (id.includes('node_modules/codemirror/')) return 'codemirror';
          /*           if (id.includes('node_modules/monaco-editor/'))
            return 'monaco-editor'; */

          // our svg icons are big, pretty much by definition. Bundling them up with the other code causes big chunks, slower builds (can't parallelize as much) and out of memory errors in build time.
          if (id.includes('node_modules/@fortawesome/') || id.endsWith('.svg'))
            return 'assets';

          return null;
        },
      },
    },
  },
});

### Used Package Manager

yarn

### Logs

_No response_

### Validations

- [X] Follow our [Code of Conduct](https://github.com/vitejs/vite/blob/main/CODE_OF_CONDUCT.md)
- [X] Read the [Contributing Guidelines](https://github.com/vitejs/vite/blob/main/CONTRIBUTING.md).
- [X] Read the [docs](https://vitejs.dev/guide).
- [X] Check that there isn't [already an issue](https://github.com/vitejs/vite/issues) that reports the same bug to avoid creating a duplicate.
- [X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to [vuejs/core](https://github.com/vuejs/core) instead.
- [X] Check that this is a concrete bug. For Q&A open a [GitHub Discussion](https://github.com/vitejs/vite/discussions) or join our [Discord Chat Server](https://chat.vitejs.dev/).
- [X] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.

[github-actions[bot]]

Hello @glekner. Please provide a minimal reproduction using a GitHub repository or StackBlitz. Issues marked with need reproduction will be closed if they have no activity within 3 days.

[patak-dev]

@glekner we'll need a reproduction to be able to work out this issue. Maybe you could also share the CPU profile of both cold start runs (using pnpm run dev --profile then p, a profile will be saved at your root) for reference here in case you can't find a way to reproduce it.