Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

big bottleneck issue code should to be improved #609

Open
simonjoom opened this issue Aug 20, 2019 · 0 comments
Open

big bottleneck issue code should to be improved #609

simonjoom opened this issue Aug 20, 2019 · 0 comments

Comments

@simonjoom
Copy link

simonjoom commented Aug 20, 2019

Or how to pass script overload from 9000ms to 1000ms in Script Evaluation at lighthouse!

I was faced with very low lighthouse ratings mainly because of waypoints script.
My application runs close to 20 waitpoints on one page.

The way that waypoint is coded does not help any application to be responsible with lot of waypoint.

Here is the main problem. waypoint can not know when the page has finished loading all the waypoints of the current page, so each time it calculates the value of a waypoint it displays and recalculates and redisplay all previous waypoints already calculated.

here the result of the process...
calcul(n waypoint)=calcul(0..(n-1)waypoint) +calcul(n waypoint)

Context.prototype.add = function (waypoint) {
	var axis = waypoint.options.horizontal ? 'horizontal' : 'vertical'
	this.waypoints[axis][waypoint.key] = waypoint
       this.refresh() ///-< refresh for one and all previous waypoint added 👎 
}

my solution for now is to comment this.refresh() in add.

Context.prototype.add = function (waypoint) {
	var axis = waypoint.options.horizontal ? 'horizontal' : 'vertical'
	this.waypoints[axis][waypoint.key] = waypoint
       //this.refresh() ///no more refresh in added waypoint
}

and trigger manually Waypoint.refreshAll() to calculate all waypoint points stored in memory.

Because the developper know better than a script where the refresh should to be start it's important to put that in a manual form

As well i removed horizontal axis so.. i could again divide the computation by 2 (not a lot of application need to watch horizontal scroll)
The best will be to add an "manual option" and add an option 'strict' to avoid horizontal computation.
As well store the innerwidth outerwidth element in memory avoid some reflowding (to be refreshed in resize)

Yeah this script seems to be not maintained this is shame because lot of wordpress theme and jQuery stuff use it.. I think better to pass to other one if this is not resolved.. or make some hack like me. (i'm lazy to change my code for IntersectionObserver by example)

Use case:
I use isotopescript coupled to waypoint:
here all element isotope are computed in a loop, only one call to refresh display them


_each(items, function (val) {
				var elInner = $(val).children('.t-inside'); 
				if (elInner.hasClass('animate_when_almost_visible') && !elInner.hasClass('force-anim')) {
					new Waypoint({
						element: val,
						handler: function () {
							var element = $(this.element).children('.t-inside'), 
								currentIndex = parent.index();
                                                         element.show();
							this.destroy();
						},
						offset: '100%'
					})
				}
				index++;
			});

Waypoint.refreshAll();

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant