Kind of a low effort article? Forms an opinion on web perf trends based on a design awards site, pulls some basic stats you can find on wpostats.com, and then uses irrelevant metrics such as page weight[0] instead of user centric perf metrics[1].
Yes websites have become more complicated[2]. HTTP Archive has been tracking that for a long time. But this isn’t new. And actually web performance isn’t getting worse, it’s been getting better[3].
> irrelevant metrics such as page weight[0] instead of user centric perf metrics[1].
I don't know if that is irrelevant to the argument "Web Designs are Getting too Complicated".
The argument as stated is kinda ambiguous.
Lets say I wrote a small web app that consisted of exactly 5 input forms with not more than 4 input elements each, backed by a database of 3 tables.
If my front-end uses a tech depending on eleven 3rd party components (vite, npm, a treeshaker, a linter, react, redux, tailwind, sass, graphql, websockets, typescript) then you can get into the situation where both these things are true:
1. The user PoV is that this is a simple webapp which is easy to use
and
2. The developers PoV is that this is an over-engineered design that could have been done in a day with no build-step nor anything beyond HTML, CSS and Javascript.
Yes the fuzzy use of “complicated” is part of the problem with this article. I am assuming “complicated” here means it’s consequential to users from a bad UX perspective because the article mentions some business stats:
> Google's research shows users form opinions about websites in 50 milliseconds. If your site takes over 3 seconds to load, you've lost 53% of mobile users. Amazon found every 100ms delay costs them 1% of sales.
In which case, my argument still stands that they’re focusing on the wrong perf metric (page weight).
The least complicated webpage is a blank page, but users won’t find that too useful. That’s why we don’t use page weight as our North Star in the web perf world
I get what you’re saying, but I also think the two are strongly correlated.
If you have a website with excellent UX, but it’s massively bloated and has noticeably slow load times on anything less than a 1 Gbps connection, that’s making for a frustrating experience for a large swath of your users (though maybe you also are targeting a niche crowd and know that they all have adequate internet speed).
It’s also possible to have both. McMaster-Carr [0] had its web dev moment last year when tech influencers rediscovered what basic performance optimizations can do, but hype aside, it’s legitimately good design (to me). It’s simple, intuitive, and fast. It’s nothing it doesn’t need to be.
How fast can I use it, how smooth can I use it, etc.
My point is about how good can I do what I want to do on a website.
For instance a shopping site can as fast and snappy as it likes, if I can’t find the right articles is useless.
Amazon and ebay come to my mind who ignore even simple exact search terms just to show things I didn’t search for.
> Looking at performance is making the second step before the first.
I'm not sure I agree. Bad design can ruin a fast UI, and bad performance can ruin a good UI. I'm not sure one is more important than the other, because they're necessary parts of the UX. They should be designed for together, not independently.
I don't know if that is irrelevant to the argument "Web Designs are Getting too Complicated".
The argument as stated is kinda ambiguous.
Lets say I wrote a small web app that consisted of exactly 5 input forms with not more than 4 input elements each, backed by a database of 3 tables.
If my front-end uses a tech depending on eleven 3rd party components (vite, npm, a treeshaker, a linter, react, redux, tailwind, sass, graphql, websockets, typescript) then you can get into the situation where both these things are true:
1. The user PoV is that this is a simple webapp which is easy to use
and
2. The developers PoV is that this is an over-engineered design that could have been done in a day with no build-step nor anything beyond HTML, CSS and Javascript.