[Bug]: The page.goto is extremely slow when specifying headless: 'new'.

[masa42]

Minimal, reproducible example

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({ headless: 'new'});
  const page = await browser.newPage();
  console.time('goto');
  await page.goto('https://www.google.com');
  console.timeEnd('goto');
  await browser.close();
})();

Error string

no error

Bug behavior

• Flaky
• PDF

Background

After upgrading the puppeteer version from 19.11.0 to 21.1.0, the execution speed of page.goto has become significantly slower.

Below are the results of comparing the execution speed of the above code for each version. The speed has become slower as the version has increased.

• puppeteer:19.11.0
  goto: 1.374s

• puppeteer:20.0.0
  goto: 6.363s

• puppeteer:21.1.0
  goto: 14.259s

Expectation

I expect the page.goto to complete within 2 seconds.

Reality

The execution of page.goto takes more than 10 seconds.

Puppeteer configuration file (if used)

No response

Puppeteer version

21.1.0

Node version

v16.14.2

Package manager

npm

Package manager version

8.5.0

Operating system

macOS

[github-actions]

The issue has been labeled as confirmed by the automatic analyser.
Someone from the Puppeteer team will take a look soon!

---

Analyzer run

[OrKoN]

I am not able to reproduce. As the goto method waits for the page to load, are you sure the delay is not caused by unstable internet connection? or perhaps something else blocking the load process?

# new-headless
❯ node gotoGoogle.cjs
goto: 370.62ms
# old-headless
❯ node gotoGoogle.cjs

  Puppeteer old Headless deprecation warning:
    In the near future `headless: true` will default to the new Headless mode
    for Chrome instead of the old Headless implementation. For more
    information, please see https://developer.chrome.com/articles/new-headless/.
    Consider opting in early by passing `headless: "new"` to `puppeteer.launch()`
    If you encounter any bugs, please report them to https://github.com/puppeteer/puppeteer/issues/new/choose.

goto: 355.882ms

[masa42]

Thank you for your reply.
The network communication is stable, and there are no signs of the load process being blocked.
The phenomenon of the execution speed changing when altering the puppeteer's version consistently reproduces in my local environment.
Also, I confirmed that it does not reproduce on Ubuntu.
I had a colleague who was working elsewhere check the behavior on an M1 Mac, and it reproduced on 2 out of 3 devices, while it did not reproduce on 1 device. Therefore, there may be some special conditions involved.

[OrKoN]

I have also tried on M1 Mac and it does not reproduce.

[masa42]

Thank you for your reply.
Upon further investigation,
I found that chrome-mac-x64 is slow, whereas chrome-mac-arm64 is fast.
node v20.5.1: x64 -> chrome-mac-x64 -> 10.292s #Using Rosetta technology.
node v19.9.0: arm64 -> chrome-mac-arm64 -> 635.419ms

Below is the investigation log.

% nodebrew use v20.5.1                                        
use v20.5.1
% node -p process.arch 
x64
% npm uninstall puppeteer                                     

removed 109 packages, and audited 1 package in 426ms

found 0 vulnerabilities
% npm i puppeteer                                             

added 109 packages, and audited 110 packages in 8s

9 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
% node -e "console.log(require('puppeteer').executablePath())"
/Users/testuser/.cache/puppeteer/chrome/mac-116.0.5845.96/chrome-mac-x64/Google Chrome for Testing.app/Contents/MacOS/Google Chrome for Testing
% node index.js                                               
goto: 10.292s


% nodebrew use v19.9.0                                        
use v19.9.0
% node -p process.arch                                        
arm64
% npm uninstall puppeteer                             

removed 109 packages, and audited 1 package in 203ms

found 0 vulnerabilities
% npm i puppeteer                                             

added 109 packages, and audited 110 packages in 686ms

9 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
% node -e "console.log(require('puppeteer').executablePath())"
/Users/testuser/.cache/puppeteer/chrome/mac_arm-116.0.5845.96/chrome-mac-arm64/Google Chrome for Testing.app/Contents/MacOS/Google Chrome for Testing
% node index.js                                               
goto: 635.419ms

[OrKoN]

Rosetta is known to be slow as it's an emulation mode. I guess there is a mismatch between cpu architectures in the binaries, for example, we have no arm64 binaries for linux.

[OrKoN]

Ah, sorry, I incorrectly assumed Docker is used here.

[OrKoN]

Is it possible to turn off Rosetta?

[connorjclark]

FYI in Lighthouse we detect the rosetta case (using x64 node to launch chrome results in launching x64 chrome under rosetta emulation, instead of the arm64 chrome in the universal app bundle...) and throw an error, as the performance hit is substantial: GoogleChrome/lighthouse#14288

Chrome has since added a error message in the logs to call out this scenario: https://bugs.chromium.org/p/chromium/issues/detail?id=1305353

Perhaps Puppeteer could do something similar.

[masa42]

I turn off Rosetta and installed Node for arm64. After that, I resolved the issue by reinstalling puppeteer. Thank you for your response and advice. I appreciate it.

[OrKoN]

Thanks, @connorjclark, I think we should do the same.

[mschmiedel]

I am not sure what is happening here, but it seems like there is a performance issue with version 21.1.0. In our case, tests are taking more or less twice as long with 21.1.0 than with 21.0.0, this happens on freshly generated docker runners in a cloud environment (arm64 architecutre for sure!). Switching versions in our setup makes this 100% reproducible...

[drago-do]

I had the same issue when loading local pages. It turned out it couldn't find a page resource (an image), which was causing the delay. I simply corrected the local path to my image, and it worked. I'm not familiar with how Puppeteer works, but this fixed the problem for me. It went from 22 seconds to 1 second.

[activeliang]

thx~