I have a friend, a colleague. Let’s call him Joe.

Joe wants the best for his customers and his organization. He knows customer experience is critical and he recognized his organization hasn’t been the best at it. People come to their site because they have to get something done. And customers loathe having to but must as part of running their own business. So they’ve put up with the occasional outage, slow page response time, or error message after submitting a form.

And the experience has gotten better over time. There’s more information on entry pages. More and better images. More context. Internal stakeholders are happier because key usage metrics like page views per visit, repeat visit, and mobile visits are all increasing.

But there’s a problem that’s not easy to see. Joe has all the tools to measure it but doesn’t have someone digging deeper into the analytics to identify it.

The never ending web page download

The problem is that the page is full of asynchronous web calls for more data and objects and for sending signals to web services. As a frequent user of Joe’s website, I can see it in my browser as it tries to hit the next endpoint. I can see it on my task manager as chrome churns >50% CPU trying to manage all these connections. If you watched me, you could see it in my frustration as I have to wait for all these interactions to stabilized.

I often give up. The mobile site works better and doesn’t have all this nonsense. I can quickly scan this page for the one, sometimes two things I seek and obtain them quicker and easier than the web experience.

Now sometimes a mobile experience is what I need or want. But other times, I’m looking for more information and to do more things, and a web or tablet experience is better for these purposes.

Browser Side Scripting on Steroids

Putting too many objects on the page – whether it be images, javascript tags, or ads – has been a problem since web 1.0.

But today. there are more websites implementing browser side scripting. Some of this is done to provide a rich experience and other times it’s a tool to personalize the website. There are different good reason to be using browser side scripting for these and other reasons.

When browser side scripting is the standard, and server side the exception then bad things can happen. These sites end up with too much code and too many server side calls. It’s hard to see this until the page is fully constructed and even then, the impact to end users may not be fully recognized by the development team.

It’s becoming a problem for teams that don’t debate the application architecture up front. When is it appropriate to put code browser side? How many interactive objects on a page is reasonable? How often should they pull for new data? How do you know when a page is performing poorly?

The web was originally designed as a thin client experience. Maybe we need to go back to that model?

By the way, if you think you are Joe, you are probably mistaken. There are lots of Joes and I don’t know them, but I know their websites.