They have put in ticket with ops that the server is slow and could we look at it. So we looked. Every single video on a page with long video list pre-loaded a part of it. The single reason the site didn't ran like shit for them is coz office had direct fiber to out datacenter few blocks away.
We really shouldn't allow web developers more than 128kbit of connection speed, anything more and they just make nonsense out of it.
Combined with CPU throttling, it's a decent sanity check to see how well your site will perform on more modest setups.
I naturally assumed that it was my code that was the problem (because I'm often the programmer equivalent of the Seinfeld hipster doofus) and spent the next few hours optimizing the hell out of it. It turned out to be unnecessary but I'm kind of glad it forced me into that "profiling" mindset.
Developers really ought to test such things better.
Alternatively, run uBlock Origin and NoScript and you probably won't need it.
You can make it look like any feature in any UI is hidden by choosing the longest path to reach it, using many words to describe it despite the target audience already knowing this stuff, and making your windows as small as possible.
Moreover, that a developer tool is a bit hidden in submenus in a UI designed for nontechnical users is fair game.
Even considering this, right click > inspect or Ctrl+shift+k also gets you the web developer tools. Not that hidden.
And then usually the network tab is visible immediately, it is one of the first tabs unless you moved it towards the end (even then, usually all the tabs are visible; but it's nice you can order the tabs as you want, and that a scroll button exists for when your window is too small -- and if the web developer panel is too small because it's docked at the left you can resize them, dock to bottom or undock).
This stuff is pretty standard across browsers, it's not like Firefox's UI is specifically weird for this. I don't have ideas for improving this a lot, it looks quite well designed and optimized to me already.
And then no, ublock Origin and No Script can't help you optimize the size of the web page you are working on. You ought to unblock everything to do this. They are a solution for end users, who have very few reasons to use the throttle feature. And unfortunately for end users, blocking scripts actually breaks too much to be a good, general workaround against web pages being too heavy. I know, I browse the web like this.
The single-line change of adding loading=lazy to the <img> elements wouldn’t fix everything, but it would make the page at least basically usable.
Marketing dept. too. They're the primary culprits in all the tracking scripts.
Marketing and managers should be restricted as well, because managers set the priorities.
You're describing the web developers again. (Or, if UX has the power to demand this from software engineering, then the problem is not the UX designers.)
Recently had to put so many huge blurs that there was screen tearing like effect whenver you srcolled a table. AND No i was not allowed to use prebake-blurs because they wouldnt resize "responsively"
But sure, the current state of brokenness is a result of a combination of overambitious designs and poor programming. When I worked as a web developer I was often tasked with making elements behave in some bespoke way that was contrary to the default browser behavior. This is not only surprising to the user, but makes the implementation error prone.
One example is making a form autosubmit or jump to a different field once a text field has reached a certain length, or dividing a pin/validation code entry fields into multiple text fields, one for each character. This is stupidity at the UX level which causes bugs downstream because the default operation implemented by the browser isn't designed to be idiotic. Then you have to go out of your way to make it stupid enough for the design spec, and some sizeable subset of webpages that do this will predictably end up with bugs related to copying and pasting or autofilling.
Less useless shit popping up (with ad block so I mean just the cookies, store location etc harassments) Store selector didn't request new pages every time I do anything; resulting in all the popups again. (just download our spyware and all these popups will go away!) Somehow my page loads are snappier than local stores despite being across the planet.
Not saying it's a good site. It's almost the same as Home Depot. Just slightly better. I mean there's an AI button for searching for a product so you can do agentic shopping with a superintelligence on your side.
I was asked to look at the site when it was already live, and some VP of the parent company decided to visit the site from their phone at home.
[1] https://css-tricks.com/test-your-product-on-a-crappy-laptop/
If you’re willing to build some infra, there’s probably a lot more you can do—nightly slow-hardware runs come to mind immediately, browser devtools have a convincing builtin emulation of slow connections, a page displaying a graph of test runtime over time[1] isn’t hard to set up, etc.—but I don’t really have experience with that.
[1] See e.g. https://arewefastyet.com/win11/benchmarks/overview?numDays=3....
Even if you don’t fix them, knowing where the weak points are is valuable for when they do snap in production.
Similarly, a colleague I had before insisted on using a crappy screen. Helped a lot to make sure things stay visible on customers’ low contrast screens with horrible viewing angles, which are still surprisingly common.
There are good reasons to have a small cheap development staging server, as the rate-limited connection implicitly trains people what not to include. =3
I'm so happy to have seen their web site that I want to do business with them, even though I have no business to be done.
Bitlbee saved (and still saves) my ass with tons of the protocols available via IRC using nearly nil data to connect. Also you can connect with any IRC client since early 90's.
Not just web developers. Electron lovers should be trottled with 2GB of RAM machines and some older Celeron/Core Duo machine with a GL 2.1 compatible video card. It it desktop 'app' smooth on that machine, your project it's ready.
You're not insightful for noticing a website is dog slow or that there is a ton of data being served (almost none of which is actually the code). Please stop blaming the devs. You're laundering blame. Almost no detail of a web site or app is ever up to the devs alone.
From the perspective of the devs, they expect that the infrastructure can handle what the business wanted. If you have a problem you really should punch up, not down.
If a bridge engineer is asked to build a bridge that would collapse under its own weight, they will refuse. Why should it be different for software engineers?
You're not even arguing with me BTW. You're arguing against the entire premise of running a business. Priorities are not going to necessarily be what you value most.
I’ve seen a lot of times where “business people” ask for a feature that sounds good but isn’t technically viable for any number of reasons. The devs not doing pushback would lead to similarly non-functional/broken stuff getting shipped.
The pushback doesn’t even need to be adversarial, just do some requirements engineering, figure out what they want and go “Okay, to implement X in the best possible way, we should do Y and avoid Z because of W.”
In the bridge analogy, the people who are asking for a specific design might not know that it’d collapse under its own weight and the engineers should look for the best solution.
There are environments where devs can't do that sort of requirements engineering and those are generally pretty dysfunctional - obviously you don't need that for every feature request, but it's nice to have that ability be available when needed.
> From the perspective of the devs, they expect that the infrastructure can handle what the business wanted. If you have a problem you really should punch up, not down.
this belittles the intelligence of the dev team. they should know better. it's like validating saying "i really thought i could pour vodka in the fuel tank of this porsche and everything would function correctly. must be porsche's fault."
Oh, and the rest of the business doesn't even know what a car or gasoline are!
The blame clearly lies with the contradictory requirements provided by the broader business too divorced from implementation details to know they're asking for something dumb. Developers do not decide those.
Developers often do push back and warn against ideas that have too many compromises, but cannot outright say no just because of that. There are too many other people involved.
You seem to think that any one person/group has/wants/should have full control when deemed necessary. That doesn't make sense unless either the success criteria are lacking (you call the shots alone and probably miss a ton of opportunities), or the requirements are so constrained that all the work is just optimizing the implementation (someone else already called the shots without you).
If your work is either of those situations it means the business plan sucks. AI is the least of your worries.
Some are just flat out refused as they are just too stupid and will cripple the system in some way.
Failing that, interpret the requirements.
Nobody can watch a bunch of videos at once that don’t even show up until you scroll! That’s a nonsense requirement and the dev’s failure to push back or redirect in a more viable direction is a sign of their incompetence, not that of the non-technical manager that saw YouTube’s interface and assumes that that’s normal and doable.
It is! You’d have to know about lazy loading and CDNs, but neither is black magic.
I suppose you've never experienced the corporate hell that can happen with a CDN. The dev could submit a dozen servicenow tickets only to see half of them rejected by those same incompetent non-technical managers, or they could just make the thing work now and move on.
The next project will be better after the dust settles and those rejections have been reviewed and escalated into proper discussions. Nobody tells the story of that project because it does the things everyone expects. Guess who led those discussions and fought to get the meetings on the calendar? The "incompetent" devs of course!
But hey, if you want to rail against incompetent developers who exist in a make-believe world where they hold all the power are simply too lazy and incompetent to 'do the right thing' then go ahead!
Me: we cant do X bceause it has Y and Z implcations for end users
Manager: It fits our brand and we have to do it.
Dev: I can do it and the implications are mitigated by (handwavy explanation)
Maanger: sounds good. (To me) Maybe you can make a (useless) diagram for this featuer that will be realy handy for KT
--Days later--
Feature is delivered and the Y and Z were ethier not mitigated or there was a attempt-ish to mitigate them
Stop making excuses and start taking ownership and responsibility of your craft.
I work in huge government departments, large financial orgs, and other "enterprise" places that are the poster child for the "realities of corporate environments".
Automatically saying "yes" to everything makes you a useless meat robot.
If you do everything that the customer asks, without push back, negotiation, or at least a deeper understanding, then you will produce broken garbage.
I see this all the time: "The customer asked for X, so I pressed the button!" is the cry of the incompetent junior tech that will never be promoted.
Nobody wants a uselessly slow website. Nobody wants to piss of their customers. Nobody wants angry rants about their online presence to make headline news.
What the customer wanted was multi media content. That's fine. The technical specifics of how that is presented is up to the engineering team to decide. You're not advisors! You own the technical decision making, so act like it.
If you make the decision to shove nearly a gigabyte down the wire to show the landing page, then that's on you. The manager asking for "video clips" or whatever as the feature probably doesn't even know the difference between megabyte and gigabyte! They shouldn't have to in the same way that I shouldn't have to know about my state's electrical wiring standards if I get a sparky out to add a porch light. If my house burns down, that's the electrician's fault, not mine as the customer!
Similarly, if someone asks for lights inside their pool, an electrician that strings ordinary mains cabling through the water should be jailed for criminal negligence. Obviously, only special low-voltage lighting can be used in water, especially near people. Duh.
Act like an electrician, not like a bored shopkeer who's memorised the line "the customer is always right" without realising that the full quote ends in "... in matters of taste."
https://en.wikipedia.org/wiki/Conway's_law
Have a wonderful day =3
The responsibility of the devs is to deliver what was asked. They can and probably do make notes of the results. So does QA. So do the other stakeholders. On their respective teams they get the same BS from everyone who isn't pleased with the outcome.
Ultimately things are on a deadline and the devs must meet requirements where the priority is not performance. It says nothing about their ability to write performant code. It says nothing about whether that performant code is even possible in a browser while meeting the approval of the dozens of people with their own agendas. It says everything about where you work.
We always have discussions here about how you have to learn to talk to communicate your value to clients in a language they understand. Same goes for internal communications.
Software development isn't factory work. And factory workers are expected to notice problems and escalate them.
Anyway, they're paying me far too much to have me turn off my brain and just check the boxes they want checked in all situations. Sometimes, checking boxes because they need to be checked is the thing to do, but usually it's not.
We're definitely way past the point where there is a singular definition of what "software development" is supposed to mean.
I also didn't describe anything like factory work.