Since LessWrong 2.0 is a fundamentally different architecture, there were a lot of changes that we made to the site, some of which definitely reduced performance. Mostly we moved from a static website architecture to a web-app architecture, which kind of requires more time to get everything up and running.

Having a web-app architecture comes with a variety of advantages, most of which are captured by "slower startup time but faster reactivity after things started up", and at least given my skillset a much better development experience (I really like developing with the React framework, which I think improved my development speed a bunch).

There are also a variety of things you can't really do in a static website framework that you can do in a web-app framework (and not really much the other way around), and since I had a lot of uncertainty in where I wanted the design of LW 2.0 to go to, I decided to go for the design choices that preserve option-value here. 

I also personally made a bunch of mistakes in some architectural choices early on, that have been difficult to get rid of which had some pretty big negative impacts on performance, that we've been fixing up over the last few months. By now at least initial loading performance should be in the realm of most other website you use on the web (though the addition of the map to the frontpage made things a bit slower again, though that will only be a temporary thing). 

Performance is also a bunch faster for logged-out users, where we do a lot more caching, which we can do because we don't have to get lots of user-specific data. If at least the initial loading performance bothers you, then maybe logging out addresses that, until we fix up a bunch more of the performance problems. 

I definitely care a whole bunch about performance, and a lot of our effort over the past few weeks and months have been going to making that better (mostly digging us out of holes I dug ourselves in when I started working on the project). I think by now things on desktop are basically fine, but I still think there are serious problems with the mobile experience, which on slow phones sometimes can't really deal with the performance overhead of the site. We have a bunch of plans for fixing that, which I expect to go up in the next few months. 

Jimrandomh also has a lot of detailed opinions on this topic, so he might want to chime in. 

In terms of GreaterWrong vs. LessWrong functionality: Greaterwrong has implemented a lot of the core functionality, but in terms of actual things you can do on the site, a lot of things are missing. Here are some examples: 

• Everything related to meetups and events
• All admin dashboards and admin operations
• Editing of sequences and collections
• A lot of comment-truncation stuff
• Sharing users on drafts of posts (I think)
• Recommendations and general view-tracking of posts
• Titles of private conversations and adding users to private conversations
• Obviously a lot of small UI things

Yes, it's slower than old-LessWrong. When we rewrote, we built on a collection of libraries and frameworks which were... not exactly production-ready. This has required a lot of compensatory engineering work to bring performance up to par, and there's still a bunch more compensatory engineering work left to do.

In the few months immediately after the rewrite, it was catastrophically slow, to the point where if you opened a bunch of sequence-posts quickly in new tabs, whichever server from the pool handled the requests would die. It's much better than that now, but it's still not where I want it to be. When it is as fast as I'd like, I plan to write a long post with technical details of what we had to change. In the mean time, yes, we know and we're working on it.