I never thought to check my banks login pages, as I never had an issue with the loading speed. I had other issues (related to bad bank related service) so I changed a couple of banks.

Current banks login pages are a bit below 3 MB.

I see it as a prioritization issue. Are you happy with your bank services except the size of the (login) pages? Probably they focus on what they should as there would be more customers switching due to bad service than to page sizes. There are probably few scenarios where 10 MB is a problem - most of it should get cached anyhow after the first load.

Well, I had never looked at how much our login page weighs, but it's 65KB [1].

Please shoot me if it gets over 1MB!

[1] https://play.tirreno.com/login

The bank that we use (and are unable to change due to the B2B nature of our operations) sucks in every aspect of relations. Both offline and online.

I think it's absolutely normal to be an expert (in web development) and measure businesses based on their web apps. And yes, if an organization where online is a critical point, such as banks nowadays, ignores the problems with their code, this is most probably a sign that the entire organization is broken.

In my case this is a 100% match.

It will be 150mb when accessible due to even more frameworks.

Just on the contrary, critical applications such as government services or banking could provide a light version that just works, maybe a simple HTML/CSS frontend without heavy frameworks to ensure that the service is deliverable.

Once I faced an issue with the SBB ticket system (Swiss rail tickets) that was not working on my iPhone (maybe 8), not in Safari on macOS, and I needed to buy a ticket on the train as in this particular place there was no offline ticket service.

Such services indeed must have a minimal requirements version.

less javascript + less dynamically loaded/changed content is the solution to web accessibility

Tell that to the developers that are 5 years, 1 million lines and 500 TODOs deep into their legacy React banking frontend. Adding stuff on top of your existing hacks is easy, taking unnecessary code away is hard. Especially if all your training on web accessibility was a one-day workshop where you never actually learned how to do anything, only why you need to do it.

Source: I used a frontend developer working on a big bank frontend. The existing UI stack was horrendous and deadlines and bank politics wouldn’t allow you to refactor anything. Just build shit on top and hope that Jenga tower of a web application doesn’t fall apart halfway there.

Thank you so much for sharing this! This is absolutely exactly how it feels.

I believe the most important point here is the internal business politics that allows such an approach in development. Once I was curious and tried to find out how private banks' front ends look, and I was surprised to learn that they used minimal frameworks (sometimes none) and obviously zero external resources.

One thing is clear: if the business structure allows 10MB for a login page, this is not only about the front-end, this could be about all services and could spread much wider.

BTW, the bank that we use (with the 10MB login page) totally sucks in every aspect of business relations as well.

is that not mostly defined in the HTML part?

This is unhinged FUD. I have some websites, that needs to adhere to the new rules. It was fairly easy to do. One of them is a react app with mantine components. I was done in less than a day.

For banks, they should mandate FinTS/HBCI instead, so folks don't have to use the bank's bloated websites/apps and instead use banking apps that can connect to any bank.