Member Avatar for benkyma

I'm building a javascript application that uses CSS transitions to fade the content container before swapping out the content and fading back in.
It appears that Chrome waits for about half a second before beginning the transition. It usually then completes the transition really quickly and jerkily. In all other browsers it seems to work really smoothly.
What is strange is that if I click the menu with a frequency of about once a second, it works smoothly. If I click with a slower frequency, it starts to execute with the delay and jerky animation again.

I am creating the animation by adding an 'invisible' class with an opacity 0 to my content div. This div has the properties:

-webkit-transition-property: opacity;
-webkit-transition-duration: 0.5s;
-webkit-transform: translateZ(0);

I am running osx Lion on a fast iMac. As I say it works fine in other browsers to I don't think the problem is hardware related. If I set a timer just before I add the class to time the transition it says it completes in 10ms. It could be a javascript issue, but I don't think so, because I've logged every line from button click to adding the css class and it just seems to stop and wait.
All my images come off 5 spritesheets which are fairly large (600-800kb). If I change the name of these images so the browser can't find them, the delay problem becomes less severe. All these images are loaded at runtime though so the delay can't be explained by the request.

  • 2 Contributors
  • 1 Reply
  • 206 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by Member #120589

Dani AI

Generated

— the symptoms you describe (long pause, then a very fast jump; smoother when you click repeatedly; improvement when large images are removed) point to browser-side work that is happening just as the fade should start: image decode / rasterization / texture upload or layer creation on the compositor thread. When Chrome has to prepare large bitmaps for a composited layer it can block the start of the transition; keeping the page “active” (rapid clicks) often keeps those textures resident so the next animation is smooth.

Practical steps to confirm and fix (fast, testable):

  • Measure precisely: use Performance.now() with transitionstart/transitionend listeners or record a DevTools Performance trace and look for long Paint / Raster tasks on the main thread. That will show whether decoding/rasterizing is the culprit.
  • Pre-decode / preload images: create an Image() and call img.decode() (or use createImageBitmap) before showing the element so the browser does the heavy work earlier.
  • Force the element into a compositor layer ahead of time and avoid doing it at the moment of the click. Use will-change: opacity (remove it when done) or set a transform earlier. Also toggle classes across animation frames to ensure transitions are applied cleanly.

Example patterns:

/* CSS hint */
.card { will-change: opacity; }

/* JS pre-decode */
const i = new Image();
i.src = 'sprite.png';
i.decode().then(() => document.body.classList.add('images-ready'));

/* ensure transition runs on next frame */
el.classList.add('pre'); // initial state
requestAnimationFrame(() => el.classList.add('fade-out'));

Split very large sprite sheets if possible, and compress or serve modern formats. — a minimal runnable example (HTML/CSS/JS) that reproduces the issue will make diagnosis faster, but start with the steps above and a DevTools trace to confirm if raster/image decode is the bottleneck.

Member Avatar for Member #120589

The images seem to be very big for sprites. Could you show all relevant code so that we could try to replicate the problem?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.