Speeding Up a Fat Web Client | Hacker News Reader

Speeding Up a Fat Web Client

engineering.linkedin.com

89 pointsjoubert28 comments

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.

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

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?

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.

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.

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.

Yes, I'm on a fast network and using a newish Android device. It's mostly the rendering performance. All I want is to get to the mailbox quickly. I've never wanted to use the timeline and notifications features and whatever else they're loading.

Even on a desktop I get a loading screen for maybe 2 seconds and the site loads in ~4 seconds.

A modern website that works well on all devices quickly is soundcloud. Seamless browsing/listening and excellent user experience.

Something I have noted from working with Jira and Magento 2 is that if your servers are on another continent, the network delay in getting the dozens of little snippets of JS and ajax API requests adds considerable delay.

Jira is especially cumbersome as when you update one thing it refreshes half a dozen other items and you have to wait for the whole lot before it becomes interactable again. In those cases, I would prefer it either to update on the component I touched or to not pretend to be reactive and just be a flat out form POST.

As it stands it is the worst of both worlds and the network delay compounds to make it a slow, page jittering mess the whole time I am using it.

Two things I know about LinkedIn: 1. Lots of former Yahoo people work there, and 2: If Facebook has it, LinkedIn needs it.

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.

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.

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

Video: https://vimeo.com/147806338

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

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.

They reduced the CSS by 2MB (uncompressed), that says little about how many MB remained.

I see two files totaling about 1.5 MB when uncompressed.

It won't, sites will just swell up to 10MB of CSS.

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.

"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.

Yes, lots of things also use "virtual scrolling"

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

2. https://alarisprime.com

What they're doing isn't even occlusion culling. It's frustum culling.

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.

iOS (And probably Android nowadays as well) list views is another example where it's been used for a long time.

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

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.

No shittier than before, got it. Heck of a philosophy, but hey, they're public.

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.

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

Reply on news.ycombinator.com