Honestly, you're being led down the garden path to failure by broken methodologies, garbage framework nonsense, and bad practices. I guarantee you're using more than double the markup needed thanks to the IDIOCY that are front-end frameworks like Semantic UI and bald faced lies like slopping presentation into the markup.
CSS and Scripting doesn't start loading in parallel until after the HTML finishes, so on top of garbage like Failwind, Bootcrap, "Non-Semantic claiming to be semantic", etc, etc, violating the separation of concerns, you end up having all of the endless pointless classes for NOTHING and endless pointless meaningless DIV slowing down the page load. And NO, throwing more code at it isn't the answer.
I'm an accessibility and efficiency consultant, and I'm CONSTANTLY having to tell clients that their choices of technologies -- like "semantic UI" -- are the root of their problems.
Look no further than their "homepage" example for proof that Semantic UI is utterly and totally devoid of semantic markup practices!
Style slopped in the markup, dozens of separate files in both CSS and "JS for nothing" slowing the page loads due to handshaking, blocking scripts in the head, endless pointless DIV for nothing, a relative lack of proper semantics on things like menus, DIV doing heading's job, numbered headings around things that shouldn't be headings, gibberish heading orders on the things that should be headings... It is a train wreck laundry list of how to build a website. Thus their 9.34k of markup to do not even 4k's job...
Much less the 700k of CSS when sight few legitimate websites have ANY need of more than 48k of CSS in at most two files per media target.
Made all the more comical by their lack of media targets, since like all other front-end frameworks they don't know what that is, and basically say "screen users only F*** everyone else"
THEN you wonder why you're having performance problems.
NONE of these "front end frameworks" are easier, simpler, or better. No matter how many lying propagandists claim otherwise, or how deeply people not qualified to write a single blasted line of HTML run off the cliff like lemmings. ALL claims of being "easier", or "better for collaboration" and so forth are nothing but BALD FACED LIES! They are a monument to the pesky 3i of web development: Ignorance, Incompetence, and Ineptitude. You look at the code for any examples of these "frameworks" it is plainly evident the people who CREATED these systems aren't qualified to write websites, much less have the unmitigated GALL to tell others how to do so!
You want a strong performance mandate? Don't use frameworks, don't use classes to say what things look like, leverage semantic markup, selectors and combinators instead of pissing classes on everything, maintain the separation of concerns.
It's good you mentioned the "moving CSS into the markup" and "loading CSS not used on the current page" too, since both of those are at BEST placebo bullshit, at worst just plain 3i bullshit. The reason being that:
1) few if any websites should have more than 48k of CSS per media target (aka media="screen"),
2) keeping it out of the markup means you are PRE-CACHING SUB-PAGES!
Think about it. If you move above the fold style into every page, it has to be loaded on EVERY page-load and visit. Moving it out of the markup means it is cached for re-visits. loading it all ahead of time means all sub-pages are faster loading due to size. And remember, if you're dynamically generating that markup that smaller size means less overhead for the back-end, simpler code to work with on the back-end, less time packing and unpacking the markup, AND all the LINK and SCRIPT start loading sooner!
Much less since we pre-cache problems like FOUC and other things people dive for JavaScript for in terms of things like SPA? In a lot of cases could be avoided if you skipped the client side scripted trash entirely!
I guarantee you that given what you've said, your performance problems stem from you and your co-workers never having learned how to use HTML or CSS properly. That might seem harsh, but I do such efficiency/speed optimizations for a living, and I'm always coming across the same foolishness. I'd love to give you one of my front-end audits for what you have just to show you how badly you've had the rose coloured glasses slapped on.
This is an epic rant and I respect that. I do want to share one anecdote that pushes back against your general sentiment, just a little. After working on the react-based add product page for a year or so and making a bunch of performance improvements I got invited to help out on another page that was primarily server rendered and used jquery for the interactivity. You know what? It was a really slow and there were almost no easy wins. What there were instead was a bunch of poor architecture choices that needed refactoring with not enough time to do it. Old school problems like not using document fragments when appending in a loop kept popping up. You don't see that anymore when using tools like react, because they manage a lot of low-level optimizations for you. I agree the modern web eco-system makes it way too easy to pull in massive dependencies that are potentially both insecure and slow. But the flip side is often dealing with a make shift framework written by burnt out co-workers long ago who put far less thought into it than even the web framework ™️ snake oil salesman of today. Pick your poison. Do you want the one found at the supermarket in the shiny bottle or some home-brewed moonshine? They'll both kill you at the end of the day.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Honestly, you're being led down the garden path to failure by broken methodologies, garbage framework nonsense, and bad practices. I guarantee you're using more than double the markup needed thanks to the IDIOCY that are front-end frameworks like Semantic UI and bald faced lies like slopping presentation into the markup.
CSS and Scripting doesn't start loading in parallel until after the HTML finishes, so on top of garbage like Failwind, Bootcrap, "Non-Semantic claiming to be semantic", etc, etc, violating the separation of concerns, you end up having all of the endless pointless classes for NOTHING and endless pointless meaningless DIV slowing down the page load. And NO, throwing more code at it isn't the answer.
I'm an accessibility and efficiency consultant, and I'm CONSTANTLY having to tell clients that their choices of technologies -- like "semantic UI" -- are the root of their problems.
Look no further than their "homepage" example for proof that Semantic UI is utterly and totally devoid of semantic markup practices!
semantic-ui.com/examples/homepage....
Style slopped in the markup, dozens of separate files in both CSS and "JS for nothing" slowing the page loads due to handshaking, blocking scripts in the head, endless pointless DIV for nothing, a relative lack of proper semantics on things like menus, DIV doing heading's job, numbered headings around things that shouldn't be headings, gibberish heading orders on the things that should be headings... It is a train wreck laundry list of how to build a website. Thus their 9.34k of markup to do not even 4k's job...
Much less the 700k of CSS when sight few legitimate websites have ANY need of more than 48k of CSS in at most two files per media target.
Made all the more comical by their lack of media targets, since like all other front-end frameworks they don't know what that is, and basically say "screen users only F*** everyone else"
THEN you wonder why you're having performance problems.
NONE of these "front end frameworks" are easier, simpler, or better. No matter how many lying propagandists claim otherwise, or how deeply people not qualified to write a single blasted line of HTML run off the cliff like lemmings. ALL claims of being "easier", or "better for collaboration" and so forth are nothing but BALD FACED LIES! They are a monument to the pesky 3i of web development: Ignorance, Incompetence, and Ineptitude. You look at the code for any examples of these "frameworks" it is plainly evident the people who CREATED these systems aren't qualified to write websites, much less have the unmitigated GALL to tell others how to do so!
You want a strong performance mandate? Don't use frameworks, don't use classes to say what things look like, leverage semantic markup, selectors and combinators instead of pissing classes on everything, maintain the separation of concerns.
It's good you mentioned the "moving CSS into the markup" and "loading CSS not used on the current page" too, since both of those are at BEST placebo bullshit, at worst just plain 3i bullshit. The reason being that:
1) few if any websites should have more than 48k of CSS per media target (aka media="screen"),
2) keeping it out of the markup means you are PRE-CACHING SUB-PAGES!
Think about it. If you move above the fold style into every page, it has to be loaded on EVERY page-load and visit. Moving it out of the markup means it is cached for re-visits. loading it all ahead of time means all sub-pages are faster loading due to size. And remember, if you're dynamically generating that markup that smaller size means less overhead for the back-end, simpler code to work with on the back-end, less time packing and unpacking the markup, AND all the LINK and SCRIPT start loading sooner!
Much less since we pre-cache problems like FOUC and other things people dive for JavaScript for in terms of things like SPA? In a lot of cases could be avoided if you skipped the client side scripted trash entirely!
I guarantee you that given what you've said, your performance problems stem from you and your co-workers never having learned how to use HTML or CSS properly. That might seem harsh, but I do such efficiency/speed optimizations for a living, and I'm always coming across the same foolishness. I'd love to give you one of my front-end audits for what you have just to show you how badly you've had the rose coloured glasses slapped on.
I've written about this a lot over on Medium.
medium.com/codex/so-you-want-to-ma...
medium.com/codex/stop-fighting-the...
This is an epic rant and I respect that. I do want to share one anecdote that pushes back against your general sentiment, just a little. After working on the react-based add product page for a year or so and making a bunch of performance improvements I got invited to help out on another page that was primarily server rendered and used jquery for the interactivity. You know what? It was a really slow and there were almost no easy wins. What there were instead was a bunch of poor architecture choices that needed refactoring with not enough time to do it. Old school problems like not using document fragments when appending in a loop kept popping up. You don't see that anymore when using tools like react, because they manage a lot of low-level optimizations for you. I agree the modern web eco-system makes it way too easy to pull in massive dependencies that are potentially both insecure and slow. But the flip side is often dealing with a make shift framework written by burnt out co-workers long ago who put far less thought into it than even the web framework ™️ snake oil salesman of today. Pick your poison. Do you want the one found at the supermarket in the shiny bottle or some home-brewed moonshine? They'll both kill you at the end of the day.