Delivering content on the web has over the years become more complex and heavier. Dependencies on third parties and external web services is increasing, causing longer loading times. The “click and wait” analogy is frustrating for users, and to overcome this problem, asynchronous technologies have been implemented on the web with great success. The reduction of loading times on web requests is an important step forward.

Lately, I’ve noticed that the asynchronous loading have caused content to jump, causing the user to re-focus and possibly re-aim a mouse-click or a touch event. Even worse, the focus can sometimes be pushed out of the viewport, which is at best confusing.

To address this problem, we need to stop the page from jumping. Question is how we do that best. We can most certainly not go back and download the whole web page before displaying it in the old request-response fashion. An alternative would be to show the structure of the web page with blanks which would lately be filled in upon asynchronous loading, but the page would look empty at first glance, and user would start to wonder why.

How do we avoid jumping of content upon asynchronous feeding without displaying an empty webpage on first rendering?

enter image description here

  • 3
    I think this is more of an software implementation issue, i.e. initially request sizes of content along with page request from server and reserve space, then asynchronously send requests for the actual content. HTML does support this. – Danny Varod Apr 28 '14 at 8:39
  • @DannyVarod In a way it is, but how should it really work. How should software developers implement a smooth loading of asynchronous loaded content? Isn't this task a specific use case for the User Experience Specialist to write? – Benny Skogberg Apr 28 '14 at 8:46
  • 2
    I think it is a bit too implementation-y really. The UX situation here is 'should the page jump when content is being loaded'. To which the answer is 'no'. How you go about stopping that happening is the implementation issue. Now, it could be more about UX if you're asking which is the better trade-off; slow page load but no jumping, or fast loading but jumpy content then that's probably a bit more suited. – JonW Apr 28 '14 at 10:40
  • 3
    I think this is a valid question: Looking at it reverse , if you ask developer to "stop the website jumping" what UI will the users get? Who knows. A developer has to know what is good UX is to implement an improvement in page loading behaviour. – Jason A. Apr 28 '14 at 10:42
  • @JonW I think I just did that in a very sublime way by asking "How do you stop the jumping of content upon asynchronous feeding without having a ridiculously empty webpage at first view?" at the end. But I take your guidance and will edit the question to fit our common UX-asking rules. – Benny Skogberg Apr 28 '14 at 13:23

Assuming that the technology in use supports it, an improved experience will be

  • If have never retrieved data from that source, but do know the size, render a place-holder image. A subtle loading animated gif, with different desaturated icon per source.

  • If have never retrieved data from that source, and don't know the size then render a place-holder at the smallest expected size, then animate expansion to new size after content is received.

  • If have retrieved data from this source before, then render a version of the data placed into local storage (e.g. could store previous HTML and data, or even store a "screenshot" of that component). Display changes if newer data is sent from sever. May need a "last refreshed at" or "data changing now" hint.

  • These are good suggestions, and I'm sure "technology" will supports it if we come up with the idea of how it should work. Thanks Jayfang – Benny Skogberg Apr 28 '14 at 13:26
  • For images for instance, you don't need to render a place holder, just specify the size and the browser can pre-allocate space for them: w3schools.com/tags/att_img_height.asp For other elements, you can use CSS to reserve space for the element without a placeholder or unnecessary animations. – Danny Varod Apr 28 '14 at 14:19
  • we do very similar things to these suggestions in our apps. fixed width blank areas with centrally aligned loading indicators, and minimum width blank areas if the area can be different widths - again with centrally aligned loading indicators. we also place headers (if applicable) above so the user knows what content is loading. – Dave Haigh Apr 30 '14 at 11:57
  • 1
    we don't however implement the 3rd suggestion. when would the placeholder screenshot update to new data? if its auto then there would be too many flashing content changes going on on the page. I can see the benefit of this though. maybe if content sync is done after user interaction. – Dave Haigh Apr 30 '14 at 11:59
  • Where I was think 3rd suggestion would be straightforward to apply is segments of a page that either do, or would "naturally" be expected to have updates e.g. an embedded twitter feed. Don't wait for twitter to respond - first load stored tweets, then update when new tweets arrive. I've made answer more clear about storing previously retrieved HTML/data. – Jason A. Apr 30 '14 at 13:15

Nobody got it right actually. It has to do with smartphones and touchscreens. Once you get past the BS of smartphones being a computer in your pocket you will soon quickly realize that touch and non touch devices are more different then they are alike.

Webpages are designed now with touch pad first which asynchronous loading works because on a small screen estate you only see a few items at once which you swish with your fingers and the rest load later as you go.

On a laptop/desktop however you see all the 20 items/objects sometimes moving at once all trying to load causing the page to jump around then finally the ads load THEN you can navigate. The ads want to be the first to load by the way so if the webpage is busy with other crap to load it will not do it until the ads do it then you often get something blaring in one of your 10 tabs open if it's a desktop/laptop.

Your Answer

