10 ms·

Speeding Up a Fat Web Client

89 points by joubert 9y ago

tyingq 9y ago
"Occlusion culling is a technique that came out of the video gaming industry where you render what is actually visible at a given time." I don't have any proof handy, but I imagine this was leveraged in areas outside of gaming. Spreadsheets seem likely to have used this, for example.
- spo81rty 9y ago
  Yes, lots of things also use "virtual scrolling"
- Brajeshwar 9y ago
  For one of our client, Adya[1], our team at Alaris Prime[2] implemented the very same idea for the web. It is a file manager that displays a huge list of folders/files from multiple clouds (file storage) providers. We needed a fast-loading, smooth UX and way to do it was to move things around as little as possible - only the visible viewport of the user's browser. We should be writing a case study on it but never got around to doing it. 1. https://www.adya.io https://www.adya.io 2. https://alarisprime.com https://alarisprime.com
- curmudgeon9 9y ago
  What they're doing isn't even occlusion culling. It's frustum culling. https://docs.unity3d.com/Manual/OcclusionCulling.html https://docs.unity3d.com/Manual/OcclusionCulling.html edit: I wouldn't even call it frustum calling since I don't think frustum culling makes much sense in a retained mode API (the frustum culling happens when rendering the retained mode representation through the underlying immediate mode API). 'Level of detail' maybe.
- TrickyRick 9y ago
  iOS (And probably Android nowadays as well) list views is another example where it's been used for a long time.
weeksie 9y ago
Yeah, cut down 2mb of CSS files and you're gonna get a speed up :| I know, I know. LinkedIn is big and has a big team and this level of rigid formalism is what's required to manage a large team of developers and keep them from committing non-performant code. The joys of big teams. I really applaud them for being able to pull it off. The site is far, far more performant than it used to be. For the most part though, for most of the rest of the world of web applications: just stop including so many fucking libraries in your js and don't do write-once ultra-scoped CSS.
ec109685 9y ago
Surprisingly, this web site doesn’t need occlusion culling to be fast.
tzahola 9y ago
2 mbytes of CSS? Wtf. I’m genuinely looking forward to the day when Moore’s law finally fails, and puts an end to this madness.
- robocat 9y ago
  They reduced the CSS by 2MB (uncompressed), that says little about how many MB remained.
  - aptwebapps 9y ago
    I see two files totaling about 1.5 MB when uncompressed.
- amiga-workbench 9y ago
  It won't, sites will just swell up to 10MB of CSS.
- jlebrech 9y ago
  you could reduce the complexity of the selectors by converting everything to id selectors, that would also end up bloating the css, but offsetting cpu usage to memory usage.
latchkey 9y ago
This blog post really shows how overly complex their system is. I'm constantly bumping into state management rendering issues on the 'new' LinkedIn. For example, when you add a new connection, you can't immediately send them a message until you reload the page. Pretty much the number one workflow you'd expect someone using the site to do. "Before releasing it to the public, we knew it had to be at least as fast as our existing site." Which wasn't saying much because the original site didn't load well at all. At least it didn't have all the state management issues. It is like they take all these newfangled technologies and then struggle to implement them correctly. So sad.
- rhizome 9y ago
  No shittier than before, got it. Heck of a philosophy, but hey, they're public.
- andreime 9y ago
  Any rewrite or big change is a gamble. By setting this metric they avoid performance degradation. I'm admitting that I'm just assuming this, but the changes are probably a start for easier future optimization. Setting two big targets: make it a lot faster and make it a lot better, seems to me like a mistake.
pbreit 9y ago
This reads like The Onion. I can’t think that anyone would think LinkedIn’s website has improved. According to the article the goals were merely to maintain performance. It’s a pure content site that benefits little if it all from single-page.
- lqdc13 9y ago
  The site still takes ~20 seconds to load on mobile Firefox. I don't know of another popular site that takes as long to load
  - dmarlow 9y ago
    Loads quickly for me. I keep hearing that LinkedIn loads slowly but people fail to mention specifics about their devices and internet speeds. Are you on home wifi, LTE or something else?
    - nzjrs 9y ago
      Thats kind of the problem right? Take a distribution of your potential user base connection speeds. Modern web app / SPA engineering seems to be to draw a line somewhere on that distribution and FU to the rest.
      - flukus 9y ago
        I think the line is drawn at how quickly you can transfer from localhost. It seems like devs tend to ignore network latency entirely because it's something outside of our control. It seems to be getting worse too, things like the windows start menu can freeze when you're on a intermittent connection, SPA's can break entirely. I've spent a good chunk of my career fixing n+1 problems over a network, even when it's on a fast connection to a local database the latency becomes noticeable are fairly small values of n.
        ShabbosGoy 9y ago
        I'm not a huge fan of SPAs. The trend of designing web applications as if they are mobile apps is quite silly. Polymer in particular is notoriously slow when using polyfill.
hoodoof 9y ago
Weird. It looks like just a website but apparently it's a fusion reactor underneath.
diafygi 9y ago
I work in energy, and there's a phrase: "The cheapest kilowatt-hours are the ones you don't use." Anyway, for those who haven't read/listened to it, Maciej Cegłowski has a wonderful talk on the subject. Talk: http://idlewords.com/talks/website_obesity.htm http://idlewords.com/talks/website_obesity.htm Video: https://vimeo.com/147806338 https://vimeo.com/147806338
wmtthrowaway 9y ago
This makes me sad for 2 reasons. Reason #1: They did a horrible job, this post reads like a list of things not to do. Reason #2: They still did a much better job than my company. We had a similar rewrite from a reasonably well performing system to a dog slow monstrosity. However instead of acknowledging it was slow, we put on our doublethink hats and deployed anyways. "We" picked a couple metrics that were easier to game (time to first byte) and then we threw up our mission accomplished flag and moved on. We also wrote posts like this bragging about the performance improvements we'd made. I hate the sort of "techcrunch driven development" that's so big in wanna-be facebook companies. Instead of solving business and customer needs, directors and vps are mostly focused on splashy articles and speaking engagements that make their resume look good.
wedgeantilles 9y ago
What a waste of time, effort and money. Seems like they are just ever so slightly better off than they were two years ago.

89 points by joubert 9y ago

"Occlusion culling is a technique that came out of the video gaming industry where you render what is actually visible at a given time." I don't have any proof handy, but I imagine this was leveraged in areas outside of gaming. Spreadsheets seem likely to have used this, for example.

spo81rty 9y ago
Yes, lots of things also use "virtual scrolling"
Brajeshwar 9y ago
For one of our client, Adya[1], our team at Alaris Prime[2] implemented the very same idea for the web. It is a file manager that displays a huge list of folders/files from multiple clouds (file storage) providers. We needed a fast-loading, smooth UX and way to do it was to move things around as little as possible - only the visible viewport of the user's browser. We should be writing a case study on it but never got around to doing it. 1. https://www.adya.io https://www.adya.io 2. https://alarisprime.com https://alarisprime.com
curmudgeon9 9y ago
What they're doing isn't even occlusion culling. It's frustum culling. https://docs.unity3d.com/Manual/OcclusionCulling.html https://docs.unity3d.com/Manual/OcclusionCulling.html edit: I wouldn't even call it frustum calling since I don't think frustum culling makes much sense in a retained mode API (the frustum culling happens when rendering the retained mode representation through the underlying immediate mode API). 'Level of detail' maybe.
TrickyRick 9y ago
iOS (And probably Android nowadays as well) list views is another example where it's been used for a long time.

weeksie 9y ago

Yeah, cut down 2mb of CSS files and you're gonna get a speed up :| I know, I know. LinkedIn is big and has a big team and this level of rigid formalism is what's required to manage a large team of developers and keep them from committing non-performant code. The joys of big teams. I really applaud them for being able to pull it off. The site is far, far more performant than it used to be. For the most part though, for most of the rest of the world of web applications: just stop including so many fucking libraries in your js and don't do write-once ultra-scoped CSS.

ec109685 9y ago

Surprisingly, this web site doesn’t need occlusion culling to be fast.

tzahola 9y ago

2 mbytes of CSS? Wtf. I’m genuinely looking forward to the day when Moore’s law finally fails, and puts an end to this madness.

robocat 9y ago
They reduced the CSS by 2MB (uncompressed), that says little about how many MB remained.
- aptwebapps 9y ago
  I see two files totaling about 1.5 MB when uncompressed.
amiga-workbench 9y ago
It won't, sites will just swell up to 10MB of CSS.
jlebrech 9y ago
you could reduce the complexity of the selectors by converting everything to id selectors, that would also end up bloating the css, but offsetting cpu usage to memory usage.

latchkey 9y ago

This blog post really shows how overly complex their system is. I'm constantly bumping into state management rendering issues on the 'new' LinkedIn. For example, when you add a new connection, you can't immediately send them a message until you reload the page. Pretty much the number one workflow you'd expect someone using the site to do. "Before releasing it to the public, we knew it had to be at least as fast as our existing site." Which wasn't saying much because the original site didn't load well at all. At least it didn't have all the state management issues. It is like they take all these newfangled technologies and then struggle to implement them correctly. So sad.

rhizome 9y ago
No shittier than before, got it. Heck of a philosophy, but hey, they're public.
andreime 9y ago
Any rewrite or big change is a gamble. By setting this metric they avoid performance degradation. I'm admitting that I'm just assuming this, but the changes are probably a start for easier future optimization. Setting two big targets: make it a lot faster and make it a lot better, seems to me like a mistake.

pbreit 9y ago

This reads like The Onion. I can’t think that anyone would think LinkedIn’s website has improved. According to the article the goals were merely to maintain performance. It’s a pure content site that benefits little if it all from single-page.

lqdc13 9y ago
The site still takes ~20 seconds to load on mobile Firefox. I don't know of another popular site that takes as long to load
- dmarlow 9y ago
  Loads quickly for me. I keep hearing that LinkedIn loads slowly but people fail to mention specifics about their devices and internet speeds. Are you on home wifi, LTE or something else?
  - nzjrs 9y ago
    Thats kind of the problem right? Take a distribution of your potential user base connection speeds. Modern web app / SPA engineering seems to be to draw a line somewhere on that distribution and FU to the rest.
    - flukus 9y ago
      I think the line is drawn at how quickly you can transfer from localhost. It seems like devs tend to ignore network latency entirely because it's something outside of our control. It seems to be getting worse too, things like the windows start menu can freeze when you're on a intermittent connection, SPA's can break entirely. I've spent a good chunk of my career fixing n+1 problems over a network, even when it's on a fast connection to a local database the latency becomes noticeable are fairly small values of n.
      - ShabbosGoy 9y ago
        I'm not a huge fan of SPAs. The trend of designing web applications as if they are mobile apps is quite silly. Polymer in particular is notoriously slow when using polyfill.

hoodoof 9y ago

Weird. It looks like just a website but apparently it's a fusion reactor underneath.

diafygi 9y ago

I work in energy, and there's a phrase: "The cheapest kilowatt-hours are the ones you don't use." Anyway, for those who haven't read/listened to it, Maciej Cegłowski has a wonderful talk on the subject. Talk: http://idlewords.com/talks/website_obesity.htm http://idlewords.com/talks/website_obesity.htm Video: https://vimeo.com/147806338 https://vimeo.com/147806338

wmtthrowaway 9y ago

This makes me sad for 2 reasons. Reason #1: They did a horrible job, this post reads like a list of things not to do. Reason #2: They still did a much better job than my company. We had a similar rewrite from a reasonably well performing system to a dog slow monstrosity. However instead of acknowledging it was slow, we put on our doublethink hats and deployed anyways. "We" picked a couple metrics that were easier to game (time to first byte) and then we threw up our mission accomplished flag and moved on. We also wrote posts like this bragging about the performance improvements we'd made. I hate the sort of "techcrunch driven development" that's so big in wanna-be facebook companies. Instead of solving business and customer needs, directors and vps are mostly focused on splashy articles and speaking engagements that make their resume look good.

wedgeantilles 9y ago

What a waste of time, effort and money. Seems like they are just ever so slightly better off than they were two years ago.