Google Chrome v60 - Lighthouse: Meteor CSS seems to load very slowly


#1

With Google Chrome 60, they shipped google Lighthouse as a standard feature instead of a plugin, so I ran a few again on my meteor app (go to your developer console > Audits to use it).

While there are a lot of issues with my app regarding performance, one comes out of it that I don’t know how to handle, and it’s CSS.

Here’s a screenshot from the latest test:

Does anyone know how to reduce stylesheet loading time, and maybe how to improve google fonts loading time?

As you can see, the google font is an order of magnitude smaller than all my meteor css combined, but takes half the time to load.


#2

I’m getting around 500ms delay, which isn’t great, not nearly as much as yours. What sort of other CSS are you loading onto your app besides Google Fonts? You’re not including ALL of Google Fonts, are you?

It also might be worth mentioning, that you’re going to get far worse results (in general) on a development app since all your resources are unbundled and loaded individually. And even in production, it largely depends on the page you’re auditing, but CSS in particular is bundled together and loaded all at once in Meteor (iirc) so it’s bound to slow things down a little bit.


#3

I ran this on the production part of my app, so there shouldn’t be too much extra stuff.

As for google fonts, I put this inside my head tag, so it should only load that single font with 2 different weights: <link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Source+Sans+Pro:300,400">.

Is your css about half the size of mine in this case ? (to make sure it scales ~linearly)


#4

Nope, mine is about 44KB, but takes less time than yours. Maybe yours is loading much slower because you’re linking to the CDN externally, instead of downloading it and bundling it locally. Every time your page loads, it has to fetch the CSS from fonts.googleapis.com. I think generally, it’s best practice to bundle your CSS locally in production, especially if you have a lot of it.

The only problem there is that it’s more work for you to keep your static assets up to date whenever you update dependencies, or Google releases an update for your fonts or icons, since you have to include them manually.

If you’re not planning on including much more CSS in your project anytime soon, I wouldn’t worry about it TBH.


#5

Right, so that would reduce the load time of the google font, but not my own CSS or did I miss something? Because all of my own CSS (the 33KB one) is in that same meteor css bundle.

I actually thought is was a good practice to serve as many assets as you can through a CDN for faster download speeds, and availability no matter how far you are from the app’s server, is that incorrect?


#6

No, that’s right, but there’s a trade-off involved. If you rely on an external CDN, you risk it going down and then your app doesn’t have the resources it needs. A big distributed CDN like Google APIs or AWS or Cloudflare shouldn’t be a problem, but you never know. However, yes, if you’re far away from the server geographically you do risk having longer load times.

Personally, I like to load my static assets locally, but that also depends on how big your app is and how distributed your user base is, globally. If you’ve got this huge user base, you’re going to be distributing some instances of your server across the world anyway, I’d imagine. Or at least distributing your JavaScript and CSS with your own CDNs like Josh Owens discusses here.

In your case, though, I think since the google CDN is essentially doubling your load time for your CSS so you might consider loading it locally. It’s a tiny 1KB thing, I don’t think you need to worry too much about what if a user is far from the server. If you’re getting 580ms now, then load time is going to be long either way in that situation.