This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Data loading on connect web is not optimized

Hi,

Lastly the connect web app was pretty slow for me, and I just discovered why. The data loading is absolutely not optimized.

ex :

https://connect.garmin.com/modern/gear => click on a link to show a popup with all activities for a gear. In my example I use my shoes totaling 118 activities / 960km.

To show this popup, you need 4 data fields for every activity : Id, Name, Date, Distance. 472 fields in total .

But, the website loads a complete stack of 220 fields for each activity, resulting in a JSON response with 28 568 lines & 700Kb of data transferred.

Loading less data would immediately result in a more pleasant user experience (quicker response time, less compute on client side), and would even be a pretty significant saving for Garmin, as processor usage time & bandwidth are costly.

Just saying :)

erratum : the transfer size in "only" 50Kb, thanks to compression.

0 peseriusz over 1 year ago

...so don't be surprised when Garmin is hacked, it's all about quality https://www.cshub.com/attacks/articles/incident-of-the-week-garmin-pays-10-million-to-ransomware-hackers-who-rendered-systems-useless

0 BunBun! over 1 year ago

For sure it could be done better, for example it's still trying to load gear and badges on public activities, but server returns 403 when not logged in. They should either fix permission or remove those calls if indeed they wanted to hide gear and badges from not logged in users.

But JSON for gear - it's compressed on the fly, so for ~120 activities it transfers ~35 KB. It's ~700 KB after unpacking. On network tab there are two columns: transferred and size. So it's not that bad for transfer. Though, they changed it lately to load all activities, earlier it loaded only some latest and older after scrolling.

0 JimmyFL over 1 year ago in reply to BunBun!

Sure, the transfer size is "only" 50.2Kb. and it takes "only" 1.48s. But considering you only need 472 short string fields it's huuuge and slow.

The transfer size is not the only metric that matters. Database access, compute power for compression/decompression, RAM usage, .... In the scale of Garmin it really makes a difference. And even more if they're running in a cloud service, where you pay per usage.

The issues it not loading all activities at once, it's the colossal amount of unnecessary fields, often empty, that's transferred.

0 BunBun! over 1 year ago in reply to JimmyFL

Yes, of course removing unnecessary calls and not used data from requests would be a good thing. The site loads quite long.

Though earlier Segments had auto match feature for all existing activities, so after creating a segment you got all times you already made on it. With more and more activities for sure it used more server time, but instead to optimize it, they just replaced it with manual match button for each activity.