

Is there even anything you can do to address that kind of perf problem? Yuck. No idea if it gives any insight into what's going on, but there y'go. Here's the profiling session in case it helps. Activate a profiling session: Command-option-I, click performance tab, command-E to start recording So, devs, if you happen to read this, the process is:ģ.

As you can see, it's 100% pegged at rendering whenever I uncollapse a thread. I just did a profiling session to figure out what the heck it was doing: But it handles all modern sites just fine, so it was surprising.ĭefinitely spikes something to 100% on each load: and the CPU graph is a nice timeline of me reloading teddit.ĮDIT: Oof. I guess my perf problems aren't really relevant. So if you do use this, I guess don't overdo it. Pages also seem to take around 10 seconds to do the initial render. Somehow it takes 4 seconds to un-collapse a toplevel comment in Chrome. Not sure where the focus on people with disabilities came from, it's important, but accessibility is much bigger than just that. One only has to look at the definition of the word "Accessibility" to see why you're wrong: "accessibility - the quality of being able to be reached or entered - the quality of being easy to obtain or use - the quality of being easily understood or appreciated". If you're audience is mainly in South America, working on making your application accessible, means making sure your application has low bandwidth usage, can deal with high latency and jitter, and works well for phones. Accessibility is mainly about maximizing the reach, not just for people with disabilities but people in any situation.įor example, people who live in South America usually have a lot worse internet connection, and more likely to be on mobile networks, than people in the west. Accessibility is often thought of as just making things accessible to people with disabilities, but it's not just that.
