Thread by @traskjd

Let's have a quick (long?) chat about web performance.

I have the unique situation of seeing data from billions of performance profiles as we help customers with @raygunio's Real User Monitoring look to improve user experience. #webdev #PerformanceMatters #webperf

1. Many folks still think a synthetic test is a Good Thing. That is, pinging a website from a fixed set of servers. It's better than naught, but it's a pretty poor proxy for real customer experience.

You're measuring data center to data center performance (even if nerfing perf)

2. Even with nerfing perf, you're talking high quality interconnects between DCs. This compares poorly, to say, what an actual user experiences on a 3G phone while roaming around somewhere.

You're not getting realistic numbers.

3. Your only real way to understand performance is to track what the end users load time actually is (hence the 'Real User' in 'Real User Monitoring').

I'm surprised how many folks don't use a product like this, or confuse it with web analytics.

4. Software developers tend to still think performance is something that happens on the server.

It ain't 1999, the web has changed. Nearly always, it's not the server these days - it's the front end.

Those web frameworks you love so much are shifting the problem to the user.

5. You know what's terrible about that? You don't see the problem. So you assume it doesn't exist, while users get really annoyed at your poor performing site.

6. "But JD, I use our site, I see the perf!" Sorry, very unlikely you do - you're a software developer who likely has a top 1% computer, likely on a higher grade internet connection, etc. You are not representative of your user base.

Use actual data, not your experience.

7. Here's an example which is actually pretty good compared to what I normally see. Notice that the largest time for this page is in the web-render. It's not the server time.

Just like JS Crash Reporting, if you're not tracking this, you likely don't have a clue how bad it is.

8. So what's the core cause? All these heavy JS frameworks, bundling everything, too much JS. As cool as you think new-JS framework is, I doubt you're evaluating based on impact on the customer.

Too many devs care about new-shiny and not business/user value.

9. Seriously, we're collectively HORRIBLE at things that actually help the end user. Making you enjoy JS isn't the key value prop you should be looking for, it's customer impact and a great experience with your app.

10. What's the answer many developers have to a poor load time (when that weight finally gets noticed by the C-Suite and they complain)? "Let's put in a loading spinner/page."

That's an admission of total failure. Nobody. NOBODY, wants that. Ever.

11. "But my app is really special and complicated and hardcore!", no, you're just sending the message that your end-user is one of your lowest priorities. That's a pretty terrible attitude. One we're trying to change with @raygunio's products - deep dive crashes, performance etc.

12. Another common request we get is 'how do I exclude this page/state/event from our load time?'.

Unless your user can avoid that, you're literally asking us to add features to lie to you about your customer experience, which is why we have never added such features.

13. So, if today you don't know what your median load time (if you know the average, again - you're living a lie, averages are lies), what your outliers are (e.g. 1% slowest load times) -- what's the reason?

14. If the answer is anything about budget/nobody cares, I can almost promise you that high enough in the org structure - they do.

They don't want to be providing something that ruins the reputation, frustrates customers, drives up marketing costs due to low conversions

15. One of the best things to happen in recent years has been Google penalizing websites that are slow. So they should, it's a terrible customer experience and you don't deserve the users time for treating them badly.

This has an interesting dynamic change.

16. Suddenly, the marketing team (who many developers look down on - wrongly), is the one needing to point out the poor quality of what the dev team is producing.

And they have to, because it's hurting the rankings, users, and ultimately the business.

17. I could go on for days here, but it just shocks me every day the attitude of many (not all) software developers, and that we're so comfortable pushing all the problems on to the poor long-suffering end user.

User empathy is important in business success.

18. Lastly, If this resonates & are a software developer:

- We are hiring devs for our Wellington office: raygun-engineering.workable.com/jobs/252302
- Understand your performance with Real User Monitoring (free 14 day trial, takes minutes): raygun.com/platform/real-…

Let's make software better.