You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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();
The text was updated successfully, but these errors were encountered:
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)
my solution for now is to comment this.refresh() in add.
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
The text was updated successfully, but these errors were encountered: