NOTE:

This is a continuation and a rework of the previous PR that had some unexplainable issues so I decided to rewrite it. I have opened this to rework it more carefully and take care of all the edge cases and random errors. (For more info, please refer to #25771)

NOTE 2:

The 70 docs commits are due to me forgetting to flush the original patch-9 branch when I was done with that one. I usually start these PR's remotely, which means I don't get to name them something unique, and I just got onto the github app to try and re-run the failed tests, which still had the old patch-9 commits. That's my bad. I used the origin's files in every conflict so it ended up just not changing anything (as can be seen in the files changed).

🔗 Linked issue

Related: #25771

❓ Type of change

• 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This is a PR that aims to improve both build time and runtime performance to the max by refactoring everything that comes to mind with performance best practices, some of which include smarter and fewer object/array iterations, reduced indexes, smarter variable usage for constant values, and more.

Some key improvements in this PR:

• Refactors of known costly javascript methods:
  In some places throughout the app, there are operations that rely on certain javascript methods that are known to be more expensive at certain conditions than manual implementation
  (similar to endsWith in perf(vite): rework endsWith to direct index #24746
  and startsWith in perf(kit, schema, nuxt): rework startsWith to direct index #24744).
  One key change under this category is the usage of Array.prototype.includes.
  Array.prototype.includes appears to be slower when checking for existence of a certain input between at the very least 2 elements than directly checking each element with strict equality (like when dealing with strings).
  After thorough benchmarking, both browser and node, direct comparisons showed marginally better performance, benchmarks attached below in that same order with the following benchmark:

  const a = "#text"
  console.time("start")
  for(let i = 0; i< 1000000; i++) {
    const inc = ['#comment', '#text'].includes(a)
  }
  console.timeEnd("start")
  console.time("stop")
  for(let i = 0; i< 1000000; i++) {
    const inc  = a === "#comment" || a === "#text"
  }
  console.timeEnd("stop")

  Browser:

  

  Node:

  

• Reduced and reworked iterations
  Originally the main change in this PR, many parts in nuxt involve some sort of array/object manipulations, and in some places they are either repeated, redundant, or simply costly in terms of performance. The main examples of such cases are the small side PR's I have submitted like perf(kit): avoid duplicate join operation #24717, perf(nuxt): avoid duplicate iterations over layers #24730, and numerous others. I couldn't get all of it at the same time so I have decided to group the rest here, and also handle the iteration logic as opposed to mere count.

• Reduced indexes:
  Some places in nuxt include working with indexes, like the length property of array/strings. While that alone isn't expensive, it still makes that repeated index, which especially with bigger inputs (like in HTML parsing or AST traversal) will gradually cost more and more microseconds, and might eventually become slightly noticeable in page performance.

• Early returns
  Similar to perf: don't manipulate an empty value #25647, there are some places where some iterations are made on potentially empty values, which increase the overhead and therefore decrease performance. This PR adds guards to ensure there won't be iterations over an empty value.

• Avoiding amortized operations where possible
  Methods like Array.prototype.push have an amortized complexity (O(1) in the case of push), which for the most part would serve most use cases well. But if we want to really fine-tune performance and take care of that amortization, we can remove them in favor of plain complexity if we know the size of the array. In multiple places around the Nuxt source, there are usages of push where the exact array size is known. This PR uses a hybrid approach that refactors said parts with known sizes by using the new Array(size) constructor with direct index modification, which would result in plain O(1) complexity, potentially outperforming the amortized O(1) complexity of push, while keeping push for dynamic arrays, variable sizes, and other parts where the size cannot be accurately obtained without causing increased time complexity (like Object.keys to obtain the size of an object).

📝 Checklist

• I have linked an issue or discussion.
• I have added tests (if possible).
• I have updated the documentation accordingly.