DrawSVG, Animation delays loading, jittery

[benjino]

At my site https://www.siegfriedmedia.com I have a GSAP DrawSVG, Stagger animation that loads into the left half column of the Front-page hero section. I had it on Siteground with its SG Optimizer plugin for WordPress and the animation would delay some. Yesterday I removed the SG Optimizer plugin and started using the Nitropack plugin which rocks but it is causing an even greater delay with the loading of the animation. I'm not sure why this is doing this. If you go to the site you might have to wait a few seconds before any of the hero section loads. First of all, is my GSAP code (not the scripts) causing any of this? Secondly, what clues are there or things I could do with the Nitropack caching plugin to fix this? I understand this isn't a support forum for Nitropack but is there anything of caching that you understand on a deeper level than myself that could be the issue, that you might see in the settings of Nitropack?

See the Pen ZEGgWWZ by benjino (@benjino) on CodePen.

[ZachSaucier]

39 minutes ago, benjino said:

I had it on Siteground with its SG Optimizer plugin for WordPress and the animation would delay some. Yesterday I removed the SG Optimizer plugin and started using the Nitropack plugin which rocks but it is causing an even greater delay with the loading of the animation. I'm not sure why this is doing this.

That's definitely a question for the Nitropack plugin or simply investigating things yourself  It likely has to do with how many files they're loading, the load order, how they bundle, caching, or something else. All the usual suspect for loading slowness. I think it's unlikely that you'll be able to get more help than that from this forum

[benjino]

So I gather you see nothing wrong with my GSAP in the JS section of Codepen?

Thanks for the insight. I've taken up a ticket with Nitropack.

 

[ZachSaucier]

16 minutes ago, benjino said:

So I gather you see nothing wrong with my GSAP in the JS section of Codepen?

TBH I didn't even look because it's not relevant to what you described. There's no point in having the outer DOMContentLoaded wrapper. Your GSAP code has no errors  

[benjino]

So remove all of this?

 

document.addEventListener("DOMContentLoaded", function(event) {

  // wait until images, links, fonts, stylesheets, and js is loaded
  window.addEventListener("load", function(e) {

	//GSAP goes here.

  }, false);

});

 

[ZachSaucier]

15 minutes ago, benjino said:

So remove all of this?

I was intending for you to just remove the outermost one that relates to DOMContentLoaded because the inner window load event will be waited for regardless of whether or not the DOMContentLoaded one is there. But you can try it without either one and see how it goes  No harm in trying things out.

[benjino]

A change has been made on the Nitropack settings where the big delay in the Hero section of the Front-page was taking a long time to load.

There is a second layer to this delay that is still bugging. The left-half column where the GSAP animation takes place will have a flash-effect for a micro-second, then reappear and do the animation as expected. I think this is the CSS rule that says "visibility:hidden" not applying fast enough, then applying, causing this initial flash effect. Then the CSS rule of visibility:visible in the JS for the GSAP gets applied and it reappears and animates as expected. To see this you have to refresh the page enough times to get it to happen. So it may not happen for you on the first load. Why would this be happening? Is there some improvement I can make with my code setup for this?

[ZachSaucier]

23 minutes ago, benjino said:

The left-half column where the GSAP animation takes place will have a flash-effect for a micro-second, then reappear and do the animation as expected. I think this is the CSS rule that says "visibility:hidden" not applying fast enough, then applying, causing this initial flash effect. Then the CSS rule of visibility:visible in the JS for the GSAP gets applied and it reappears and animates as expected. To see this you have to refresh the page enough times to get it to happen. So it may not happen for you on the first load. Why would this be happening? Is there some improvement I can make with my code setup for this?

This is called a flash of unstyled content (FOUC). See this article on the subject:

 

Browsers will wait for the CSS to load before rendering the DOM so what you said doesn't make much sense. Use your dev tools to see what's going on. Maybe some earlier JS is overwriting the CSS and then some later JS is fixing the issue? 

[benjino]

  // wait until images, links, fonts, stylesheets, and js is loaded
  window.addEventListener("load", function(e) {

  // custom GSAP code goes here
  //when js kicks in show
	gsap.set("#drawsvg_content, .arrow", {visibility:"visible"});

	// sm_icon drawSVG
	gsap.fromTo("path", {drawSVG:"50% 50%"}, {duration:1, drawSVG:"100% 0%", ease:"none"});

	//stagger in next 3 and have them remain
	gsap.from("#icon_behind, .home_intro, .arrow", {duration: .5, autoAlpha:0, scale:.5, ease: "power4", y: -150, stagger: 0.2});

  }, false);

Well this is what I have so it looks like I don't need the first line of "gsap.set." That may have been needed before you upgraded GSAP, not sure, but I did have this code prior to the update that then required you to use "gsap.mymethod". So below is what I did and checked it out in the Inspector and I see "opacity:1, visibility:inherit" in there, and there is no flash now. Everything works the same.

 

  // wait until images, links, fonts, stylesheets, and js is loaded
  window.addEventListener("load", function(e) {

  	// sm_icon drawSVG
  	gsap.fromTo("path", {drawSVG:"50% 50%"}, {duration:1, drawSVG:"100% 0%", ease:"none"});

  	//stagger in next 3 and have them remain
  	gsap.from("#drawsvg_content, #icon_behind, .home_intro, .arrow", {autoAlpha:0, duration:.3, scale:.5, ease: "power4", y: -150, stagger: 0.2});

  }, false);

 

Edited April 7, 2020 by benjino
Update with the corrected code