Render-blocking JavaScript and CSS in above-the-fold content

(Michael Downey) #1

Google’s PageSpeed Insights for (and my own instance) shows several opportunities for improvement:

  • Mobile score is 62/100 for speed & 99/100 for UX.
  • Desktop is 83/100.

For both mobile and desktop, the biggest area for performance improvement is eliminating render-blocking JavaScript and CSS in above-the-fold content.

From a non-developer standpoint, does the team have any plans for improvement in these areas?

Google Webmaster Tools warns of "mobile usability issues" due to images in topics?
(Sam Saffron) #2

aka. Drop Ember.JS and completely rewrite our front end.

(Stephen Bain) #3

Yeah Page Speed Insights is great but getting 100% on it can often disadvantage your site rather than improve it. Render blocking JS sometimes has to be there or you’ll get content that doesn’t load or misaligned elements that rely on knowing the page width or height. Take it from me 100%ing Insights is a stupid thing to aim for!

(Jeff Atwood) #4

Our whole site is giant ball of JavaScript. Remember that what you see on the screen here was not loaded via a HTTP page request for HTML+CSS, it is JavaScript literally drawing everything on the screen, every time you click or tap.

The only thing retrieved from the server is the ball of JS that makes up Discourse, then the JS will make JSON API calls to get what it needs to paint the screen. Everything is painted on the screen via JavaScript, at no point do we say “retrieve this HTML file and display it”. That concept does not exist in Discourse.

We are looking at breaking off parts not needed for anon users, e.g. stop serving the editor to anon users.

(Kevin P. Fleming) #5

Also, what does ‘above-the-fold’ mean? My screen does not fold.

(Dean Taylor) #6

(Kevin P. Fleming) #7

Correct. The paragraph you quoted clearly indicates that while saying ‘above the fold’ may be common, it has no value whatsoever.

(Jeff Atwood) #8

It does if you push harder!

(Michael Downey) #9

Nonsense. Render the stuff the user can see first, as quickly as possible. The stuff outside of the viewport can wait and be slower.

(Michael Downey) #10

Agreed, but does that mean you should ignore areas for improvement? :smile:

This is a great approach. I also would find it hard to believe that there is no JS that doesn’t need to be blocking the rendering of the page, but is. This discussion was just meant to brainstorm or describe possible areas where speed could be improved.