The scroll-through pattern
Scrolling is a widespread pattern in the way we interact with websites. It determines how smooth and responsive we experience them during the process of finding our way to complete our intended tasks. Very few web pages are free from scrolling by design, so we can't avoid the reflows that scrollbars cause and their effect on user's behavior. A common discussion point in the past was what the immediately visible top area of the site should contain and we tried to put the most important content there. But as time passed and page lengths became infinite, we somehow lost this discussion. We no longer even know what our most important content is. As a result our users scroll up and down without finding any peace. During this scrolling all kinds of things can happen and the viewport gets constantly repainted. Everything that is bound to the scroll event gets executed and if these computations are heavy, they can slow down the page significantly. As the user scrolls, hover effects on all kinds of elements are randomly activated, which—in case of a table with too many elements—can slow down the experience without any visible reason. All this leads to less than 60fps.
But scrolling isn't always initiated by the user. This leaves room for interpretation how it should be done. We can put an anchor on a link that sends the user immediately to the element with the same id. There is nothing wrong with this approach: it is very fast and happens immediately, probably even on a slow mobile device. It shows exactly what the user expects to see. We could probably explain this as a "scroll-to" behavior. But lately we have also introduced the very similar "scroll-through" pattern and the difference is so subtle that it justifies further discussion. When a user clicks on a link or button, he "travels" to the right place with the scrolling itself being animated. This allows him to get a better feeling of what the page contains before he sees the related content. Depending on how fast the animation is, he could see more or less. If he sees more, he arrives slower at his destination; if he sees almost nothing (with a one-second animation), he arrives faster. Here we are animating something the user didn't ask for, something unrelated to what he was trying to achieve. Even if this looks great, it isn't very useful to someone who isn't interested in extra details. Problematic is also that the effect happens after the action and the user has no control over it for its entire duration. Normally, we see effects before taking action and when done right, they give us hints of what we could expect. But this isn't the case with scroll-through. I think that whether animations should happen after the user's action should be open for discussion, because right now we don't seem to have interface elements that clearly suggest animated scrolling. At least I think of links in terms of leading somewhere and of buttons as having two states, one of which activates something important.
Scroll-through, when widespread, could motivate making web pages even longer, when people could jump up and down everywhere with a single click. Then we'll no longer talk about user experience, but about scroll experience. Unfortunately, this will have further consequences for our ability to focus and will make finding content even harder. It's probably best if we leave scrolling for users to do it themselves.
The longer web pages are, the more people need to scroll and the more time they spend scrolling. The page height then gives an accurate picture how much work people need to do to reach the bottom of the page. Most of the time they can't arrive there instantly—only gradually. This makes it especially important with long pages to provide a mechanism for people to jump quickly to the top and bottom. We could measure the page length in pixels and divide it by the average viewport height that our users have to get the number of screens they need to go through. I have measured the page lengths of the top 25 websites (homepages only!) according to Alexa's traffic tank to see which pixel lengths work best. For this I have used document.body.scrollHeight in the Firebug console. Here is the result as of 30.7.2013:
We can see that the sites with the most traffic are concentrated in being around 1000px tall or less. (The mean is 1822px, the median—1179px.) This is contrary to the widespread perception that more content is better. But there are also many sites in the range of 2000-4000px. One is even above 7000px high. If we assume that the viewport has a height of 700px, this would mean that the user needs to scroll through ten screens. It's hard to imagine how many dpi the his mouse needs to be to do this in a reasonable time. The need for more scrolling is thus a bad design decision we should strive to avoid.