Jump to content
GreenSock

Alle

Difference between 2 preloads

Moderator Tag
Go to solution Solved by ZachSaucier,

Recommended Posts

Hi,
I would like to know an opinion from the experts.

I have created 2 preloads.
The first one using onUpdate from GreenSock.

var obj = {prop: 1};
  gsap.to(obj, {
    duration: 1,
    prop: 100,
    //onUpdate fires each time the tween updates; we'll explain callbacks later.
    onUpdate: function() {
      gsap.to(".bar", {
        width: obj.prop + "%" });
        $(".percentage").html(parseInt(obj.prop) + "%");
        console.log(parseInt(obj.prop)); //logs the value on each update.
    },
    onComplete: function(){
      startTimeline();
    }
  });

I try to see inspect element and I get back the data :

15, 36, 67, 88, 94, 95, 96, 98, 98, 99, 99, 99, 100


The second one using JS PerformanceTiming.
I discovered this thanks to Ahsan K. Rathore.
https://codepen.io/ahsanrathore/post/accurate-page-progress-bar
It seems to me that using this system the preload works much better.
the data that return to me are 1,2,3,4,5, etc..

 

I probably didn't understand well how onUpdate works, so I was wondering
if there is any way to get the same result using onUpdate, I would like to avoid to use the script of 
Ahsan K. Rathore  because I would prefer to use gsap directly.

Can you give me some indication of the error I am making or is the method wrong?
 

Thank you all.
Have a great Sunday.

See the Pen accurate-page-progress-bar by ahsanrathore (@ahsanrathore) on CodePen

Link to comment
Share on other sites

Hello Alle,

 

Regardless of solution you will need some kind of logic that directly reflects the actual load progress. Then you just feed it into width/scale and innerText.

Scale is more performant than width, so you can probably stick with it. Also making the same querySelection on each onUpdate is unnecessary, you can just save a variable beforehand.

 

Currently this will fire 5*60 times( since we have 5secs) but we are only updating 1 to 100, so maybe not ideal, so we are overwriting a lot of those (e.g 1.1 => 1, 1.2 => 1, etc) :) 

Tap into the real progress for better results.

 

This looks like a good start if you like another approach to JS Performance Timing.

https://www.freakyjolly.com/how-to-pre-post-load-assets-like-images-css-js-files-using-preload-js-liberary/#.YEVQz2h8JTY

 

See the Pen 28b7da79ad3162c196dcccb63436292e?editors=1010 by dadacoded (@dadacoded) on CodePen

 

 

 

 

  • Like 1
Link to comment
Share on other sites

Hey Alle. The question really boils down to: what are you wanting to show? Are you wanting to show a value based on the actual load of the page? Or based on your animation length? Because the two almost certainly don't match up exactly. 

 

20 hours ago, Alle said:

I try to see inspect element and I get back the data :

15, 36, 67, 88, 94, 95, 96, 98, 98, 99, 99, 99, 100

That distribution of values largely comes from the ease that's applied to your tween. If you set the ease to "none" it will be more what you're expecting.

 

If I were tasked with doing something like this, I would probably use the method of calculating the estimated time of the page load that Ahsan provided in your linked post but use GSAP's ticker to update the value. Or perhaps using tweens that overwrite each other if you find that there are larger jumps that are unsightly. 

  • Like 1
Link to comment
Share on other sites

Hi and thanks for the super quick response. "tailbreezy and ZachSaucier"

I explained myself rather badly actually, probably because I didn't really understand what I wanted to do either.
What I wanted to know exactly was the loading of the page and not the length of the animation.


No one tasked me with this job.
I got obsessed with greensock and trying to figure out the best way to do things in the future.

I did some experiments.
The one provided by tailbreezy and the one provided by Ahsan.
 

I compared both online and non-localhost preloads.
Also I put the Network Fast 3G to slow everything down.

I noticed that both preloads start after about 3500 / 5000 milliseconds. 

So I was wondering why they don't start right away? 
It's as if there is an initial GAP with both. 
I'm fine with that too but I'm doing it to understand and go deep into things.
834953772_Schermata2021-03-08alle15_27_37.thumb.png.297eaba0b088768d6bdca0c74d17cf0d.png 

 

I was not aware of the ticker like many other things :-) evidently.
This library is great and also its documentation, but there are so many
things to know so it's not that easy.


You have already given me a lot of valuable information that will help me
to study and test.


Thank you very much for your support.

  • Like 1
Link to comment
Share on other sites

  • Solution
7 minutes ago, Alle said:

I noticed that both preloads start after about 3500 / 5000 milliseconds. 

So I was wondering why they don't start right away? 

That's probably how long the page takes to load before the JS runs at all.

  • Like 1
Link to comment
Share on other sites

7 minutes ago, ZachSaucier said:

That's probably how long the page takes to load before the JS runs at all.

Could be the DOM load time as Zach suggested.

 

From the screenshot it seems to me that the DOM loads at around 1000ms.

 

Can be verified by checking on bottom of Network tab in Chrome.

 

Fast ( your preloader will start at 1.08 and it will run its course to 3.55s)

image.png.0104cff3477e2b6e957dc4809a9092c0.png

 

Slow ( sorry haven't waited to finish :) but same applies)

image.thumb.png.f3d7b4774c3d29cf53a5eede9af96110.png

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×