Optimizing our website at the millisecond level(blog.algolia.com)
blog.algolia.com
Optimizing our website at the millisecond level
https://blog.algolia.com/improving-web-performance-to-mirror-engine-speed/
18 comments
Indeed, actually right now our trackers represent quite a big chunk of the website size, but we made sure that they are all async loaded so they don't impact the site that much. It's something that we are aware of and pushed a bit for internally but since we are still evaluating tools and learning, we decided to keep them for now. I'm sure that once we have the right one, we'll decrease that part quite a bit :)
I've gone down this same optimization route for some of my sites and disabling trackers was one of the biggest contributors. If you have to have trackers consider loading them only on a small percentage of your users to get you a statistically relevant sample. This will at least give the bulk of your users a vastly better experience. You'll need to scale the percentage of users you do put the trackers on with your traffic.
That's an interesting idea. Seems like it would be hard to get a representative sample though if the trackers themselves affect the user experience.
My team just completed a similar performance optimization for a massive ecommerce site. The 3rd party javascript libraries are a huge penalty in performance. The second you get those out of the way and loading async or after page loads, you can start breathing again.
Most 3rd party tools should seriously start evaluating how they offer JS inclusions into web pages.
Most 3rd party tools should seriously start evaluating how they offer JS inclusions into web pages.
Great to see them mentioning https://www.webpagetest.org/ one of my favorite tools for optimizing frontend performance.
Surprised they didn't mention https://gtmetrix.com.
The problem I have with lighthouse is that it emphasizes total page load, instead of first paint.
The problem I have with lighthouse is that it emphasizes total page load, instead of first paint.
> The problem I have with lighthouse is that it emphasizes total page load, instead of first paint.
Not sure what you mean about lighthouse? First Meaningful Paint is featured prominently in the performance scoring.
Not sure what you mean about lighthouse? First Meaningful Paint is featured prominently in the performance scoring.
You're right, a couple months ago it didn't have that
Nice post, but one has to wonder if it is self defeating. In the end "speed" is just a matter of expectation management. Suppose you had a website that could complete all actions instantaneously. At this point I imagine speed would simply be redefined as the amount of time it takes you to find the desired action.
Surely there's a point where it's easier to just create a culture of patience than to pursue diminishing returns of shaving off nanoseconds.
TLDR: Is the better experience carefully crafted expectation management or simply being faster?
Surely there's a point where it's easier to just create a culture of patience than to pursue diminishing returns of shaving off nanoseconds.
TLDR: Is the better experience carefully crafted expectation management or simply being faster?
In terms of workflow, faster is always better than patient. Above one second it feels like waiting on the computer, impeding workflow. Below ~200 milliseconds it feels instant.
In most applications, going from 200 milliseconds to 100 milliseconds doesn't accomplish anything, but going from 1 second to 500 milliseconds allows for a better workflow and more exploration (waiting is a huge discouragement to exploration)
In most applications, going from 200 milliseconds to 100 milliseconds doesn't accomplish anything, but going from 1 second to 500 milliseconds allows for a better workflow and more exploration (waiting is a huge discouragement to exploration)
I'd argue that "exploration" is a failure to identify intent for most applications. This is probably the hardest UI/UX problem.
Would you rather select a series of instantaneous actions select the "Do" button and within 5 seconds it will complete whatever you want, magically?
It obviously depends on how long it takes you to select the actions, but I think it's an interesting thought experiment.
Would you rather select a series of instantaneous actions select the "Do" button and within 5 seconds it will complete whatever you want, magically?
It obviously depends on how long it takes you to select the actions, but I think it's an interesting thought experiment.
I would agree that most exploration is a failure to identify intent. But in may cases, even the user would be unable to express his intent. Trying out various actions/settings and seeing the result is a powerful tool to let the user realize what he even wants.
In e-commerce settings speed more or less directly translates into dollars. So a better experience definitely is something to strive for and not just a matter of 'expectation management'.
Speed doesn't translate into dollars for the vast majority of use cases. Would you really suggest to an e-commerce startup to focus on speed and not building a great experience? Obviously you need to be fast enough, but there are diminishing returns.
I fail to see how "a better experience" is not directly related to "expectation management." A certain experience is obviously something someone would expect, and therefore be managed.
I fail to see how "a better experience" is not directly related to "expectation management." A certain experience is obviously something someone would expect, and therefore be managed.
Go for the good experience first, define a good UI and make the site good to use. Once it's good to use, make it fast so that using it doesn't feel slow and users can get to what they want faster :)
I would say it depends on the current experience. For instance, if you have a slow site, make it faster but don't go into nanoseconds. If it's still slow afterwards, try faking speed (queue actions, improve render chain, caching etc). There were some studies that actually showed that loading just some resources and giving the user the "it's loading" message would actually have them question their connection/phone and not blame the slow experience on the website. Not good, but still better than having them blame it on you because then you lost them. However if the UX is still not good enough, you can go into milliseconds and really make it fast. That said, I'm positive that with the evolution of tools and languages + add some good affordable providers that offer fast CDN and easily configurable HTTP/2 features (Netlify for instance) most of the hard work will be taken away fromthe developers and making your site fast should not be something we'll have to focus on in the future because that's just the way they'll be made :)
It's a bit funny at how they go to such lengths to cut down their page load, only to have it doubled with third-party analytics. Regardless, a great blog post on best optimization practices.