search

mitodl / open-discussions

BSD 3-Clause "New" or "Revised" License
10 stars 2 forks source link

PageSpeed Optimization Suggestions #616

Open pdpinch opened 6 years ago

pdpinch commented 6 years ago

See https://developers.google.com/speed/pagespeed/insights/?utm_source=analytics&tab=desktop&url=https%3A%2F%2Fdiscussions.odl.mit.edu%2F

pdpinch commented 6 years ago

as of 4/20, our score for desktop has increased to an 84 (Good) and the score for mobile has increased to a 62 (Medium)

gsidebo commented 6 years ago

Eliminate render-blocking JavaScript and CSS in above-the-fold content

The "above-the-fold" recommendations are centered around showing the user some initial UI while other assets (namely our javascript) are loaded post-page-load. I don't think there is a way for us to do this with OD that wouldn't involve a pretty hefty overhaul of the front end for a benefit that may not end up being very significant. Basically everything we show the user in OD is dynamic, and the UI is react-driven (like all of our other web apps). In order to render the UI, we need react and all of our components, which means we need the javascript bundle.

There may be ways we can sensibly break up the JS bundle so that it can load smaller files in parallel, but @aliceriot pointed to some more beneficial and obvious ways that we can improve the speed of static asset loading before we get into that. Breaking up the JS bundle would involve some work and might not give us a significant performance boost.

alicewriteswrongs commented 6 years ago

Yeah, I don't think we'd see a significant benefit from breaking up the JavaScript bundle from the investment that it would take (which is fairly significant). We could implement server-side rendering to get rid of the render-blocking JavaScript warning but that would also represent a (very) significant engineering time investment, and I'm not convinced we would see a meaningful performance increase in most cases. given that we're now around ~400kb

I just looked at the pagespeed recommendations again, and I don't think we should worry too much about them right now. There is a 'browser caching' warning for the newrelic JS file and the google analytics file, and an 'optimize CSS delivery' warning for our CSS bundle. Since we are fairly locked-in to sticking with render-blocking JS it wouldn't really make much sense to do something like inline the CSS to get around that (in my view) since we wouldn't have any real UI to show at that point anyhow. Our CSS is also bundled together by Webpack, so it would be hard to pull out a minimal part of it which we could inline to style things right off the bat for a faster first paint.

We should figure out a way to serve the static images from cloudfront at some point - I am concerned that we will have trouble updating them, though, since cloudfront works on the basis of filenames. If we edit, say, the mit-logo-transparent3.svg file but the filename stays the same cloudfront won't pick up on the difference (as far as I understand it to work anyway). So we would either want to probably adopt a practice of changing filenames when we edit the static images or of somehow inserting a value into the filepath for them (maybe the current commit hash at HEAD or something, idk).