Related

Garmin Connect Web EXTREMELY slow to load with Run/Walk Graph

omnivoracious
6 days ago

It appears there's an issue where loading the page to view an activity in Garmin Connect web is slow if the run/walk graph is on. This issue is present on all runs but seems to get exponentially worse as the time of the activity increases.

Noticed some issues when viewing activities, especially long activities, where loading the page was EXTREMELY slow. This was the same across different browsers/computers/OSes (Chrome and Firefox on Windows 10 and Chrome on Android). Loading a recent long run of four hours takes 12-14 seconds. Loading up a recent 100K race takes a couple minutes, and for a recent 100M race the page hangs for literally 20 minutes before the activity loads. Panning the map is also quite laggy even once it loads.

Noticed I wasn't having this issue when looking at an older race recorded on my Fenix 5 which doesn't not have run/walk detection. Tried some troubleshooting and as soon as I turn off the run/walk graph, those same 100K/100M races above all load in 2-3 seconds (tried both Windows and on Android). The lag with panning the map is also gone with that run/walk graph off.

This issue is specific the graph. If I turn the map layer to run/walk, it doesn't cause any issues. The activities were all recorded with a Fenix 7.

The issue is not present on the Garmin Connect app for Android.

ETA: Also noticed enabling the Run/Walk graph GREATLY increases the memory usage. Without it enabled, a Chrome tab for the 100M run uses 377 MB of memory. With it enable, it uses a comically large amount of memory, 2 GB.

  • 0 6 days ago

    Interesting analysis! I tried to replicate the problem, but the longest trail I have in my account is barely 30km long, and although the loading is a bit slower, the difference is not so horrible - loading time without the Walk/Run chart around 8s, and with it is 20s, so not so easy to spot if you do not focus on it.

    In the DevTools I also see that no additional data is transferred for the Walk/Run chart. Instead, a JavaScript function is used for parsing the pace and acceleration data, and for plotting the graph. And of course, the more data you have, the longer the parsing takes, and the more memory it consumes. 

    So unless you really ultimately need the Walk/Run chart, I recommend keeping the option off, especially when accessing long run activities. Using a faster computer with a big RAM is another option. You can also try reporting it to the Support - there is certainly room for optimizing the JS function (or executing it after the page is already displayed), but TBH I am skeptical about Garmin developers spending time on it, unless there are hundreds or thousands of users complaining about it.

    BTW, when browsing through my longer trails, I see that the option for the Walk/Run chart is completely missing at many of them, and I do not see why, because the trail activities definitely contain some walking sections. Do you have the option at all of your trails?

  • 0 5 days ago in reply to trux

    Yeah, it's something that is noticeable but doesn't become problematic until the activity length is long.

    I'm running a mid level Ultrabook, and none of the other graphs or map of the same run/walk data causes the issue. It's also not an issue in the GC app. I suspect there is some bug that wasn't caught in testing since it doesn't become obvious until the activity length is long enough.

    I do have the option on all of my trail runs recorded with my Fenix 7. 

  • 0 5 days ago in reply to omnivoracious
    omnivoracious said:
    I'm running a mid level Ultrabook, and none of the other graphs or map of the same run/walk data causes the issue.

    The graphs are not transmitted to the browser as images. A javascript function parses the activity data from a JSON data structure to series of HTML tags. Practically all graphs are plotted with couple of "path fill" tags, each of them containing numerous coordinates addressing individual points of the graph.

    The Run/Walk graph is an exception - it consists of rectangles of different colors (for run/walk/idle periods). Each rectangle is described by a tag over 200 characters long (example below). In a ~3 hours long trail I have 22,000 such rectangles, and together with the remaining code describing the run/walk graph, all the code weights almost 6 Mbytes, which is already really huge amount of HTML code for a graphical chart. At a 100 miles trail, especially if you use the Every Second Recording mode, the size of the code will be proportionally bigger (likely an order of magnitude if not more), and it is no surprise it takes the browser a long time to parse.

    <rect x="112.6641357749" y="0" width="1" height="1" fill="none" class="highcharts-a11y-mock-point" opacity="0" fill-opacity="0" stroke-opacity="0" tabindex="-1" aria-hidden="true" style="outline: none;"></rect>

    The conclusion is, unless Garmin changes the type of the graph to use a more efficient method than those tens or hundreds of thousands of rectangles, or unless they optimize the code in a different way (for example removing all those empty rectangles like in the example above), there is no chance to get the charts loading fast. At least not without using a superfast computer.