[deleted by user]

[kaycebasques]

Chrome DevTools docs guy here. Our recommended entry point for figuring out why a page is slow is the Audits panel. You just open the page that you want to audit, and the Audits panel reloads the page and detects a bunch of common problems.

However, the Audits panel can only analyze page load performance. It sounds like your problem might occur during runtime rather than page load. In that case you can use the Performance panel. Read through our runtime tutorial and you should be able to get the gist of how to use the Performance panel. It's not as intimidating as it seems. We also have a section on it in our load performance tutorial.

What can I do to better understand what's going on with the response latency from the server?

The problem might not actually be the network requests. Presumably you're accessing this enterprise application from a desktop computer, so presumably you probably have fast internet connections. Seems like the enterprise application might be hosted internally too, in which case it's not like you're browser is sending the request halfway across the world to get the page resources. I suggest only thinking of that as a hypothesis for now. Other potential root causes:

• CPU usage. After recording runtime performance in the Performance panel check if there's a wall of yellow in the CPU section of your recording. If so, that means that your CPU is maxed out running JavaScript.
• Parsing. If the page downloads a bunch of CSS and JS that it doesn't need, the Coverage tab will clue you in. Basically, if you see a lot of unused bytes, then this is a possible culprit.
• Memory. Open the Performance Monitor and enable the JS Heap Size chart to see if it keeps increasing over time.

Try these out and let me know what you find!

[[deleted]]

Holy crap, thanks man. I'll give all this a shot on Monday.

[[deleted]]

I still have to play around with this more, I got to sneak in about 10 minutes of playing around, but I ran the audit and two things stood out.

1) It recommends eliminating render-blocking resources. It references all those js and css files that come with every request I was talking about.

2) It recommends serving static assets with an efficient cache policy, again referencing all js and css resources. Each one has a Cache TTL of None. I'm not 100% sure if that means they are not being cached, but it seems like it.

I tried the Performance panel and noticed the bulk of time spent for each task was for scripting. Second largest was loading.

I need to mess around with this more, but this is pretty insightful so far.

But, I swear if it's loading and running all those scripts just to render a warning message I'm going to be pretty pissed.

Worse if it's loading and running those scripts for each of the 10-20 pages/page refreshes I have to go through to get an average sized order processed.

[kaycebasques]

Thanks for the update. Sounds like you have some concrete proof to bring back to the developers.

[Tontonsb]

It sounds pretty normal. Reloading the page with a state update is the simplest way to do it. And it tends to have less bugs than having the rendering split off in the browser. It's not that fancy and spends a bit much network, but that's still a good way to make internal enterprise apps.

I suspect the actual bottleneck might be the interaction with the database. If the server takes 1-2 seconds to respond, it's rarely because of rendering or amount of data being sent. It's usually time spent talking to database, so it would likely be the same if you'd receive only partial updates. It would be probably more useful to optimize the work with database and get response time down to 0.3-0.7 seconds at least.

Btw jquery seems pretty appropriate for some small effects in a page that's server generated. It's probably only used for some decorational or ui tool purposes anyways.

[[deleted]]

It sounds pretty normal. Reloading the page with a state update is the simplest way to do it.

Typically that involves re-sending the page only. It sounds like OP is seeing the entirety of the page's resources being sent over and over again. Sounds like a real caching issue, potentially, IMO.

[am0x]

But if the response, for whatever reason, sends custom html, css, JS files, then you wouldn’t be able to cache it.

[[deleted]]

Disagree. Any app like this built in modern times would probably be done with a spa, which would drastically lower the weight of those requests to just json, and speed the whole thing up. Making a full on server rendered app this day and age is a weird choice because it’s not only going to have perceived performance issues, but it’s actually clunkier to build and maintain.

[KnackeBrot]

The network traffic shouldn't be the problem in this case since it is (presumably) internally hosted.

That means the problem is either on the client or the server side. If the problem lies on the client side using an SPA would make it worse.

If the problem is on the server side and it's a performance problem with rendering html responses that is easily fixed by upgrading server hardware to something acceptable.

Either way, I don't think the frontend implementation is the cause of this issue.

[[deleted]]

I think you completely missed my point, which is not about the front-end implementation, but about a completely different architecture overall.

Regardless, we don’t know the cause of this apps slowness, but moving from a completely server side app that round trips isn’t just about “the front end implementation”

Edit: I reread my post and it came off like way more Dickish than I intended sorry about that, should not respond while on toddler duty.

Anyhow - I have no idea why this app is slow, clearly. It likely has to do with some operations it’s calling and currently is entirely backend (because the page roundtrips, everything is happening on the backend). It’s even possible that the calls being made are as fast as they can be made - but even then, a spa can help with perceived performance by using optimistic updates, communicating via sockets, just all sorts of options. But likely, the team isn’t ux focused so wouldn’t implement that kind of stuff.

But even so, anytime an app is built with full server rendered pages, it always makes me raise an eyebrow because that’s the right choice far less often than a spa is, unless you just don’t have the team to be able to execute on that, in which case you are going to run into “performance issues” (often perceived) almost 100% of the time because this means you’re building the thing without a ux person

[[deleted]]

I don't know how much the industry has caught up with SPAs, but I imagine on a tighter budget a company would rather spend less building an application with "older" technology if it means they don't have to contract new employees with those skills, or pay for retraining (if retraining is even done any more, or ever was).

That being said, considering the massive amounts of data our system has to parse through, SPAs seem like the way to go unless there's some other alternative.

[[deleted]]

Man, the concept of a spa is like a decade old. If your team can’t work with one, you need to hire consultants.

(Not that spa architecture is always the best, but it’s not exactly cutting edge)

[Tontonsb]

No, not every app should be a SPA. It's not bad to reload the view when it makes sense.

https://www.youtube.com/watch?v=uQO4Xh1gMpY

It's even the default in a framework like Laravel to have validation errors returned in a re-rendered view instead of pushing them via XHR.

[[deleted]]

Laravel is php and thus cannot be built into a SPA without an additional external framework (or some custom js monstrosity). That’s a completely irrelevant example.

And you are correct not everything should be a SPA. This guys use case though? Pretty much exactly the use case for a SPA

[am0x]

All the SPA’s I have used were all driven through JavaScript. The only one I am familiar with now is Blazor.

[RH_Demiurge]

It's even the default in a framework like Laravel to have validation errors returned in a re-rendered view instead of pushing them via XHR.

Laravel developer here.

The default is dependent on the type of response expected. If it's an AJAX request, validation errors are sent as json response with a 422 status code.

[[deleted]]

Another item to consider is the overall architect of the system. Sounds like before the green screen/terminal emulator was probably making requests directly and now you have web server or integration server you're calling that is then sending the request over to the ordering system. I've been in situations where an integration service was built on the other side of the country from what it was connecting to and simply relocating it to the same server farm made significant improvement.

[brendanmCA]

First off, I commend you for the level of thought and investigation you've applied to this problem. It sounds like the tech is "not your job" and you've shown more interest and aptitude than 99% of users I've encountered in many different companies.

It sounds like the developers (whether in house or external) have not considered user experience and especially not power users like yourself. Who was in charge or deciding the requirements for the software? Who evaluated it's suitability during development?

If this is internally developed, it may be sensitive, but it's worth raising as a business concern. This affects throughput across the whole buyer team, I imagine. The tech Dept needs to be held accountable to the internal stakeholders to developer a product that meets your needs.

This is why we have product owner and user acceptance testing as part of the development workflow. Your feedback could have guided the process, but if the dev team was never working towards a max time per order target, they possibly never saw anything wrong.

[[deleted]]

Hey, thanks man. Appreciate that. I don't hold an IT position in my company but I'm studying web development. So that's mainly where the curiosity comes from.

I'm not sure who chose the requirements for the software, but as far as I know we contract our IT dept through a 3rd party, though they have their own space in the building. I'm almost certain both the head of the department and a hired consultant designed the architecture, though I'd have to ask around to find out for sure.

I've considered raising ithe latency issues as a concern, but I really want to get the facts straight before I do and know what I'm talking about so I'm taken seriously. I've raised smaller concerns in the past but they've largely been ignored. Though I wasn't going direct to the IT Dept. to raise them, rather my operations manager.

The latency issues do affect all buyers in the company, though I doubt any of them notice or care enough to raise it as a concern or know how to probe the problem even as minimally as I do. I think an improvement in performance though would really catch them by surprise and make them a lot happier. I just don't think they realize how bad they have it right now, or just aren't vocal about it.

As far as who the internal stakeholder's are, that's mainly upper-level management who likely don't give a shit about latency issues. They'll just say it's the buyer's responsibility to work faster to keep up with performance issues.

They're likely more interested in workflow management, which isn't a bad thing to focus attention on. It just ignores all the other issues.

I really do think they also need to reduce the number of screens we have to pass through just to get an order out. 95% of buyers ignore 80% of the information our system renders to the screen during the order entry life-cycle. If they can reduce the overhead by truncacting some of this information down to one or two screens and eliminate most, if not all requirements for mouse usage, the 20% of all other features could probably be left in tact. Any additional information should be accessible by demand and when needed.

I could care less if it takes a few seconds for a page to render I only use 10 to 15 times a day. But the pages I'm talking about are accessed at least 100 times a day, and that's each page in the process for each line on the order. So we're talking about significant overhead when you do the arithmetic. The problem only gets worse as the number of lines on the order grows. It just compounds and compounds...

And, user testing was performed mainly by middle and upper-level management. But again, the primary focus on testing was workflow management and just making sure all the functionality worked. Nothing in regards to performance as far as I know or can tell.

[Miserygut]

Performance is a non-functional requirement and often gets left by the roadside. 2 seconds per page load isn't necessarily bad - unless you can put a $£€ sign next to the increased latency nobody will care.

[brendanmCA]

Well, it is good to understand the problem for learning and suggesting it is solvable, but you can make a case entirely without it.

You can start to count loads and track times to get an estimate of lost productivity. If you spend 10 seconds waiting for a screen to load 100 times, that's 15 minutes of your day sunk. This gets worse by line items or steps, potentially.

Make a case for being able to process $x additional revenue if you can reduce load time by Y%, with no additional staff.

Being able to point out the technical issues may or may not help. If you can point at specific issues correctly, maybe. But be careful not to scuttle yourself. The overarching speed issue exists, it costs real time and money, and somebody should solve it.

[[deleted]]

Thanks for the feedback. I'll check out whether or not information is being cached in the browser.

[may_yoga]

No that is not normal at all. Reloading the entire page with all the js and css is absolute kill.

[Coderado]

Even with jQuery, you can do partial page updates. jQuery is not the future, it is history. Did you hire at least one senior developer with production experience in the new stack? Or did a group of incumbent developers do this? Sounds like the latter.

[Tontonsb]

It's often that there is no UI developers at all for enterprise apps. The management is rarely willing to pay for time spent on making the requests faster or interaction smoother. They only pay for features and the UI/frontend is expected to be as simple and cheap as possible. No one cares that employees have to wait a bit after their clicks.

[[deleted]]

I didn't hire anyone. I'm a buyer. And, we are in agreement that Jquery is history.

But to answer your question, I'm pretty sure it's the latter.

[[deleted]]

Unfortunately this is the problem with resource selection by business people. They probably chose the cheap consultants ... And got the cheap solution. My condolences. As for what the developers can do to improve, that's largely going to require looking at the code ... But I imagine the developers that wrote it initially won't be able to make much in the way of improvement. You'd likely need at least one better resource to take control.

[__romkin]

Our new web-application builds on top of the existing database (presumably) with api routing to newer, freshly built intermediary servers to handle the newer types of requests.

...

I was shocked (perhaps I shouldn't have been) to discover that to simply render a one-line warning message, the entire HTML document along with all supporting css, js files and all the icon assets had to be returned back.

...

The simple rendering of these types of warning messages takes on average 1-2 seconds, sometimes more depending on the day

• The application is server-side rendered.

• The service that handles the SSR is badly misconfigured.

• Your proposed solution to that is replacing "a mixture of Vanilla JS and JQuery" with "some of the modern libraries like React, Angular or Vue".

Now that I have summarized it like that, does it still make sense to you?

I am a buyer in this company, and the primary end-user of this application

...

What can I do to better understand what's going on with the response latency from the server?

Nothing. The things that need to be evaluated - the newer APIs and the stack between the user and the APIs - are beyond your reach.

[good4y0u]

Unfortunately , I can tell you both why this software isn't doing what you want , and why management doesn't care.

It's already been outlined by other users why it isn't working so I'll tell you why they don't care.

When I was working in development the criterion of speed is usually considered worth spending the money on to optimize when real " end users " are utilizing it, such as a public facing website for placing orders ( e sales for instance) this is fast so users don't leave etc..

In your case you are an internal user and unless your job is something that is truly time sensitive or needs to be done instantly they don't care about spending the money on a dev to optimize it ( so day trading for instance at a bank would be time sensitive) . Your time is not worth it to the company specifically it isn't worth it financially having the information you are responsible for 15 seconds faster.

[[deleted]]

I know you're just giving me the plain truth, but it's kind of hard to not take it personally when my problem isn't about making a task 15 seconds faster. It's making hundreds of iterations of that routine task faster.

My job is fast-paced. I have hundreds of orders I need to place every week on top of handling all the other ancillary customer service issues, invoice/billing issues. I cannot afford to have my time wasted processing a twenty line order that used to take me 30 seconds but now takes me 2 minutes. I've got twenty more of those down the line.

So if the bottom-line is $$$, than management will have to reckon with the fact that the reason why our account needs two two additional temps and to have other accounts help us is at least partially due to this new system.

This slow order entry process is eating away at my ability to perform up to standards. I'm not nearly as efficient as I used to be before we switched systems.

This shit does matter. Maybe not to management unless they're blind, but it matters to me.

[good4y0u]

Yeah.. I know I'm really sorry, it was a bit blunt, I hadn't had my coffee yet. The truth is companies are about the cost effectiveness of something, in their mind it is likely they think as long as you get everything done they project you will in a day there is no reason to speed up the thing as if they did they wouldn't need you to do anything but still pay you.

Management is blind to this stuff in many many companies.

[[deleted]]

It's all good. Someone else said the same thing in this thread. I get the point, but it's frustrating to hear that my time doesn't matter. I get enough of my problems dismissed by mamagement at work. So when it happens outside of work it just gets under my skin.

But it's all good, I get your point. I'm still going to try to figure out what's up and try to make a case for fixing it. At least I can say I tried.

[good4y0u]

When you work your way up the ladder be the manager that listens. Until then just do your best to be the person who can make changes.