Using cookies to speed up Puppeteer and Playwright scripts
As we go about our day-to-day on the web, our browser automatically exchanges small amounts of data with the websites we visit. This way we get to have them recognise us and remember our preferences, the contents of our shopping baskets or the fact that we had just logged in to our account.
These bits of information are called cookies, and they allow the otherwise stateless HyperText Transfer Protocol (HTTP) to keep context consistent over the course of a session.
Reading and writing cookies to the browser
Reading or modifying cookies opens up useful possibilities. A practical example is skipping authentication when testing features available only after login. We could automate the login procedure, but there is no point in going through it for every test in our suite. Skipping it might free up precious time, speeding up delivery.
The following examples show how we can save existing cookies after logging in to GitHub and reuse them later to skip login. First, let us perform login with our credentials, read the cookies and save them to a file.
After a successful login, our saved cookies file will look something like this:
We are now able to read the file later and load the cookies into our new browser session. Notice how we are logged in from the start, without having gone through the UI login procedure.
Note: Cookies come with an expiration date, so make sure the ones you are trying to reuse are still valid.
While brand new browser sessions with both Puppeteer and Playwright will not contain any cookies by default, there might be points when it is necessary to clear them.
Tip: Notice how Puppeteer handles cookies at page level while Playwright does so at context level.
localStorage and sessionStorage
Cookies are sent with every request, potentially deteriorating performance if used for storing large amounts of data. The localStorage and sessionStorage APIs can help us offload some of this data to the browser. Just like with cookies, Puppeteer and Playwright make accessing localStorage and sessionStorage straightforward.
Our test site, Danube, actually uses localStorage to keep track of a few things, such as the content of your cart. Let’s see how we can access this state and then replicate it in a later session.
We will first fill the cart by adding three items, then we will copy the contents of localStorage to a file.
In this case our file will look as follows:
We can use the content of this file to set localStorage in a separate session. That way we will immediately start with the three items already in our shopping cart, potentially getting us closer to a specific scenario we want to test and thereby saving ourselves time.
You can interact with sessionStorage very much like we did with localStorage.
Tip: Do not underestimate the usefulness of having shorter execution time on scripts, especially when frequently running large batches/suites.
All the above examples can be run as follows.
GITHUB_USER=username GITHUB_PWD=password node managing-cookies.js
SET GITHUB_USER=usernameSET GITHUB_PWD=passwordnode managing-cookies.js
2. The Puppeteer and Playwright APIs for handling cookies are slightly different but achieve the same goals.
1. The official MDN docs for cookies.
2. A practical guide to the Web Storage APIs, sessionStorage and localStorage.
This article was originally posted on theheadless.dev