3 ms·
I can repro it. The lag is only of a few milliseconds, but enough to capture a screenshot, so it is jarring for sure. This is on first page load - http://imgur
by revorad 14y ago
I can repro it. The lag is only of a few milliseconds, but enough to capture a screenshot, so it is jarring for sure.
This is on first page load - http://imgur.com/4kB93ZX http://imgur.com/4kB93ZX
And this is on clicking through to a post - http://imgur.com/i7B3HOE http://imgur.com/i7B3HOE
When I hit back, I get the first page's loading symbol again.
Here's another weird thing:
Sometimes, when I click from the list of posts page through to a post, scroll down, and then hit back, it takes me to the top of the post instead of back to the list of posts. This happens only sometimes, not always.
Also, it looks like you are tracking scroll position by chopping up the page into numbered sections which are tracked in the url. Going back and forth resets the scroll position to the top of the tracked section. This works mostly fine, but is off sometimes by a line or two.
Edited to add:
In an earlier post[1], Robin argues that using client-side frameworks like Ember increases speed because you can leverage CDNs. But, I think our examples suggest that there are still some speed issues in the client-side rendering, which I think is DHH's point.
Even if total times with Ember (request to server and final render) might be less than something like pure Rails, the perceived speed for the user might be lower.
Robin gives one anecdote of some people in Prague finding his Ember site faster than others. saurik and I have provided couple more anecdotes :-)
But, it might be good to collect some proper data using something like Torbit.
[1] http://eviltrout.com/2013/01/06/turbolinks-and-the-prague-effect.html http://eviltrout.com/2013/01/06/turbolinks-and-the-prague-ef...
- saurik 14y ago> I can repro it. The lag is only of a few milliseconds, but enough to capture a screenshot, so it is jarring for sure. I would say this is at least a few hundred milliseconds; if nothing else, I dare you to succeed in taking a screenshot of something that only lasts for milliseconds ;P. (I say this only because someone else might get the wrong impression about how intrusive it ends up being.) > Also, it looks like you are tracking scroll position by chopping up the page into numbered sections which are tracked in the url. Going back and forth resets the scroll position to the top of the tracked section. This works mostly fine, but is off sometimes by a line or two. This is the actually specific issue I was complaining about with the scroll position (and which I think was what was trying to be reproduced); its awesome that you found another one, though ;P. The longer the posts (and even just a post with a YouTube video in it is half my screen height) the more off the scroll position becomes. I often see posts on the forums I use that are a couple screens long: clicking a link from them and then hitting back with Discourse resets you to the top of the post, as the "numbered sections" are the index of the post you are looking at (with that irritating caveat that I've found a bunch of contexts where there are multiple post-like thing that somehow "don't count" for the URL).
- sams99 14y agosee: http://meta.discourse.org/t/lots-of-loading-time-when-browsing/2564/6 http://meta.discourse.org/t/lots-of-loading-time-when-browsi...