5 ms·

Optimizing our website at the millisecond level

111 points by vvoyer 9y ago

prophesi 9y ago
I'd add one more section to this blog post: Disable Trackers. 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.
- Jonas_ba 9y ago
  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 :)
  - jacquesm 9y ago
    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.
    - boreas 9y ago
      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.
  - ronpeled 9y ago
    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.
tabeth 9y ago
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?
- Jonas_ba 9y ago
  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 :)
- wongarsu 9y ago
  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)
  - tabeth 9y ago
    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.
tschellenbach 9y ago
Great to see them mentioning https://www.webpagetest.org/ https://www.webpagetest.org/ one of my favorite tools for optimizing frontend performance.
- xcasperx 9y ago
  Surprised they didn't mention https://gtmetrix.com https://gtmetrix.com. The problem I have with lighthouse is that it emphasizes total page load, instead of first paint.
  - magicalist 9y ago
    > 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.
    - xcasperx 9y ago
      You're right, a couple months ago it didn't have that

111 points by vvoyer 9y ago

I'd add one more section to this blog post: Disable Trackers. 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.

Jonas_ba 9y ago
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 :)
- jacquesm 9y ago
  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.
  - boreas 9y ago
    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.
- ronpeled 9y ago
  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.

tabeth 9y ago

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?

Jonas_ba 9y ago
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 :)
wongarsu 9y ago
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)
- tabeth 9y ago
  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.

tschellenbach 9y ago

Great to see them mentioning https://www.webpagetest.org/ https://www.webpagetest.org/ one of my favorite tools for optimizing frontend performance.

xcasperx 9y ago
Surprised they didn't mention https://gtmetrix.com https://gtmetrix.com. The problem I have with lighthouse is that it emphasizes total page load, instead of first paint.
- magicalist 9y ago
  > 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.
  - xcasperx 9y ago
    You're right, a couple months ago it didn't have that