I was just wondering, is it typical that the loading time of basically any Beeminder goal on the website is above 10 seconds? (I’ve just done some measurements in the network tab of my browser.) I feel a bit stupid asking this now, since it’s been always like this for me, but I admit that it makes the website hardly usable (and it might explain why I was so keen to write that Emacs client I use all the time). Basically, the only way I can use the web client (which I sometimes need) and not go crazy is “do something there, go to another tab/brush my teeth/do some dishes/read a book/etc., come back some time later, do the next thing”, etc.
2 Likes
That’s super-odd! It’s not happening for me loading my goals - both the initial goal-listing page and the individual goals load pretty fast (sub-second for the goal page).
Do your goals have many many data points on them? As I understand it, for the individual goal pages, the graphs aren’t images but are constructed in HTML (EDIT: actually, they’re constructed in XML, which is what the SVG files are under the covers), so if you have a thousand or more datapoints, maybe it’s taking a long time to receive and process those. Maybe you have a goal with fewer datapoints - that might tell you if it’s data-point-count related, by comparing across the two.
If it does look like its data-point-count related, you could further test this out by limiting the date range displayed for a graph - on the Settings tab, use the Graph Settings section, and limit the X-min to a more recent date, cutting down the 1000 data points to 100, say.
Finally, if you’re feeling up to it, you could load a page while using your browser’s Web Developer tools, where there will be a Performance tab (or some similar name), and you can see specifically which thing or set of things is taking so long - I mention this as you’re contemplating an Emacs client, and it’s got to be simpler than that 
Do let us know what you find!
1 Like
The website is fast (< 1s) for me too. I even have some goals with thousands of data points that are all shown on the graph (e.g. floss | byorgey/floss goal page has 2325 data points) and those pages load quickly too.
For individual goals, the graphs are SVG images. So yes, it’s true that the SVG file for a graph with many data points is larger than that for a graph with few data points, but the image is almost surely cached somewhere, not generated on the fly every time you visit the page.
1 Like
My guess is that the issue would be on the browser side, rendering a massive svg…
1 Like
I’ve done a bit of digging, looking at the browser dev tools and comparing two goals with many datapoints: mbork/email-zero from @mbork , comared with byorgey/floss from @byorgey .
Both have many datapoints, but email-zero has a much more complex graph line - maybe 500 different line segments vs 60. In practice, especially given the goal setup, there are lots and lots (thousands) of small line segments for the red line, going up and then back down. So I think @narthur 's guess was right, and it’s the rendering time for the SVG on the browser end. Maybe worth bringing in the X-min setting, see if that makes a difference!
3 Likes
However, email-zero | mbork/email-zero goal page loads almost instantly for me too.
1 Like
My goal with possibly the most datapoints is pjh/flex and it loads within a couple of seconds. The vast majority of my goal pages load as fast as this, as does the gallery.
My goal with possibly the most line segments is pjh/w and it takes just north of ten seconds. It used to be intolerably slow, such that a graph with lots of road changes would take what felt like minutes to load.
Using Edge on Mac, and changed both those goals to show a year’s worth of data in case that mattered.
1 Like
I will take a look at this. There are a few different things we are watching regarding performance, and the likely culprit is related to having lots of segments in your commitment.
(Also, we have good analytics on server time, but we don’t currently have great analytics in the browser for actual render time.)
If you haven’t already said, which browser are you using?
3 Likes
The biggest issue is usually having complicated graph matrices, but I wouldn’t think that would make the dashboard slow, because that (as I understand it) doesn’t have to load the graph matrices. Is the dashboard slow too? I wonder if it might help to know exactly what you’re doing that’s slow, e.g. entering data manually? Requesting data from Toggl (always really slow for everyone, because we have a 2 second limit in there between fetches because of a trigger-happy rate-limiting on their side)? Loading the dashboard?
As an aside for everyone’s general interest, if I remember rightly, even graphs with lots of entries in the matrix will load OK for someone who doesn’t have premium; it’s the graph editor in settings, or the admins’ graph editor, which takes the time.
And yes, this probably counts as working during my day off. disappears in a puff of smoke before Rescuetime catches me
4 Likes
Some insight here, about what’s going on under the covers when an SVG is rendered (and confirmation that slow rendering of complex SVGs is a known problem).
1 Like
For me the dashboard is very responsive, but the goal pages have always felt slow and sluggish (especially on initial load). I use the android app and the dashboard to enter data so it hasn’t really gotten in the way for me personally.
I took a couple screen recordings. Here is one of me clicking into a ‘complicated’ graph; the goal page takes ~20 seconds to load and then a further ~20+ seconds to render the SVG graph. I changed the x-min to simplify the graph and tried again but it didn’t seem to help. This particular graph loads very quickly when I’m not logged in.
The number of entries for the graph editor section inside the settings tab is really, really large. I’m not even sure why some of these entries are here. It’s a do more goal with a slope of 0 and no data entered for March, yet there are 2 entries in the graph editor per day (auto ratcheting getting confused?). 
The large number of entries is consistent with what @shanaqui mentioned at least. Any chance of that section being completely removed (in favor of the new visual editor) or at least lazy loaded? (it seems like it has all the matrix info when hopefully the SVG only requires the range in the window to render)
For me, it looks like my goals with autoratcheting → exceptionally slow to load the page & render the graph. My goals without it → load quickly with no problem. I guess the every-day tweaking of the graph (which is business as usual for my do-less goals that I’m successfully doing less of) makes that matrix blow up.
2 Likes
That’s exactly it for me too. The number of road segments seems to affect load/render times, and so it will particularly affect goals that use autoratchet, weekends-off, and the autodialler.
2 Likes
Thanks for all replies. This seems to explain a lot – most of my goals use autoratchet and many of them use weekends-off, too…
2 Likes
This probably explains why the infinibee seems to keep spinning indefinitely on my ianminds/test goal every time a new datapoint is added using the web interface.
Although its road has a sawtooth pattern, it still has a reasonable sounding number of segments (43). Reloading the page while the bee is still spinning does end up showing the updated graph.