10/05/2017: Development update (performance & styles)

post by habryka (habryka4) · 2017-10-06T07:22:36.777Z · LW · GW · 8 comments

Contents

8 comments

Hey Everyone, here are the latest changes I just pushed to the page:

  • Significant speed improvements after the initial package load. Posts should now load reliably in less than 2-3 seconds (and usually faster than that).


  • Some speed improvements for the first visit of the page. This is still taking far too long, but it should be a good bit better now (more on that at the end of this post)


  • Typography improvements for posts and comments (things now have reasonable line-height, and upvote and downvote buttons are more recognizable)


  • Comments are now collapsable


  • Various small bugfixes all over the place


  • A lot of internal code refactoring and cleanup (as part of making things fast)


Overall, quite happy with the last week. Let me know what you think about the changes. I particularly want to thank Max Harms who spent some of his free time to work on LessWrong for part of the last two weeks, and has been extremely helpful. 

This is not the final performance update. A large part of our performance rework was sadly somewhat stopped in its tracks by a bug in Meteor I ended up discovering, so some of the biggest gains will have to wait until that has been fixed. However, we've already made quite a bit of improvements, and are reaching load times that are only half a second slower than Reddit on some of our development servers, so I think we can definitely achieve reasonably fast loading speeds.

Let me know what you think about all the latest changes, and please always feel free to add new Bugs to our Github repo (or even better, come and help fix some of the bugs yourself!). We will continue to focus on performance improvements for now, but from now on things will be more incremental, and so you should see more frequent updates and faster bugfixes.

8 comments

Comments sorted by top scores.

comment by [deleted] · 2017-10-06T14:30:50.629Z · LW(p) · GW(p)

Thanks for all these constant improvements!

Also: If I'm looking to get started looking into the code on GitHub, is the Issues page or the README better to get a sense of what needs to be done?(The README mentions things like keyboard shortcuts for the editor + a favicon, and both of these seem to be done already, so I'm guessing it's outdated?)

Replies from: habryka4
comment by habryka (habryka4) · 2017-10-06T17:28:45.666Z · LW(p) · GW(p)

The issue page is the correct place to look. In particular the 'Important (Easy)' label.

comment by habryka (habryka4) · 2017-10-06T08:18:24.811Z · LW(p) · GW(p)

Also: Just realized comments seem to not appear for a few seconds after posting them, which seems to be the result of one of the performance things that I've done. I thought it was fine when I first tried it locally, but the delay is a bit larger on the live server, and so I am probably going to reverse that specific change. I find seeing an empty comment after posting really unsettling and I feel afraid that my content might have been lost or something.

Replies from: gjm, habryka4, gjm
comment by gjm · 2017-10-06T13:20:53.815Z · LW(p) · GW(p)

I agree that it's unpleasantly unsettling. What's worse is that (for me) after initially posting a comment, at least some of the time its content never appears at all unless I e.g. edit the comment. I guess some timeout is expiring.

If doing this makes things better in some other way, perhaps there's a way to give a visual indication that what the user is seeing is known not to be up to date but should get refreshed shortly? Depending on what the advantages of the change were, this might be better than just backing it out. Obviously the right thing is to make it so fast that it isn't an issue at all :-).

[EDITED to add:] To my surprise, I find that if I open another instance of the same page it doesn't have the newly posted comment on it, but an empty comment just like the original page where I posted it. So I guess it isn't just a matter of taking time to reload content, but something more complicated. I don't have a good mental model of what might be happening underneath to produce this effect, but my gut says it probably isn't a good idea.

comment by habryka (habryka4) · 2017-10-06T20:11:49.209Z · LW(p) · GW(p)

This should be fixed now. Sorry for anyone who felt unsettled by this.

comment by gjm · 2017-10-06T13:23:41.436Z · LW(p) · GW(p)

(Apologies for the kinda-redundant comment; I wanted to test something that required a new one.) So if I post a comment and then immediately -- while it's showing as an empty comment -- close the window, then the thing-showing-as-an-empty-comment still shows up empty in other windows but can be edited and has all its actual content. So I'm guessing there's some nontrivial rendering process that happens in the background on the server, and until that's done the "rendered" version of the comment is whatever it used to be, which for a new comment is empty?

If so, then (what I assume to be) the fact that this "rendering" process is slow enough to be worth trying to do in the background seems pretty scary. How can that not be really quick?

Replies from: habryka4
comment by habryka (habryka4) · 2017-10-06T17:23:53.150Z · LW(p) · GW(p)

The problem is actually not that the rendering itself is not quick. The rendering itself actually takes practically no time. I just looked into it, and the reason this is taking so long is that while the client renders the comment, it actually waits until the next server polling interval (every 20 seconds on production) to display it, which is actually a quite easy-to-fix bug.

comment by gjm · 2017-10-06T13:29:12.243Z · LW(p) · GW(p)

Aside from the comment-posting bug, this all does seem like solid improvement; thanks!