Slow Performance after importing years worth of transactions (edited)

Same issue with a very slow experience after all transaction data is imported.

Similar story to the latest comments. Transferred my data (~14K transactions) from mint and web application is way too slow - changing categories and payees takes a substantial amount longer than what it should likely take.

Troubling to say the least that Quicken Simplifi has been working on this for three years. I wanted to stick with Simplifi, but if issues persist it'd be difficult to stay.

@Coach Natalie

Are we still using the feedback method to submit our issue?

Wow this had been an issue for almost 2 years and still no resolution. I just imported all my Mint transactions and it's painfully slow to do anything now.

Hi. I had added a few comments to this thread (this morning) but they appear to be missing now.

I just wanted to point out that this issue is not related to importing large amounts of manual transactions. I just exported all of my Simplifi transactions, and I only have data going back to November 2019 (so it has only been 4 years) and I only have a total of about 9000 transactions over that 4 year period.

I think grouping this issue under the topic of "Slow Performance after importing years worth of transactions" isn't accurate since it seems like I and many others on this thread can reproduce the issue without doing manual imports at all.

Another interesting find from the MS Edge DevTools…

This is in the Console when I try to do actions (edit notes, etc) in Simplifi. I asked Bard what "TTI for txnSave is too slow" is and got this answer:

"The Time to Interact (TTI) is a performance metric that measures the time it takes for a user to interact with a page after a user input event. The TTI for txnSave is too slow, which means that it is taking too long for the page to respond to the user's input. This can be frustrating for users, and it can also lead to a decrease in user satisfaction."

https://g.co/bard/share/98491d49cbb2

@perrynmyers you'll notice that @kai4387 came to a similar conclusion about local data encryption taking a significant portion of time back in April 2022 on page 1 of this post's comment thread. Seems like the same thing is still happening a year and a half later and is still a major bottleneck.

Ok, this is really interesting.

I decided to redo the performance profile on both Edge and Chrome but after clearing my browser caches. Things were much more responsive, and when I tried profiling UI transactions/updates, I no longer saw any calls at all to encrypt. The breakpoints I had in the debugger were never being triggered.

Then I simply F5 refreshed the browser, and things immediately slowed down to where they were before. And now when I profile I see the calls to encrypt again.

What this tells me is that when someone logs into Simplifi on a clean browser (including an Incognito session) their performance will be good, because for some reason on that initial login it doesn't try to persist anything to a local cache.

But, once you close the window and reopen it (or just refresh the page), it reverts to the behavior where the local cache has to be updated and encrypted with every UI interaction.

I have absolutely no explanation for why this would be…

Actually, quick update… I can reproduce this without even doing a browser cache clear. Here's the steps:

1. Log out of Simplifi and log back in. In this initial login session, the UI is responsive and profiling of UI interactions shows no encrypt calls.
2. Refresh the browser and now UI interactions will start causing encrypt to be called, which slows down the UI responsiveness.
3. Log out of Simplifi and log back in, and it'll go back to good UI responsiveness and no calls to encrypt on UI transactions.

Using an Incognito window of course simulates the above, since in a new Incognito window you're always logging in fresh. But the issue seems to be between the initial session created in the app on first login, vs. what happens when you close the window and reopen it (and therefore don't need to login again).

I just logged in fresh and have a good working instance right now (i.e. it is responsive and not calling encrypt). I'm going to let this window sit open overnight and see if it has the same behavior in the morning.

@perrynmyers @josh_shannon Another cause for latency (at least for me behind a proxy), is the absurd amount of calls to tracking / UX sites such as clientstream.launchdarkly.com/… and sessions.bugsnag.com/. These tracking sites are called for every single character that I type in the transaction search bar and cause serious delay between typing and results. You can see in your URL bar that the things you type are appended to the query string as ?displayNode=all&q=foobar (emphasis on the foobar) and for whatever reason, the site is deciding to call out to these sites for every single letter. For me, the browser is waiting on the response from this sessions.bugsnag.com/ between 150–250 ms PER LETTER.

Or another example is when I cleared the search terms, Simplifi called out to <LONG_STRING>.cloudfront.net/track/?verbose=1&ip=1&_=<LONG_STRING> with a whole host of tracking data (somewhat redacted below since I don't know what is personally identifying):

[
{"event": "active","properties": {"$os": "Windows","$browser": "Microsoft Edge","$current_url": "https://app.simplifimoney.com/transactions?displayNode=all","$browser_version": 119,"$screen_height": 1080,"$screen_width": 1920,"mp_lib": "web","$lib_version": "2.47.0","$insert_id": "<STRING>","time": <FLOAT>,"distinct_id": "<STRING>","$device_id": "<STRING>","$initial_referrer": "$direct","$initial_referring_domain": "$direct","client_type": "Simplifi Web App","quicken_year": 2023,"$app_version_string": "3.92.0","$app_build_number": 22825,"$device": "desktop","$user_id": "<STRING>","qcs_id": "<STRING>","dataset_id": "<STRING>","dataset_platform": "ACME","dataset_created_by": "acme_ios","scope": "openid qcs.me qcs_acme_beta uaa.user","groups": "oauth.approvals,openid,password.write,qcs.me,qcs_acme_beta,scim.me,uaa.user","source": "QUICKEN","subscription_status": "subscribed","purchase_channel": "direct","subscription_tier": "acme-basic","subscription_tier_name": "Simplifi - Basic","subscription_state": "trial","subscription_term": "annual","auto_renew": "on","entitlements": [
"ACME_BASIC"
],"persist": true,"keep_logged_in": false,"proxy": true,"pathname": "/transactions","memory_device": 8589934592,"memory_limit": 4294705152,"memory_used": 103648109,"memory_available": 4191057043,"is_chromebook_twa": false,"token": "<STRING>","mp_sent_by_lib_version": "2.47.0"}}
]

The above doesn't seem like much, but it's a 1,528 byte transaction which took 1.71s of queing, 286ms of connecting to cloudfront, and a further 115ms of waiting for cloudfront (a total of over 2.1s) just to clear my search bar!

There's also a site called pendo.io that I don't fully understand (they call themselves "The all-in-one platform for breakthrough digital experiences" enabling the dev team to "See the behavior behind the data. Watch video playbacks of how users navigate your app, so you can find the irrefutable evidence to make smarter, more impactful product decisions."), but is clearly another resource hogging tracking provider that's used by Simplifi, and it gets called a ton by the web app.

Overall, the site just seems to be quite poorly designed with an insane amount of blocking, heavily invasive and tracking JS interactions and excessive overhead as you've found for the encryption for the entire transaction history. If you're going to be extremely invasive in your tracking, at least be fast like Google.

Fair point @RobWilk … might be better suited to a new thread.

@Coach Natalie Thanks!

Can confirm that engineering knows that the lag issues are definitely related to the encryption of the entire transaction store on every UI transaction?

And did you share with them the profiling data that I generated?

With this root cause analysis done, I think the issue should be fixable in a few days at the most. It just comes down to the developers deciding on an optimization path. For example, given my comment above, you could treat every "refresh" of the app the same as the initial login, meaning that there is no local caching of the transactions file needed.

Thanks!

Perry

@esender See the analysis above. This isn't an issue with round trip networking latency, or even server delay. The issue in a nutshell is that on every client side interaction the Javascript in the browser is reencrypting the entire transaction store and persisting that to disk.

We've provided tracing to prove where the issue is (see above) and even suggested some ways they could design a solution to avoid the issue.

So far the only feedback we have gotten is "Our product team is aware of the issue and they are working to resolve it as quickly as possible.", and that was now a week ago.