Repository: electron
Issue: [Bug]: dom-ready is too slow when open window with blob url
Labels: performance :checkered_flag:,bug :beetle:,component/node-integration,platform/all,status/confirmed,27-x-y,28-x-y,29-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

27.2.0

### What operating system are you using?

windows 11 & MacOS 14

### What arch are you using?

x64 & arm

### Last Known Working Electron version

E21

### Expected Behavior

dom-ready should be as fast as electron20 & electron21

### Actual Behavior

dom-ready is slower than electron20 & electron21

### Testcase Gist URL

N/A

### Additional Information

When we upgrade electron from 20 to 27.2.0, the dom-ready is too slow when call window.open in web. 
Here's the example code.

```javascript
 var blobData = new Blob([], { type: "text/html" });
 var blobUrl = URL.createObjectURL(blobData);
 var newWindow = window.open(blobUrl, '');
```

This issue currently only occurs in my company's code. It reproduces on the first open window after a reload but not subsequently. I have created a simple demo in which the issue cannot be reproduced. Here's the logs, it took about 7 seconds.
```
2024-01-24T16:13:51.896+0800 INFO: ELECTRON,[webContentsMonitor],[WebContents 4]: did-navigate {"url":"blob:https://app.ringcentral.com/7e7c4856-c58c-4965-8f3c-d788a1a57c39"}
2024-01-24T16:13:58.148+0800 INFO: ELECTRON,[webContentsMonitor],[WebContents 4]: dom-ready
```

After debugging, I found that the difference between Electron 20 and Electron 27 when calling window.open lies in the following function(`third_party/electron_node/deps/v8/src/execution/isolate.cc`).

```c++
void Isolate::CollectSourcePositionsForAllBytecodeArrays() {
  if (!initialized_) return;

  HandleScope scope(this);
  std::vector<Handle<SharedFunctionInfo>> sfis;
  {
    HeapObjectIterator iterator(heap());
    for (HeapObject obj = iterator.Next(); !obj.is_null();
         obj = iterator.Next()) {
      if (!obj.IsSharedFunctionInfo()) continue;
      SharedFunctionInfo sfi = SharedFunctionInfo::cast(obj);
      if (!sfi.CanCollectSourcePosition(this)) continue;
      sfis.push_back(Handle<SharedFunctionInfo>(sfi, this));
    }
  }
  for (auto sfi : sfis) {
    SharedFunctionInfo::EnsureSourcePositionsAvailable(this, sfi);
  }
}
```

Electron 20 does not call `EnsureSourcePositionsAvailable`, but Electron 27 does, indicating that `sfis` is not empty on Electron 27. When Electron 27 calls `EnsureSourcePositionsAvailable`, it triggers `parsing`, and most of the time is spent here. The dom-ready event only occurs after parsing is complete.

Currently, our workaround is to delete following code to resolve the issue.
`third_party/electron_node/src/api/environment.cc#308` 

```c++
  if (s.flags & DETAILED_SOURCE_POSITIONS_FOR_PROFILING)
    v8::CpuProfiler::UseDetailedSourcePositionsForProfiling(isolate);
```
Now that I have removed this code, I'm not sure what impact it might have. Can you please help take a look?