[DarwinMailApp]

I can certainly attest to this.

Every second support email in the early days of https://www.darwinmail.app was from users who were wondering why the website wasn't faster to load and operate.

I knew that this was going to slowly kill the product if I didn't focus on optimising the speed immediately. I also heard somewhere that even a 0.01 increase in load times for Amazon's website would cost them somewhere in the region of 100's of millions.

1. I gathered feedback from all users that said the website was slow (in any way and in any page/component/workflow).

2. I created a Trello board https://trello.com/c/PPuhLtW0/95-upgrade-performance for all the feedback.

3. Since that week of initial performance enhancement research and groundwork, I have essentially been completing todo's on that Trello card and adding more tasks as time goes on. I think the more speed improvements I make, the more I learn about what other parts of the application can be sped up. It's like economics, the more you learn, the more you realise you have so much more to learn :D

A few years later and I have not received an email suggesting to increase the speed of the app in several months, although I continue to make speed improvements on a regular basis.

Netflix have been my source of inspiration here. They are leagues ahead of every other streaming service and their custom architecture placed at the ISP level is absolutely incredible and paramount to how the deliver content with such amazing speeds.

[pronoiac]

Hey, you could copy your description from Product Hunt - "Enhance Gmail to get your Google Inbox features back" - and put it on your front page and/or your About page.

[mattmanser]

You never heard of a profiler? Logging? You're going about this all wrong.

When fixing performance problems you shouldn't guess, just profile it to find the bottlenecks.

I've seen plenty of performance 'fixes' that weren't, pure guesses by developers that did nothing, when a quick profile immediately revealed the culprit.

In your case you also need to figure out if it's happening server-side or client-side. I generally start with the server-side logs, get a few days/weeks worth of data, find average page request times, plus how much deviation on those requests, then go from there. That gets you the server-side. For client-side, unfortunately it's a lot harder. Google analytics page load speed, for example, is a pile of crap. But, again, there's a profiler in dev tools, remember js compile time is a significant thing and can slow load time too so check that out as well as the actual run times (js compile time shows in the page load graph).

[toss1]

Good points about using good tools & analysis techniques - especially to get to latent sources of slowness.

But I'm not sure you can say that he's not profiling - he's using the end users' direct experience as the profiling tool, prioritizing the fixes by greatest annoyance.

Since he let himself get in the mode of being reactive, that's not a bad way out of the hole he dug himself.

Of course the best way is to design your architecture for speed, minimize all code usage & data transfer, use the profiling tools before release candidate status, and prioritizing speed & performance in the QA process.

[DarwinMailApp]

More profiling is on the Trello board list ;)

I've done heaps of profiling.. pun intended :D

[flavius29663]

profiling is not a replacement for user feedback. You could profile some server side functions and see that X is 5 ms and Y is 8 ms. You will think all good, they're pretty fast. But the user might complain about a feature being slow, say deleting a thread, which happens to call the 5 ms function 50 times for some reason. You would then address the reason for so many calls, rather than optimizing the call itself.

Talking to your users is paramount, at the very least they will indicate where you have to add profiling