5 ms·

Is it just me or does this feel really slow?

• axod 16y ago
  Fits right in with jquery. Then in the next version they can announce it's 2000% faster.
  • tjarratt 16y ago
    First you make it work, then you make it perform well. What, you were expecting the first code they wrote to be perfect?
    • axod 16y ago
      Attaching code to scroll events will never be a good idea. Infinite scroll will never be a good idea.
      • roel_v 16y ago
        "Infinite scroll will never be a good idea." I very much disagree. It's an awesome way to capture the reader. I love it myself, not needed reloads, hunting for 'next' buttons, ... Yes you lose the relative position on the page indicator from the scroll bar, but it's irrelevant by the time you get to the bottom of the page anyway.
        • Sharlin 16y ago
          You also lose all indication of the total content length, which is IMHO a bad thing in many contexts.
          • wladimir 16y ago
            If the content is not truly infinite (#comments known?), just very large, you could solve the scrollbar issue by giving the page the right vertical size (or an estimation), but only populating the HTML if the user scrolls somewhere.
            • axod 16y ago
              so the page looks broken or like its still loading? Yah great usability
              • wladimir 16y ago
                You'd use AJAX to load the elements, so it doesn't show as loading. And you make sure the user never sees the empty space, given normal scrolling speed, by loading the area around the visible screen. Certainly not worse than extending the page when the user reaches the bottom, as some sites do.
• baddox 16y ago
  Not too bad. On the sticky elements example, if I furiously flick my scroll wheel downward, there is a noticeable but tiny delay for the section menu to "catch up" at the top of the screen. The infinite scroll example seems fine, as does the analytics example. Is there really any way to get faster performance in the first example other than just giving the section menu div position:fixed (which doesn't exactly do the same thing)?
  • moe 16y ago
    I think he means the main page, that one scrolls fairly jerky for me, too (OSX/Chrome). However I think this is more due to the generous use of drop shadows than the javascript.
  • imakewebthings 16y ago
    Plugin author here, I can help clarify that. The scrolling is throttled so that all the checks aren't run with every single scroll event, as that would choke everything. So the small delay you see there is some 0-100 millisecond value while it hasn't triggered the event yet. You can change the throttle by setting $.waypoints.settings.scrollThrottle = 50, or whatever number you like, to try to reduce flickers in cases like these. Just be aware its a balance you'll be striking with executing more scroll checks. But all the selectors and offset values are cached so the performance should still hold up should you choose to lower this value.
    • patrickaljord 16y ago
      Reminds me of this, I guess you read it already: http://ejohn.org/blog/learning-from-twitter/ http://ejohn.org/blog/learning-from-twitter/
      • imakewebthings 16y ago
        Based the throttling on that exact post.
    • karl_nerd 16y ago
      I love what you did with this and i will definitely play around with it. This functionality should really be built into the browser in my opinion. I was thinking, for performance reasons, did you try ditching the $(window).scroll and go with this? http://jsbin.com/eciwu4/edit http://jsbin.com/eciwu4/edit
• mickeyben 16y ago
  it's the box-shadow effect :-) Just tried with the webkit inspector, if you remove all the box-shadow, the page is smooth.