cy.visit takes too long

How to wait for page to load in Cypress

Cypress test can be pretty fast. Sometimes even faster than the application we are testing. If you find yourself in a situation where Cypress runs faster than you application loads, this blogpost is for you.

Page load event

If you found this post via Google search, you might have started your search, because you saw a message that says: "Timed out after waiting 60000ms for your remote page to load."

This message appears when your page does not trigger the load event. But what actually is that?

According to MDN docs , load event is something that your browser triggers once has downloaded all page assets.

So what does that mean?

Whenever you enter an URL into your browser and hit enter, your browser is going to make a GET api call to that address. Similarly to when you do API testing with Postman or with Cypress. Instead of getting a JSON -structured object, you are going to get an HTML document.

A simplified version of the document that is return will look like this:

Browser will take a look into the document and will request all files linked to it. Notice we have style.css and app.js files. Browser will download them and once it’s done with this, it will trigger the load event that Cypress waits for.

This is pretty much the best point at which we can say that application is ready. Realistically, many sites have dynamic .js files that starts calling APIs that load resources from a server, or animate elements on page. These may cause the application to still be in "loading" mode. There’s no telling how many resources these .js files will load or how long it will take to load them. While the load event is a good checkpoint, in case of modern web applications, it is rarely last thing that happens on a page.

If you see an error that Cypress could not load your page, chances are that this download is not happening, or something is blocking it. This may be an issue on your side, so you can treat this as a bug that needs to be fixed.

I recently saw the mentioned error happen on demo site from Sauce labs . The reason for this problem was how service worker was configured. It caused the load event to never happen. This is not a problem with all service workers, but it caused some trouble for me. The final solution was to stub the service worker API call, essentially disabling the service worker. I added the following intercept and restarted the browser. Copy to clipboard undefined

Waiting for network calls

Another way of ensuring that a page is loaded is to wait for a network call. For example, when you have a to-do app that will load all the to-dos when it’s opened, you can use a network call intercept that will wait for that network call to happen:

Since cy.wait() will wait for not only the request to happen, but also the response, it can be a reliable way of making sure that your page is properly loaded.

If you have multiple API calls, you can intercept them all and make your test wait for them by passing an array of aliases to cy.wait() command like this:

Another way of waiting for multiple requests is to use cy.get('@alias.all') syntax. This way you can wait for all requests to happen.

There are two small gotchas though. cy.get() will wait only for 4000 ms for the request to happen, as it listens to defaultCommandTimeout option instead of responseTimeout as it does with cy.wait() . If your requests take longer to load, you need to change the timeout on cy.get() command. Also, cy.get() will only wait for the request to trigger, but will not actually wait for the response. Cypress’ built-in retry-ability can help us though, because we can check the last request status code by referencing the last request:

Waiting for DOM

Another way of making sure that the application is fully loaded is to take a look into the DOM. This way we can actually assure that we don’t end up doing something we would not expect from a real user.

For example, in real world you would probably not interact with an app while there’s still a "loading" animation still overlaid on page. You can add a guard for your test to make sure the loader disappears before you interact with the page.

Negative assertions can be a little tricky, and depending on the page speed or way of how the .loader animator works, we might want to add .should('be.visible') before we assert on the element’s non-existence.

To flip this, we can instead just use cy.get() for the element we want to first interact with. If that takes longer time to appear, a timeout can be added. You can read more about timeouts and waiting in one of my previous blogposts .

Default timeout

Sometimes, keeping things simple is the best wait. Every cy.visit() will wait for 60 seconds for the load event to be fired. This is quite a long time, since real users usually don’t have such patience. If the cy.visit() command fails, you should probably fix the application itself and use this timeout as a performance benchmark. Alternatively, you can lower the timeout by changing the pageLoadTimeout option in your configuration. Read about different timeouts in Cypress docs .

If you read this far, you might be interested in following me on Twitter , LinkedIn , or on YouTube . If you want to be notified about my new blogs and workshops, I recommend subscribing to my newsletter at the bottom of this page.

Tweet this article

Share on LinkedIn

Edit on GitHub

Table of contents:

Let’s keep in touch.

From time to time I send some useful tips to your inbox and let you know about upcoming events. Sign up if you want to stay in loop.

is required.

I treat your email address like I would my own. That means no ads. Just notifications of when I do cool stuff. Unsubscribe anytime. Click here to read about how I handle your data

Visit a remote URL.

Best Practice

We recommend setting a baseUrl when using cy.visit() .

Read about best practices here.

Correct Usage

url (String)

The URL to visit.

Cypress will prefix the URL with the baseUrl configured in your global configuration if set.

If the baseUrl has not been set, you will need to specify a fully qualified URL or Cypress will attempt to act as your web server. See the prefixes notes for more details.

Note: visiting a new domain requires the Cypress window to reload. You cannot visit different super domains in a single test.

options (Object)

Pass in an options object to control the behavior of cy.visit() .

By default, the cy.visit() commands' will use the pageLoadTimeout and baseUrl set globally in your configuration .

You can also set all cy.visit() commands' pageLoadTimeout and baseUrl globally in the Cypress configuration .

• cy.visit() yields the window object after the page finishes loading.
• It is unsafe to chain further commands that rely on the yielded window after cy.visit() .

Let's confirm the window.navigator.language after visiting the site:

Visit a local server running on http://localhost:8000

cy.visit() resolves when the remote page fires its load event.

Change the default timeout

Overrides the pageLoadTimeout set globally in your configuration for this page load.

Add basic auth headers

Cypress will automatically apply the right authorization headers if you're attempting to visit an application that requires Basic Authentication .

Provide the username and password in the auth object. Then all subsequent requests matching the origin you're testing will have these attached at the network level.

You can also provide the username and password directly in the URL.

Cypress will automatically attach this header at the network proxy level, outside of the browser. Therefore you will not see this header in the Dev Tools.

Provide an onBeforeLoad callback function

onBeforeLoad is called as soon as possible, before your page has loaded all of its resources. Your scripts will not be ready at this point, but it's a great hook to potentially manipulate the page.

Check out our example recipes using cy.visit() 's onBeforeLoad option to:

• Bootstrapping your App
• Set a token to localStorage for login during Single Sign On
• Stub window.fetch

Provide an onLoad callback function

onLoad is called once your page has fired its load event. All of the scripts, stylesheets, html and other resources are guaranteed to be available at this point.

Add query parameters

You can provide query parameters as an object to cy.visit() by passing qs to options .

The parameters passed to qs will be merged into existing query parameters on the url .

Submit a form

To send a request that looks like a user submitting an HTML form, use a POST method with a body containing the form values:

Visit is automatically prefixed with baseUrl

Cypress will prefix the URL with the baseUrl if it has been set. Configure baseUrl in the Cypress configuration to prevent repeating yourself in every cy.visit() command.

The cypress.json file has been replaced by cypress.config.js or cypress.config.ts in Cypress version 10.0.0. We recommend that you update your configuration accordingly.

Please see the new configuration guide and the migration guide for more information.

If you would like to visit a different host when the baseUrl has been set, provide the fully qualified URL you would like to go to.

Visit local files

Cypress will automatically attempt to serve your files if you don't provide a host and baseUrl is not defined . The path should be relative to your project's root folder (the directory that contains the Cypress configuration file ).

Having Cypress serve your files is useful in smaller projects and example apps, but isn't recommended for production apps. It is always better to run your own server and provide the url to Cypress.

Visit local file when baseUrl is set

If you have baseUrl set, but need to visit a local file in a single test or a group of tests, disable the baseUrl using per-test configuration . Imagine this Cypress configuration:

The first test visits the baseUrl , while the second test visits the local file.

Visit will automatically follow redirects

Protocol can be omitted from common hosts.

Cypress automatically prepends the http:// protocol to common hosts. If you're not using one of these 3 hosts, then make sure to provide the protocol.

Visit will always yield the remote page's window object when it resolves

Trying to change the User-Agent ? You can set the userAgent as a configuration value in your configuration file.

Prevent requests before a remote page initially loads

One common scenario Cypress supports is visiting a remote page and also preventing any Ajax requests from immediately going out.

You may think this works:

But if your app makes a request upon being initialized, the above code will not work . cy.visit() will resolve once its load event fires. The cy.intercept() command is not processed until after cy.visit() resolves.

Many applications will have already begun routing, initialization, and requests by the time the cy.visit() in the above code resolves. Therefore creating a cy.intercept() route will happen too late, and Cypress will not process the requests.

Luckily Cypress supports this use case. Reverse the order of the commands:

Cypress will automatically apply the routes to the very next cy.visit() and does so immediately before any of your application code runs.

Requirements

• cy.visit() requires being chained off of cy .
• cy.visit() requires the response to be content-type: text/html .
• cy.visit() requires the response code to be 2xx after following redirects.
• cy.visit() requires the load load event to eventually fire.
• cy.visit() will automatically wait for assertions you have chained to pass
• cy.visit() can time out waiting for the page to fire its load event.
• cy.visit() can time out waiting for assertions you've added to pass.

Visiting cross-origin sites

After visiting a cross-origin site, to interact with the content, you must use a cy.origin() block.

When visiting a cross-origin site, the onBeforeLoad and onLoad options are not supported.

Command Log

Visit example application in a beforeEach

The commands above will display in the Command Log as:

When clicking on visit within the command log, the console outputs the following:

• cy.reload()
• cy.request()
• Recipe: Bootstrapping your App
• Recipe: Logging In - Single Sign on
• Recipe: Stubbing window.fetch

Visit a remote URL.

Best Practice We recommend setting a baseUrl when using cy.visit() . Read about best practices here.

Correct Usage

url (String)

The URL to visit.

Cypress will prefix the URL with the baseUrl configured in your network options if you’ve set one.

You may also specify the relative path of an html file. The path is relative to the root directory of the Cypress installation. Note that the file:// prefix is not needed.

options (Object)

Pass in an options object to control the behavior of cy.visit() .

You can also set all cy.visit() commands’ pageLoadTimeout and baseUrl globally in configuration .

cy.visit() yields the window object after the page finishes loading.

Visit a local server running on http://localhost:8000

cy.visit() resolves when the remote page fires its load event.

Change the default timeout

Add basic auth headers.

Cypress will automatically apply the right authorization headers if you’re attempting to visit an application that requires Basic Authentication .

Provide the username and password in the auth object. Then all subsequent requests matching the origin you’re testing will have these attached at the network level.

You can also provide the username and password directly in the URL.

Cypress will automatically attach this header at the network proxy level, outside of the browser. Therefore you will not see this header in the Dev Tools.

Provide an onBeforeLoad callback function

onBeforeLoad is called as soon as possible, before your page has loaded all of its resources. Your scripts will not be ready at this point, but it’s a great hook to potentially manipulate the page.

Check out our example recipes using cy.visit() ‘s onBeforeLoad option to: Bootstraping your App Set a token to localStorage for login during Single Sign On Stub window.fetch

Provide an onLoad callback function

onLoad is called once your page has fired its load event. All of the scripts, stylesheets, html and other resources are guaranteed to be available at this point.

Add query paramaters

You can provide query parameters as an object to cy.visit() by passing qs to options .

The parameters passed to qs will be merged into existing query parameters on the url .

Submit a form

To send a request that looks like a user submitting an HTML form, use a POST method with a body containing the form values:

Visit will automatically follow redirects

Protocol can be omitted from common hosts.

Cypress automatically prepends the http:// protocol to common hosts. If you’re not using one of these 3 hosts, then make sure to provide the protocol.

Cypress can optionally act as your web server

Cypress will automatically attempt to serve your files if you don’t provide a host and baseUrl is not defined . The path should be relative to your project’s root folder (where the cypress.json file is generated by default).

Having Cypress serve your files is useful in smaller projects and example apps, but isn’t recommended for production apps. It is always better to run your own server and provide the url to Cypress.

Visit is automatically prefixed with baseUrl

Configure baseUrl in the your configuration file ( cypress.json by default) to prevent repeating yourself in every cy.visit() command.

Visit will always yield the remote page’s window object when it resolves

Trying to change the User-Agent ? You can set the userAgent as a configuration value in your configuration file.

Prevent XHR / Ajax requests before a remote page initially loads

One common scenario Cypress supports is visiting a remote page and also preventing any Ajax requests from immediately going out.

You may think this works:

But if your app makes a request upon being initialized, the above code will not work . cy.visit() will resolve once its load event fires. The cy.server() and cy.route() commands are not processed until after cy.visit() resolves.

Many applications will have already begun routing, initialization, and requests by the time the cy.visit() in the above code resolves. Therefore creating a cy.server() will happen too late, and Cypress will not process the requests.

Luckily Cypress supports this use case. Reverse the order of the commands:

Cypress will automatically apply the server and routes to the very next cy.visit() and does so immediately before any of your application code runs.

Requirements

cy.visit() requires being chained off of cy .

cy.visit() requires the response to be content-type: text/html .

cy.visit() requires the response code to be 2xx after following redirects.

cy.visit() requires the load load event to eventually fire.

cy.visit() will automatically wait for assertions you've chained to pass.

cy.visit() can time out waiting for the page to fire its load event.

cy.visit() can time out waiting for assertions you've added to pass.

Command Log

Visit example application in a beforeEach

The commands above will display in the Command Log as:

When clicking on visit within the command log, the console outputs the following:

• cy.reload()
• cy.request()
• Recipe: Bootstrapping your App
• Recipe: Logging In - Single Sign on
• Recipe: Stubbing window.fetch

© 2020 Cypress.io Licensed under the MIT License. https://docs.cypress.io/api/commands/visit.html

Execute code in Node via the task plugin event.

We do not recommend starting a web server using cy.task() . Read about best practices here.

Correct Usage

• cypress.config.js
• cypress.config.ts

The task plugin event handler can return a value or a promise. The command will fail if undefined is returned or if the promise is resolved with undefined . This helps catch typos or cases where the task event is not handled.

If you do not need to return a value, explicitly return null to signal that the given event has been handled.

Arguments ​

event (String)

An event name to be handled via the task event in the setupNodeEvents function.

arg (Object)

An argument to send along with the event. This can be any value that can be serialized by JSON.stringify() . Unserializable types such as functions, regular expressions, or symbols will be omitted to null .

If you need to pass multiple arguments, use an object

options (Object)

Pass in an options object to change the default behavior of cy.task() .

cy.task() yields the value returned or resolved by the task event in setupNodeEvents .

cy.task() provides an escape hatch for running arbitrary Node code, so you can take actions necessary for your tests outside of the scope of Cypress. This is great for:

• Seeding your test database.
• Storing state in Node that you want persisted between spec files.
• Performing parallel tasks, like making multiple http requests outside of Cypress.
• Running an external process.

Read a file that might not exist ​

Command cy.readFile() assumes the file exists. If you need to read a file that might not exist, use cy.task .

Return number of files in the folder ​

Seed a database ​, return a promise from an asynchronous task ​, save a variable across non same-origin url visits ​.

When visiting non same-origin URL, Cypress will change the hosted URL to the new URL , wiping the state of any local variables. We want to save a variable across visiting non same-origin URLs.

We can save the variable and retrieve the saved variable outside of the test using cy.task() as shown below.

Command options ​

Change the timeout ​.

You can increase the time allowed to execute the task, although we do not recommend executing tasks that take a long time to exit .

Cypress will not continue running any other commands until cy.task() has finished, so a long-running command will drastically slow down your test runs.

Tasks must end ​

Tasks that do not end are not supported ​.

cy.task() does not support tasks that do not end, such as:

• Starting a server.
• A task that watches for file changes.
• Any process that needs to be manually interrupted to stop.

A task must end within the taskTimeout or Cypress will fail the current test.

Tasks are merged automatically ​

Sometimes you might be using plugins that export their tasks for registration. Cypress automatically merges on('task') objects for you. For example if you are using cypress-skip-and-only-ui plugin and want to install your own task to read a file that might not exist:

See #2284 for implementation.

If multiple task objects use the same key, the later registration will overwrite that particular key, similar to how merging multiple objects with duplicate keys will overwrite the first one.

Reset timeout via Cypress.config() ​

You can change the timeout of cy.task() for the remainder of the tests by setting the new values for taskTimeout within Cypress.config() .

Set timeout in the test configuration ​

You can configure the cy.task() timeout within a suite or test by passing the new configuration value within the test configuration .

This will set the timeout throughout the duration of the tests, then return it to the default taskTimeout when complete.

Allows a single argument only ​

The syntax cy.task(name, arg, options) only has place for a single argument to be passed from the test code to the plugins code. In the situations where you would like to pass multiple arguments, place them into an object to be destructured inside the task code. For example, if you would like to execute a database query and pass the database profile name you could do:

Argument should be serializable ​

The argument arg sent via cy.task(name, arg) should be serializable; it cannot have circular dependencies (issue #5539 ). If there are any special fields like Date , you are responsible for their conversion (issue #4980 ):

Requirements ​

• cy.task() requires being chained off of cy .
• cy.task() requires the task to eventually end.

Assertions ​

• cy.task() will only run assertions you have chained once, and will not retry .
• cy.task() can time out waiting for the task to end.

Command Log ​

This example uses the Return number of files in the folder task defined above.

The command above will display in the Command Log as:

When clicking on the task command within the command log, the console outputs the following:

• cy.fixture()
• cy.readFile()
• cy.request()
• cy.writeFile()
• Blog: Incredibly Powerful cy.task()
• Blog: Rolling for a Test
• Universal Code Test with Cypress
• Read a file that might not exist
• Return number of files in the folder
• Seed a database
• Return a Promise from an asynchronous task
• Save a variable across non same-origin URL visits
• Command options
• Tasks must end
• Tasks are merged automatically
• Reset timeout via Cypress.config()
• Set timeout in the test configuration
• Allows a single argument only
• Argument should be serializable
• Requirements
• Command Log

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications You must be signed in to change notification settings

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cypress slows down drastically over long runs - restart renderer between spec files? #431

jrdallen97 commented Feb 14, 2017

• 👍 8 reactions

Andrew1431 commented Mar 7, 2017

• 👍 2 reactions
• 👎 2 reactions

Sorry, something went wrong.

brian-mann commented Mar 7, 2017 • edited

Brian-mann commented mar 7, 2017.

• 👍 7 reactions
• 👀 3 reactions

jrdallen97 commented Mar 7, 2017

• 👍 1 reaction

jennifer-shehane commented Jun 6, 2017

ddeath commented Jun 16, 2017 • edited

Brian-mann commented jun 16, 2017, ddeath commented jun 16, 2017.

derekharmel commented Aug 3, 2017

It's worth noting that when the app initially loads in development, it uses ~450 MB and stays pretty close to the number throughout the day. Thereore, there still exists a problem which can't be blamed on sourcemaps.

brian-mann commented Aug 3, 2017

Derekharmel commented aug 3, 2017 • edited.

dhoko commented Oct 26, 2017 • edited

brian-mann commented Oct 26, 2017

Dhoko commented oct 27, 2017 • edited, brian-mann commented oct 27, 2017 via email, dhoko commented nov 6, 2017 • edited, brian-mann commented nov 6, 2017, dhoko commented nov 6, 2017.

robbybooker commented Jan 15, 2018 • edited

• 👍 3 reactions

mikehallstar commented Jan 24, 2018

jamiel commented Feb 22, 2018

pgroot91 commented Mar 1, 2018

Brian-mann commented apr 15, 2018, brian-mann commented may 30, 2018.

SecondFlight commented Jul 18, 2018 • edited

• 👍 4 reactions

brian-mann commented Jul 18, 2018

Secondflight commented jul 19, 2018.

pradeepgururani commented Aug 10, 2018 • edited

L4mPi2 commented Sep 5, 2018 • edited by jennifer-shehane

• 👎 17 reactions

jennifer-shehane commented Apr 24, 2019

sgatade commented Apr 17, 2022 • edited

srotak5 commented May 23, 2023

• 😄 4 reactions

nagash77 commented May 23, 2023

No branches or pull requests