Using evaluate should work:

console.log(await page.evaluate(x => x.value, fieldHandle)));

The timeout you specify here needs to be shorter than the default timeout.

The default timeout is 5000 and the framework by default is jasmine in case of jest. You can specify the timeout inside the test by adding

jest.setTimeout(30000);

But this would be specific to the test. Or you can set up the configuration file for the framework.

Configuring Jest

// jest.config.js
module.exports = {
  // setupTestFrameworkScriptFile has been deprecated in
  // favor of setupFilesAfterEnv in jest 24
  setupFilesAfterEnv: ['./jest.setup.js']
}

// jest.setup.js
jest.setTimeout(30000)

See also these threads:

setTimeout per test #5055

Make jasmine.DEFAULT_TIMEOUT_INTERVAL configurable #652

P.S.: The misspelling setupFilesAfterEnv (i.e. setupFileAfterEnv) will also throw the same error.

There may be a race condition in these two lines:

await page.click(SELECTOR_BOTON);
await page.waitForNavigation();

Sometimes navigation happens before page click resolved, sometimes after this. To avoid this effect, try to replace these lines with these ones:

await Promise.all([
  page.click(SELECTOR_BOTON),
  page.waitForNavigation(),
]);

The timeout you specify here needs to be shorter than the default timeout.

The default timeout is 5000 and the framework by default is jasmine in case of jest. You can specify the timeout inside the test by adding

jest.setTimeout(30000);

But this would be specific to the test. Or you can set up the configuration file for the framework.

Configuring Jest

// jest.config.js
module.exports = {
  // setupTestFrameworkScriptFile has been deprecated in
  // favor of setupFilesAfterEnv in jest 24
  setupFilesAfterEnv: ['./jest.setup.js']
}

// jest.setup.js
jest.setTimeout(30000)

See also these threads:

setTimeout per test #5055

Make jasmine.DEFAULT_TIMEOUT_INTERVAL configurable #652

P.S.: The misspelling setupFilesAfterEnv (i.e. setupFileAfterEnv) will also throw the same error.

Here is what worked for me. First, I clear all my buildpacks and then I added the puppeteer-heroku-buildpack and the heroku/nodejs one:

$ heroku buildpacks:clear
$ heroku buildpacks:add --index 1 https://github.com/jontewks/puppeteer-heroku-buildpack
$ heroku buildpacks:add --index 1 heroku/nodejs

Then, add the following args to the puppeteer launch function:

const browser = await puppeteer.launch({
  'args' : [
    '--no-sandbox',
    '--disable-setuid-sandbox'
  ]
});

Finally, deploy it back to Heroku:

$ git add .
$ git commit -m "Fixing deployment issue"
$ git push heroku master

the element is in an iframe. so first you need to get the frame and then select the element from that frame. You would typically do:

let iframeHandle = await page.$('#disneyid-iframe');
let frame = await iframeHandle.contentFrame();
let inputElement = await frame.waitForSelector('#did-ui-view > div > section > section > form > section > div:nth-child(1) > div > label > span.input-wrapper > input')
await inputElement.type('hello', { delay: 100 });

However, there is an issue with out-of-process frames, so you need to launch chromium with --disable-features=site-per-process. The following should work:

const browser = await puppeteer.launch({headless: false, args: ['--disable-features=site-per-process']});
const page = await browser.newPage();
await page.goto('https://fantasy.espn.com/basketball/team', {waitUntil: ['load', 'domcontentloaded','networkidle0']});
await page.waitFor(5000);
let iframeHandle = await page.$('#disneyid-iframe');
let frame = await iframeHandle.contentFrame();
let inputElement = await frame.waitForSelector('#did-ui-view > div > section > section > form > section > div:nth-child(1) > div > label > span.input-wrapper > input')
await inputElement.type('hello', { delay: 100 });

Iterating puppeteer async methods in for loop vs. Array.map()/Array.forEach()

As all puppeteer methods are asynchronous it doesn't matter how we iterate over them. I've made a comparison and a rating of the most commonly recommended and used options.

For this purpose, I have created a React.Js example page with a lot of React buttons here (I just call it Lot Of React Buttons). Here (1) we are able set how many buttons to be rendered on the page; (2) we can activate the black buttons to turn green by clicking on them. I consider it an identical use case as the OP's, and it is also a general case of browser automation (we expect something to happen if we do something on the page). Let's say our use case is:

Scenario outline: click all the buttons with the same selector
  Given I have <no.> black buttons on the page
  When I click on all of them
  Then I should have <no.> green buttons on the page

There is a conservative and a rather extreme scenario. To click no. = 132 buttons is not a huge CPU task, no. = 1320 can take a bit of time.

---

I. Array.map

In general, if we only want to perform async methods like elementHandle.click in iteration, but we don't want to return a new array: it is a bad practice to use Array.map. Map method execution is going to finish before all the iteratees are executed completely because Array iteration methods execute the iteratees synchronously, but the puppeteer methods, the iteratees are: asynchronous.

Code example

const elHandleArray = await page.$$('button')

elHandleArray.map(async el => {
  await el.click()
})

await page.screenshot({ path: 'clicks_map.png' })
await browser.close()

Specialties

• returns another array
• parallel execution inside the .map method
• fast

132 buttons scenario result: ❌

Duration: 891 ms

By watching the browser in headful mode it looks like it works, but if we check when the page.screenshot happened: we can see the clicks were still in progress. It is due to the fact the Array.map cannot be awaited by default. It is only luck that the script had enough time to resolve all clicks on all elements until the browser was not closed.

1320 buttons scenario result: ❌

Duration: 6868 ms

If we increase the number of elements of the same selector we will run into the following error: UnhandledPromiseRejectionWarning: Error: Node is either not visible or not an HTMLElement, because we already reached await page.screenshot() and await browser.close(): the async clicks are still in progress while the browser is already closed.

---

II. Array.forEach

All the iteratees will be executed, but forEach is going to return before all of them finish execution, which is not the desirable behavior in many cases with async functions. In terms of puppeteer it is a very similar case to Array.map, except: for Array.forEach does not return a new array.

Code example

const elHandleArray = await page.$$('button')

elHandleArray.forEach(async el => {
  await el.click()
})

await page.screenshot({ path: 'clicks_foreach.png' })
await browser.close()

Specialties

• parallel execution inside the .forEach method
• fast

132 buttons scenario result: ❌

Duration: 1058 ms

By watching the browser in headful mode it looks like it works, but if we check when the page.screenshot happened: we can see the clicks were still in progress.

1320 buttons scenario result: ❌

Duration: 5111 ms

If we increase the number of elements with the same selector we will run into the following error: UnhandledPromiseRejectionWarning: Error: Node is either not visible or not an HTMLElement, because we already reached await page.screenshot() and await browser.close(): the async clicks are still in progress while the browser is already closed.

---

III. page.$$eval + forEach

The best performing solution is a slightly modified version of bside's answer. The page.$$eval (page.$$eval(selector, pageFunction[, ...args])) runs Array.from(document.querySelectorAll(selector)) within the page and passes it as the first argument to pageFunction. It functions as a wrapper over forEach hence it can be awaited perfectly.

Code example

await page.$$eval('button', elHandles => elHandles.forEach(el => el.click()))

await page.screenshot({ path: 'clicks_eval_foreach.png' })
await browser.close()

Specialties

• no side-effects of using async puppeteer method inside a .forEach method
• parallel execution inside the .forEach method
• extremely fast

132 buttons scenario result: ✅

Duration: 711 ms

By watching the browser in headful mode we see the effect is immediate, also the screenshot is taken only after every element has been clicked, every promise has been resolved.

1320 buttons scenario result: ✅

Duration: 3445 ms

Works just like in case of 132 buttons, extremely fast.

---

IV. for...of loop

The simplest option, not that fast and executed in sequence. The script won't go to page.screenshot until the loop is not finished.

Code example

const elHandleArray = await page.$$('button')

for (const el of elHandleArray) {
  await el.click()
}

await page.screenshot({ path: 'clicks_for_of.png' })
await browser.close()

Specialties

• async behavior works as expected by the first sight
• execution in sequence inside the loop
• slow

132 buttons scenario result: ✅

Duration: 2957 ms

By watching the browser in headful mode we can see the page clicks are happening in strict order, also the screenshot is taken only after every element has been clicked.

1320 buttons scenario result: ✅

Duration: 25 396 ms

Works just like in case of 132 buttons (but it takes more time).

---

Summary

• Avoid using Array.map if you only want to perform async events and you aren't using the returned array, use forEach or for-of instead. ❌
• Array.forEach is an option, but you need to wrap it so the next async method only starts after all promises are resolved inside the forEach. ❌
• Combine Array.forEach with $$eval for best performance if the order of async events doesn't matter inside the iteration. ✅
• Use a for/for...of loop if speed is not vital and if the order of the async events does matter inside the iteration. ✅

---

Sources / Recommended materials

• Sebastien Chopin: JavaScript: async/await with forEach() (codeburst.io)
• Antonio Val: Making array iteration easy when using async/await (Medium)
• Using async/await with a forEach loop (Stackoverflow)
• Await with array foreach containing async await (Stackoverflow)

OK here's my take on this. Firstly, you're using the evaluate method incorrectly. Mainly because you don't actually need it but also because you're asking it to do something it can't do. Just to explain: the evaluate method operates in the context of your web page only. It pretty much only allows you to execute Javascript instructions directly on the current page in the remote browser. It has no concept of variables that you've declared externally to that function - so in this case, when you do this:

await page.goBack();

The evaluate method has no idea what page is nor how to use it. Now there are ways to inject page into the evaluate method but that won't resolve your problem either. Puppeteer API calls simply won't work inside an evaluate method (I've tried this myself and it always returns an exception).

So now lets get back to the problem you do have - what you're doing in the evaluate function is retrieving one UI element with class .items and then searching for every UI element within that UI element with class .item. You're then looping through all of the found UI elements, clicking on each one, grabbing some kind of data and then going back to click on the next one.

You can achieve all of this without ever using the evaluate method and, instead, using Puppeteer API calls as follows:

const itemsList = await page.$('.items'); // Using '.$' is the puppeteer equivalent of 'querySelector'
const elements = await itemsList.$$('.item'); // Using '.$$' is the puppeteer equivalent of 'querySelectorAll'

const data = [];
elements.forEach(async (element) => {
  await element.click();
  // Get the data you want here and push it into the data array
  await page.goBack();
});

Hope this helps you out!

You can use page.metrics() to compare two points in time (e.g. before and after page.goto). The page.evaluate approach to read the data from the performance API is also a good alternative. As I already pointed out in the comment, it is not defined what should be considered a "full page load". Both approaches are valid.

It's even more complex

There are a number of thing which people might consider a page to be loaded:

• DOMContentLoaded event fired
• Load event fired
• Time it takes from navigation start until all resources embedded in the document (like images are loaded)
• Time it takes from navigation start until all resources are loaded
• Time until there are not more ongoing network requests.
• ...

You also have to consider whether whether you want network related phases (like DNS) to be part of the measurement. Here is an example request (generated with the Chrome DevTools Network tab) showing how complex a single request might be:

There is also a document explaining each of these phases.

Simple approach

The simplest way to measure the load time would just to start measuring when the navigaiton starts and stop measuring after the page is loaded. This could be done like this:

const t1 = Date.now();
await page.goto('https://example.com');
const diff1 = Date.now() - t1;
console.log(`Time: ${diff1}ms`);

Note that there are also other APIs (page.metrics, process.hrtime, perf_hooks) to get more precise timestamps.

You can also pass options to the page.goto function to change the resolving of the promise to something like this (quoted from the docs):

Consider navigation to be finished when there are no more than 0 network connections for at least 500ms

For that, you would have to use the setting networkidle0:

await page.goto('https://example.com', { waitUntil: 'networkidle0' });

There are also other events in the docs linked above you could use.

More complex: Use the Performance API

To get more precise results, you can use the Performance API as you already did in your code. Instead of going through the prototype of window.performance you can also use the functions performance.getEntries() or performance.toJSON() like this:

const perfData = await page.evaluate(() =>
    JSON.stringify(performance.toJSON(), null, 2)
);

That way, you get data that looks like this:

{
  "timeOrigin": 1556727036740.113,
  "timing": {
    "navigationStart": 1556727036740,
    "unloadEventStart": 0,
    "unloadEventEnd": 0,
    "redirectStart": 0,
    "redirectEnd": 0,
    "fetchStart": 1556727037227,
    "domainLookupStart": 1556727037230,
    "domainLookupEnd": 1556727037280,
    "connectStart": 1556727037280,
    "connectEnd": 1556727037348,
    "secureConnectionStart": 1556727037295,
    "requestStart": 1556727037349,
    "responseStart": 1556727037548,
    "responseEnd": 1556727037805,
    "domLoading": 1556727037566,
    "domInteractive": 1556727038555,
    "domContentLoadedEventStart": 1556727038555,
    "domContentLoadedEventEnd": 1556727038570,
    "domComplete": 1556727039073,
    "loadEventStart": 1556727039073,
    "loadEventEnd": 1556727039085
  },
  "navigation": {
    "type": 0,
    "redirectCount": 0
  }
}

So if you want to know how long it took from navigationStart to loadEventStart you subtract one value from the other one (e.g. 1556727039073 - 1556727036740 = 2333 ms).

So which one to take?

This is up to your decision. In general, it is a good idea to use the Load event as a starting point. Waiting until all requests are finished might actually never happen because there are constantly resources being loaded in the background. Using networkidle2 as waitUntil option might be an alternative in case you don't want to use the load event.

In the end, however, it comes down to your use case which metric to use.