2

I’m curious if running an FPS counter in a Playwright/Puppeteer test suite that throws when the FPS drops below a threshold, like 60fps, is that a useful canary to alert when a part of the interface needs performance work.

Here’s an example of something like the FPS counter I’m wanting to implement within the browser context:

// Options
const decimalPlaces    = 2;
const updateEachSecond = 1;

// Cache values
const decimalPlacesRatio = Math.pow(10, decimalPlaces);
let timeMeasurements     = [];

// Final output
let fps = 0;

const tick = function() {
  timeMeasurements.push(performance.now());

  const msPassed = timeMeasurements[timeMeasurements.length - 1] - timeMeasurements[0];

  if (msPassed >= updateEachSecond * 1000) {
    fps = Math.round(timeMeasurements.length / msPassed * 1000 * decimalPlacesRatio) / decimalPlacesRatio;
    timeMeasurements = [];
  }

  if ( fps > 60 ) {
      // Throw to Puppeteer or Playwright
  }

  requestAnimationFrame(() => {
    tick();
  });
}

tick();

Original: https://stackoverflow.com/a/52727222/1397641

Ideally I’d love an FPS counter on as many tests as possible that tells me when a part of the user experience is too sluggish before it gets deployed to the user.

I know using performance.now() is better than Date.now(), but I'm uncertain how to make sure the test environment is similar or slightly slower than a target user device.

For example: Is puppeteer running on a build process like Netlify or Vercel comparable to a user device like a 5 year old Android device?

Can I add throttles to make the test more realistic or even less powerful than a user device so that the FPS test fails slightly before users devices would?

Sam Carlton
  • 1,190
  • 1
  • 17
  • 18
  • Where does the playwright(being an UI test automation library) comes in this picture? May be its an stupid question , but it was not clear to me so asked. – Vishal Aggarwal Apr 19 '23 at 14:09
  • @VishalAggarwal My understanding is that Playwright goes beyond the standard testing features like a library like Jest would have. For example, Playwright has built-in support for testing automation in Safari. Perhaps there's a simpler way to spin up a browser environment within a CI flow that I'm unaware of. – Sam Carlton Apr 19 '23 at 16:07
  • So let's put it this way, what exact part you want playwright to play in this scenario to make it successful? – Vishal Aggarwal Apr 19 '23 at 17:26
  • The main purpose here is that Playwright and Puppeteer can be interchangeable on certain features, so it's for question visibility/indexing. I'm hoping to get an answer that helps people working with either, but if not, say something like, "I don't know if this works in Puppeteer" or "I've checked and this only works in Playwright". This seems to be a decent reference for the differences: https://playwright.dev/docs/puppeteer – Sam Carlton Apr 19 '23 at 21:47
  • There seems to be at least three questions here, if I understand correctly: (1) how can I implement throwing when FPS drops in a Playwright or Puppeteer test? (2) how to throttle an automated test browser to emulate the speed of an older device? (3) is FPS a useful measurement to test in the first place? – ggorlen Aug 31 '23 at 21:17
  • @ggorlen Maybe a better merged question would be: How does one implement FPS counting into Playwright or Puppeteer testing well? – Sam Carlton Aug 31 '23 at 21:47

1 Answers1

2

It might be useful depending on what kind of app/site you are testing. Such a feature probably does not need to be enabled by default. How it can be implemented:

  1. https://pptr.dev/api/puppeteer.page.exposefunction/ to expose a binding to the target page to report fps drops.
  2. https://pptr.dev/api/puppeteer.page.evaluateonnewdocument/ to load the fps measurement code before anything else.
  3. https://pptr.dev/api/puppeteer.page.emulatecputhrottling/ to make the page slower. Although not sure how realistic that would be.
Oleksii Rudenko
  • 1,277
  • 12
  • 23