Safari (iOS) is working, but I haven’t checked the speed.
I only use my mobile version to complete my daily wellness and RPE/Feel data, or to manually move a workout (for athletes) when required. Screen is too small for these aging eyes 
1 Like
Safari on iOS is much faster than before for me. A huge improvement… 
1 Like
Really fast, now I can keep Calendar view and pull up previous years almost instantly (before, I had to use list view).
However if I:
- pull up an activity older than last week
- then click Activities on left navigation
nothing appears:
until I manually force a page refresh, and then calendar appears.
Latest iOS and macOS
1 Like
Checked calendar view loading this morning. Notably faster. It loads instantly. Zero lag.
1 Like
Thanks. I just fixed that bug. It was unrelated to this protocol stuff but a result of the deep-linking work I did a little while ago.
I have added binary protocol support for events (races, planned workouts etc.). This will help athletes with a lot of non-activity stuff on their calendar.
Thank you.
The performance improvement is huge. Really appreciate having a very responsive site when pulling up workouts from past seasons.
1 Like
I just enabled binary protocol for activity, wellness and events. FYI, I use hardened Firefox.
1 Like
Using Android mobile with activity binary protocol, running pace zone percentages are displaying up to 15 decimal places. Display is normal when binary protocol is turned off.
Also just checked Linux x86_64 desktop and it is the same as above.
Thanks. I have just fixed this.
1 Like
I have added binary protocol support for chats. If you have a lot of chats (I have 600+!) then this helps.
2 Likes
Should this affect the load speed of the /compare page? That is the one I am most interested in seeing a speedup on (and it still takes a long time with binary fetching enabled)
1 Like
No these speedups won’t help with that page. How many activities are you comparing? It shouldn’t be particularly slow. It might take a while to get data if you compare activities that you haven’t looked at in the last 30 days because data has to be fetched from cloud storage.
Looking at the season compare page, not activities compare. It takes about 2 minutes to fully load in the last 4 years of data.
So far so good with the new binary protocol!
I have no chat’s, but as soon as I enable “binairy chats protocol” no activities will be loaded.
If I uncheck the protocol they load fast, but enabeling the protocol again and nothing loads.
This is on Android Chrome.
I have fixed that bug, will deploy tm. Tx.
There is a general problem with Safari on Mac and iOS and the binary protocol, not just with chats. Binary messages above a certain size cause the WebSocket connection to close. Activities “work” because the server streams them back in small batches. I spent half of today trying to figure this out.
I have added support for browsers stuck behind corporate proxies that block WebSocket’s. Unfortunately this means that if the binary protocol causes Safari to break it is likely to fallback to SockJS. You might not notice immediately but the performance is much slower. This is what appears at the bottom of the /settings page:
You should turn off the binary protocols one by one (starting from the bottom of the list) to see if that works.
1 Like
It looks like the issues with Safari and the binary protocols are fixed. Please turn all of them on and post if you run into anything. For the Java devs out there: I had to replace Tomcat with Jetty. It seems Tomcat does something with binary WebSocket messages and compression that Safari doesn’t like.
1 Like
The binary protocols are now enabled by default for everyone. If you had previously used the checkboxes on the /settings page to toggle them on/off these take precedence.