Looks like the Great Firewall or something like it is preventing you from completely loading www.skritter.com because it is hosted on Google App Engine, which is periodically blocked. Try instead our mirror:

legacy.skritter.cn

This might also be caused by an internet filter, such as SafeEyes. If you have such a filter installed, try adding appspot.com to the list of allowed domains.

Site speed issues

HuangKe   September 17th, 2011 8:34p.m.

I absolutely love Skritter. If I had to change one thing about it, it would be the site speed. Certain pages load really slowly, which takes away from the time I should be studying, which is of course the main point of the site. In particular, I've noticed the following (in order of priority):

"Study/all" page: The blue/green graph at the top, showing "X to review / Y added," is not very helpful. For one thing, I'm not sure what "added" means. Added since when? For another, neither of these data points really means much to me. There will always be more to study, even if I somehow get the "X to review" down to 0. Also, the scale is inconsistent. For instance, right now, my graph says "103 to review / 90 added" but the blue "review" bar is about 1/6 the size of the greed "added" bar. And, as The Professor just told me while typing this (nice), the review bar can be a little inaccurate. I'd happily do without this graph if it would speed things up even just a tiny bit.

"Vocab/listsec?" page: Even the official and textbook lists take a long time to load. I notice there is a ton of Javascript on these pages, and I wonder if some caching of the standard lists would help. Maybe the progress could be loaded only after clicking a button, so at least the rest of the page comes up more quickly.

Main "/study" page: There are a lot of graphs and things on this page that seem to slow down the loading. I would totally be willing to give up the whole "X words to study in the next 5 days" section if it would speed the page up by a millisecond. The blue/gray area graphs are pretty meaningless to me, and I'd opt for a cleaner page anyway.

I know each of these things probably doesn't impact the speed of its particular page a whole lot. But I wonder if removing some of this dynamic content (or requiring a button click) would reduce your overall server load and make the whole site a little faster.

To me, the most important features of the site are the vocab lists, studying algorithm, and the practice page. Any bells and whistles (and graphs and server calls) that slow these features down even a little bit is probably not worth it. It might be different if you had Google-type data centers and CDNs. But with the resources you have, I'd try to focus more on site speed. And that iPad app! :)

nick   September 17th, 2011 9:59p.m.

Hi HuangKe; thanks for the feedback about the speed. Making pages load faster is important, for sure. But it's not obvious what's actually taking the time when these pages load. Many of the slow things you noted are actually loaded in parallel with the main content, so they don't slow down the loading of what you're actually after.

For example, the progress in the vocab list section pages only starts to load after the words themselves have loaded and the page is ready to go. The same is true for the main study navigation page: the time taken is really the time taken to fetch the lists that you're studying, not the number of items due or becoming due. So you're not waiting at all for those pieces of information--just which lists you're studying.

Our site doesn't get any faster or slower when you adjust the dynamic load, because we're hosted on Google App Engine, and whenever there's more load, we automatically get more instances to cover it. The only difference is that our server costs are slightly higher, since we're running more instances. (It's too bad that we can't really use CDNs for our dynamic content, as the App Engine servers are often very far from those outside North America.)

Thinking about how the item counts are generated on the study page, where it determines how many items are due for review, has given me an idea how to speed that up, though. Although it's done in parallel, there is a limit to how many connections your browser will hold open in parallel at once, and on the study page itself, that limit becomes relevant. I think I know a good way to reduce the number of connections needed for that review bar. I'll do some testing and see if that can speed anything up.

But perhaps I'll do that after I do the iOS app. Thanks for reminding me of priorities! ;)

HuangKe   September 18th, 2011 1:09p.m.

Thanks for the response. Anything to help the study page load would be great. Every millisecond counts.

Of course, lugging my giant laptop around slows me down as well, so I consider the iOS app a speed improvement as well :)

This forum is now read only. Please go to Skritter Discourse Forum instead to start a new conversation!