cypress: Ability to opt out of waiting for 'load' event before resolving cy.visit() - onload event takes too long to fire
Current behavior:
Cypress runs extremely slowly. Run time for 2 tiny tests is ~60-65 compared to similar Protractor test suite which takes ~20-25 seconds to complete the same tests. My timing for Cypress is based on the timer in the runner and my timing for Protractor is based on the timestamp in the console from when it starts and finishes.
Desired behavior:
Significant improvement to run time.
How to reproduce:
Using test code below.
Test code:
Cypress code:
(I would set timeout as 15000 just like my Protractor code, but it times out when I do that)
describe('Attempt to log in', () => {
beforeEach(() => {
cy.visit('/')
})
it('without a username or password', () => {
cy.get('button', {timeout: 30000})
.contains('SIGN IN')
.should('be.visible')
.click()
cy.get('#error')
.should('have.text', 'Please enter your username')
})
it('without a password', () => {
cy.get('#username', {timeout: 30000})
.should('be.visible')
.type('example_username1')
cy.get('button')
.contains('SIGN IN')
.click()
cy.get('#error')
.should('have.text', 'Please enter your password')
})
})
Comparable Protractor code:
describe('Attempt to log in', () => {
const EC = protractor.ExpectedConditions;
beforeAll(() => {
browser.get('/');
browser.wait(EC.presenceOf($('#username')), 15000);
});
it('without a username or password', () => {
element(by.buttonText('SIGN IN').click();
expect($('#error').getText()).toBe('Please enter your username');
});
it('without a password', () => {
$('#username').sendKeys('example_username1');
element(by.buttonText('SIGN IN').click();
expect($('#error').getText()).toBe('Please enter your password');
});
afterEach(() => {
browser.executeScript('window.sessionStorage.clear();');
browser.executeScript('window.localStorage.clear();');
browser.refresh();
});
});
Cypress is really great and powerful, but it’s a shame that it takes so long to execute these tests.
- Operating System: Windows 7
- Cypress Version: Beta 1.0.2
- Browser Version: Version 61.0.3163.100 (Official Build) (64-bit)
About this issue
- Original URL
- State: open
- Created 7 years ago
- Reactions: 25
- Comments: 32 (7 by maintainers)
OH God, i sold to my boss using Cypress for e2e testing, and i encountered this issue, i cant believe this is an issue reported over an yr and not been fixed or getting an work around, should i start pack up and looking for new interviews ?
any update?
Kindly make it optional to opt out of the load event.
Hey, @jennifer-shehane are there any updates on this feature?! if you guys can prioritize this it will be great as this issue makes a lot of noises thanks
describe(‘CSS Locator’,()=>{ it(‘Verify the CSS Locator’,()=>{ cy.visit(“https://rahulshettyacademy.com/seleniumPractise/#/”) cy.get(“input[placeholder=‘Search for Vegetables and Fruits’]”).type(“Cucumber”) cy.get(“h4[class=‘product-name’]”).contains(‘eq’,‘Cucumber’) }) })
I am running the above code in cypress and everytime it says Timed out after waiting 60000ms for your remote page to load.
Your page did not fire its load event within 60000ms.
You can try increasing the pageLoadTimeout value in cypress.config.js to wait longer.
Browsers will not fire the load event until all stylesheets and scripts are done downloading. can anyone tell me why it is happening and what is the solution because it is perfectly loading on a normal browser
In my case, 3rd party scripts that were sending requests on first load were blocking the load event. Some notable examples were Intercom, Facebook events and others. If they are added to
index.htmlthrough script tags, then I think they’ll cause theloadevent to be blocked.After using
cy.interceptto mock responses for those requests, my load event no longer takes a huge amount of time.There are cases where DomContentLoaded and Load events can be fired at significantly different times, one case can be when the page needs to load very large images. ~Also https://github.com/cypress-io/cypress/issues/8679 further causes issues for us having to wait on the
loadevent. Due to this bug the load event often never fires as images are constantly loading.~Correct me if I’m wrong but the main difference between DomContentLoaded + Load is stylesheets and image loading. From https://github.com/cypress-io/cypress/issues/788#issuecomment-338747293 @brian-mann commented that using load event offers higher guarantees, why is that? At DOMContentLoaded all scripts are parsed and loaded (https://developer.mozilla.org/en-US/docs/Web/API/Document/DOMContentLoaded_event) and I don’t see what cypress commands generally rely on image being loaded. IMO using DomContentLoaded as the event that cy.visit waits on makes more sense to me in scenarios where static assets like images etc slow things down would be great if that was an option.
visit https://www.saucedemo.com/ CypressError Timed out after waiting 10000ms for your remote page to load.
Your page did not fire its load event within 10000ms.
You can try increasing the pageLoadTimeout value in cypress.config.js to wait longer.
Browsers will not fire the load event until all stylesheets and scripts are done downloading.
When this load event occurs, Cypress will continue running commands.
cypress/fixtures/pages/loginPage.js:17:8 15 | 16 | visit() {
Please allow for opting out of the load event. I am struggling to get past this issue even though the rest of my tests work when I use a beta environment URL that does not have the load page issue.
I forgot this thread until rossjwaddell revived it. So per my previous comment I wrote more than 2 years ago I had the same issues as everyone where my tests were taking a long time to run even when it was just 1 or 2 tests.
For me the issue was that the headless browser would take a long time to load a page in Windows 10 but the execution of the unit tests itself were fast. I didn’t have the problem when I ran my unit tests on a machine running OSX with identical setup.
It’s been a while since I worked on that project but I was actually able to get around the issue. I believe it had something to do with the fact that the site I was performing a
cy.visit()either hadI am almost sure it was the first one and if that were the case I modified the html of the site so the external links matched the schema of the site URL I was visiting. In my case I changed them to be all http.
I hope this helps someone even though it’s a bit late.
Some of these comments are related to other slow running issues, but I’d like to focus this issue on the topic of Cypress waiting for the
loadevent to fire duringcy.visit(), since that was extensively addressed in https://github.com/cypress-io/cypress/issues/788#issuecomment-338747293 and also there is a reproducible example of that being an issue provided here https://github.com/cypress-io/cypress/issues/788#issuecomment-482173298If your issue is still happening and not related to the time that the
cy.visit()command appears in the Command Log to the time it resolves (when the pagesloadevent fires) I suggest opening a new issue.There has been some discussion of, instead of waiting for the
loadevent to fire, to wait for network idle. This would not address the bhg.com issue however since the network is constantly fetching resources for 85 seconds until the load event fires.The only way to get around this issue would be to perhaps listen to the DOMContentLoaded event, as @brian-mann suggested, or to have the ability to opt in and disable listening for the
loadevent as on oncy.visit(), which would mean it is up to the user how they wish to proceed after callingcy.visit().I’m recreating the same test in protractor and cypress in my app too and getting a similar result.
I think the reasons for this happening have been already explained, but basically, my app is composed of very old pieces and very new ones using Angular 7. Testing around angular 7 it’s quite fast but when testing the old pages which can have all sort of bad practices about blocking the load event…
Hope we get the option to opt out soon
I face same issue. Cypress is extremely slow when call cy.visit() because it waits all url is loaded.