{"id":61002,"date":"2025-07-21T14:12:29","date_gmt":"2025-07-21T18:12:29","guid":{"rendered":"https:\/\/app14743.cloudwayssites.com\/?p=61002"},"modified":"2026-03-11T15:00:25","modified_gmt":"2026-03-11T19:00:25","slug":"handling-animations-and-loading-artifacts-in-visual-testing","status":"publish","type":"post","link":"https:\/\/app14743.cloudwayssites.com\/blog\/handling-animations-and-loading-artifacts-in-visual-testing\/","title":{"rendered":"Handling Animations and Loading Artifacts in Visual Testing"},"content":{"rendered":"\n

Have you ever encountered a situation where you try to take a screenshot, but instead of the beautifully well-crafted UI, all you\u2019ve got is an image of a spinner\/skeleton\/loading screen? Handling animations and loading artifacts in visual testing can be daunting.<\/p>\n\n\n\n

Don\u2019t worry – it can happen to anyone, and we\u2019re not here to judge you \ud83d\ude09<\/p>\n\n\n\n

One of the SDK engineers here at Applitools, Noam, breaks this down into a hands-on tutorial, hoping it will help you get a better understanding of the industry’s best practices around visual testing of rich and dynamic UI experiences.<\/p>\n\n\n\n

Let\u2019s dive right in!<\/p>\n\n\n\n

Framework Native Solutions<\/strong><\/h2>\n\n\n\n

Most frameworks already have different mechanisms to handle animations and loading artifacts. Keeping things simple is often the best way to achieve code stability and maintainability. Using your framework’s built-in tools would most often be the best approach.<\/p>\n\n\n\n

For example:<\/p>\n\n\n\n

Playwright JS<\/h3>\n\n\n\n
\/\/ Playwright: wait for spinner to be removed\nawait page.waitForSelector('.spinner', { state: 'detached' });\nawait eyes.check()<\/code><\/pre>\n\n\n\n
Cypress<\/h3>\n\n\n\n
\/\/ Cypress: wait for spinner to not exist\ncy.get('.spinner').should('not.exist'); \ncy.eyesCheck()<\/code><\/pre>\n\n\n\n
Selenium JS<\/h3>\n\n\n\n
\/\/ Selenium: wait for spinner to be invisible\nconst spinnerElements = await driver.findElements(By.css('.spinner'));\nif (spinnerElements.length) {\n  await driver.wait(until.elementIsNotVisible(spinnerElements[0]), 5000);\n}\nawait eyes.check()<\/code><\/pre>\n\n\n\n
A Common Pitfall<\/strong><\/h2>\n\n\n\n
Even if the UI appears visually unchanged, frontend frameworks like React, Vue, and Angular may re-render elements under the hood. This can lead to stale element references<\/strong>, especially when capturing regions right after a DOM change.<\/p>\n\n\n\n
Consider the following example:<\/p>\n\n\n\n
cy.get('.main').then($el => {\n  cy.get('.spinner').should('not.exist'); \/\/ spinner disappears after main was located\n\n  cy.eyesCheckWindow({\n    tag: 'main',\n    target: 'region',\n    element: $el, \/\/ stale reference if .main was replaced\n  });\n});<\/code><\/pre>\n\n\n\n
    \n
  1. First, Cypress locates .main<\/code><\/li>\n\n\n\n
  2. Then, Cypress waits for the spinner to disappear<\/li>\n\n\n\n
  3. This example would fail (even if the new element has the exact same properties) if the main element is replaced by another element<\/li>\n<\/ol>\n\n\n\n
    How to avoid that?<\/h3>\n\n\n\n
    When possible (e.g., Playwright), it’s preferred that you use locators instead of selectors<\/a>. If you can’t, it’s better if you use selectors instead of DOM references (element: \u2018.main\u2019<\/code>).<\/p>\n\n\n\n
    Videos, CSS Animations, GIFs<\/strong><\/h2>\n\n\n\n
    There are many techniques to eliminate other types of dynamic behaviour in web pages. Playwright, for example, provides a Clock API<\/a> that allows pausing JavaScript time-related events (including JS-driven animations). It\u2019s also possible to install custom CSS snippets to pause and reset CSS-related animations. Other JS specialized crafted snippets would be required for resetting GIFs, videos, and so on – you get the idea.<\/p>\n\n\n\n
    This never-ending cat-and-mouse game can be prevented by using Applitools Ultrafast Grid (UFG)<\/a>. Instead of rendering web pages on locally executed browsers, the UFG team maintains specialized logics and fine-tuned commands that ensure a stable and consistent rendering experience. While UFG offers more than just rendering stability, it’s worth noting that classic screenshots can still achieve stable results. UFG just makes it easier!<\/p>\n\n\n\n
    Algo-Based Solutions<\/strong><\/h2>\n\n\n\n
    If you intentionally want to capture dynamic content (e.g., animations, changes), a smarter strategy is to embrace that variability and use smart matching algorithms to compare just what you need, like those found in Applitools Eyes<\/a>. <\/p>\n\n\n\n
    Any match level can be used for the entire screenshot or specific regions of the screen. Read more in the Match Level Best Practices tutorial<\/a>. For example, algorithms like the Layout match level can drastically improve your experience with localization testing.<\/p>\n\n\n\n
    The waitBeforeCapture<\/code> Setting<\/strong><\/h2>\n\n\n\n
    Performing wait operations can become more complicated when:<\/p>\n\n\n\n
      \n
    1. Testing with no-code visual testing SDKs (e.g eyes-storybook<\/a>)<\/li>\n\n\n\n
    2. Testing with advanced Eyes features like lazyLoading<\/a> and layoutBreakpoints<\/a><\/li>\n<\/ol>\n\n\n\n
      The waitBeforeCapture<\/code> setting was invented for these types of use cases (and a few others). <\/p>\n\n\n\n
      This setting can receive three types of arguments:<\/p>\n\n\n\n
        \n
      1. Milliseconds<\/strong> – the simplest approach. While it\u2019s not always the most innovative or sophisticated pattern, in many cases, it \u201cdoes the trick.\u201d In general, waiting for explicit timeouts during tests is not recommended. However, when compared to clock manipulations and code injections, sometimes the simplicity and stability is worth the longer run-time.<\/li>\n\n\n\n
      2. Selector<\/strong> – when we\u2019re waiting for something to appear, most SDKs support passing a selector, and Applitools Eyes will automatically wait for an element that matches this selector to appear in the web page.<\/li>\n\n\n\n
      3. Custom function<\/strong> – see code example<\/li>\n<\/ol>\n\n\n\n
        \/\/ eyes-storybook\n  waitBeforeCapture: async () => {\n    while (document.querySelector('.spinner')) {\n      await new Promise((resolve) => setTimeout(resolve, 100))\n    }\n    return true;\n  }\n\n\/\/ eyes-playwright\nawait eyes.check({\n  name: 'my-step',\n  async waitBeforeCapture() {\n    await page.locator('.spinner').waitFor({state: 'hidden'})\n  },\n})<\/code><\/pre>\n\n\n\n
        The waitBeforeCapture<\/code> setting can be defined in your applitools.config<\/code> file, in your eyes.check<\/code> settings, using the Target<\/code> settings builder, and in other similar places. Please refer to the documentation of the specific SDK<\/a> you\u2019re using for concrete examples.<\/p>\n\n\n\n
        Storybook Play Functions<\/strong><\/h2>\n\n\n\n
        A nice eyes-storybook<\/a>-specific trick to achieve a desired rendering state would be a Storybook Play Function<\/a>.<\/p>\n\n\n\n
        Applitools Eyes will run your play functions and wait for them to finish before capturing anything on the screen. Use Play Functions to navigate the story to an interesting state and wait for the story to be stable inside the play function to help Eyes understand what the best time is to capture the screenshot.<\/p>\n\n\n\n
        Applitools is Here to Help<\/strong><\/h2>\n\n\n\n
        We hope you\u2019ve found this article interesting, and maybe it solved some of the most common visual testing issues you may have encountered. Go ahead and try these examples out for free with Applitools Eyes<\/a>.<\/p>\n\n\n\n
        However, if something isn\u2019t clear or if you\u2019d like advice regarding the best way to incorporate visual testing into your organization, please don\u2019t hesitate to reach out to our experts<\/a>! Testing is our passion, and we\u2019re here to help.<\/p>\n\n\n\n
        Quick Answers<\/strong><\/h2>\n\n\n\n
        What are \u201cloading artifacts\u201d in visual testing, and how do I avoid flaky tests?<\/strong> 
        Loading artifacts are transient UI elements, like spinners, skeleton cards, GIFs, that appear while data is fetched. If a screenshot is captured before they disappear, your baseline image won\u2019t match future renders, causing false failures (flaky tests).<\/p> <\/div> 
        Why do I get \u201cstale element reference\u201d errors after a React\/Vue\/Angular re\u2011render?<\/strong> 
        Modern frameworks often replace DOM nodes even when the UI looks identical. If you save a DOM reference (e.g., cy.get('.main')<\/code>) before<\/strong> waiting for the spinner to vanish, that reference may point to a removed element, causing stale errors. Capture by selector<\/strong> or locator<\/strong>, not by saved element handles, to avoid this.<\/p> <\/div> 
        What is the waitBeforeCapture setting in Applitools, and what values can it accept?<\/strong> 
        waitBeforeCapture<\/code> delays the screenshot after the DOM is stable. It accepts:\u2022 Milliseconds<\/strong> (e.g., 500<\/code>)\u2022 CSS selector<\/strong> to wait for element presence\/absence\u2022 Custom async function<\/strong> for complex logic (e.g., loop until .spinner<\/code> hidden)<\/p> <\/div> 
        Can I use Storybook Play Functions to control the render state before visual testing?<\/strong> 
        Yes. In eyes\u2011storybook<\/strong>, Applitools runs each story\u2019s Play Function and waits for it to finish\u2014perfect for clicking buttons, filling forms, or pausing animations before the snapshot.<\/p> <\/div> 
        Is it better to fast-forward the JavaScript clock or add explicit waits for CSS animations?<\/strong><\/strong> 
        Fast-forwarding the JS clock (e.g., page.clock.fastForward(1000)<\/code> in Playwright) is usually more reliable and efficient than using hard timeouts. It advances timers without waiting in real time, making tests faster. However, it won\u2019t affect CSS-driven animations since those still require CSS overrides to pause or skip transitions. For full stability, combine clock control with style injections or use Applitools Ultrafast Grid, which auto-handles CSS animations under the hood.<\/p> <\/div> <\/div>\n\n\n\n
        \n