Page Ranking and Meteor Apps


Our mobile score ranks 60 out of 100, which is pretty low. Seems like I need to add defer to the script tags. Has anybody done this with meteor success in Meteor? What are other people’s page ranking scores?

Your page has 1 blocking script resources and 3 blocking CSS resources. This causes a delay in rendering your page.
None of the above-the-fold content on your page could be rendered without waiting for the following resources to load. Try to defer or asynchronously load blocking resources, or inline the critical portions of those resources directly in the HTML.
Remove render-blocking JavaScript:
Optimize CSS Delivery of the following:


54/100 - but I don’t really know if Google did that test for “web applications” like Meteor. Just thinking about that Meteor needs to send the whole app to the users during the initial load. That’s not the most performant way. Normally we would load any script when it is needed, so I think it could be difficult to reach the 100 without using webpack or the future Meteor releases.


this is good to know, and something MDG should also take a look at for 1.3 release. Unfortunately, Google dings sites that don’t rank high, and since the world is going mobile… it’s something to take in consideration.


It is easily possible for a Meteor web app to get 100/100 on Google PageSpeed Insights and a lot of other awesome perks if you implement a minor hack to the core package boilerplate-generator.

You can achieve:

  1. Very fast time-to-first-render on empty cache, like 500ms
  2. No “flash of styled content”
  3. Score 100/100 on Google PageSpeed Insights
  4. Use of any webfont without killing your PageSpeed score
  5. Full SEO control including page title and meta
  6. Perfect integration with Google Analytics and Facebook Pixels that accurately records every page view regardless of server- or client-side rendering
  7. Google search bot and other crawlers see all of your pages’ real HTML immediately without running scripts
  8. Seamlessly handles #hash URLs to scroll to parts of a page
  9. Use a small number (like < 30) of icon font characters without adding requests or hurting speed score
  10. Scale up to any size of Javascript without impacting landing page experience
  11. All the regular awesomeness of a full Meteor web-app

See this Stack Overflow question and answer:

An example page:


Awesome. Thanks for documenting. Were you able to use to avoid the hack like you mentioned in your SO answer?


No. As far as I can tell, the inject-initial module only allows you to add code. It would be very cumbersome to modify the existing HTML in the response. I’m thinking of writing a module that uses the same technique as inject-initial (intercepting the response object) but re-writes the script tags. Not a priority right now but would be happy to work on it if there more interest and help…


any info on progress?


Yep, lots of progress. I’ve made two meteor packages that accomplish the following without hacking core:

  1. All JavaScript loads async in production mode
    Except Meteor config stuff which would make things very wonky on the unlikely chance it arrives after the big mothership.
  2. Inlines one user script file into the initial html payload
    This is where you can put critical script–like attaching a click event to your hamburger to open the sidebar menu–that you want live immediately on first render, before the big script arrives a few seconds later. The package also inlines it’s own tiny script before yours that supplies some basic utility functions (like add/remove/toggleClass and hasClass and safe event binding wrapper that will automatically play nice with React when the big script arrives) written in pure vanilla JavaScript so it’s easier to get things done without jQuery.
  3. Removes all unused CSS selectors, rules, and media queries from all your aggregated CSS based on a user-supplied list of unused selectors and inlines this lean CSS into the initial html payload
    This dramatically shrinks your CSS if you’re using a framework like Semantic or Bootstrap and styles the page perfectly on first render without waiting for massive CSS file–which is still coming in case your unused list isn’t perfect. You can copy-paste a list of unused selectors from a tool like Chrome Dev Tools Audits --> Unused CSS Selectors.

It’s working well in my development site, haven’t gone live yet. If anyone is interested in these packages I could put them up on Atmosphere but they are far from polished. As it is now, it assumes your are doing SSR with React (ie. requires react, react-router, react-router-ssr, react-helmet).

edit: Also handles icons fonts so you can use a custom iconic font service like (free) to build a font with only the icons you use and embed that directly in the CSS in the initial html so all your icons are there for first render without downloading an external font file.


I’ve followed your way so everything is setup with packages you mentioned. Please add to atmosphere.


Thanks for all the information. I know it’s like 2 years later but would still love to to see the packages and understand the best way to solve this in Meteor 1.6+ @noland


@krishaamer There’s been a couple of developments that help this a lot:

1. Server Side Rendering

By providing pre-rendered html to the client it can render immediately before the templating engine mounts and takes over

2. Dynamic Imports:

By splitting your app into various parts or delaying the loading of heavy JS libraries, you can significantly shrink the initial bundle size

3. Generally better tree shaking

By taking advantage of ES Modules, Meteor will automatically tree-shake your bundle and only include the files that you explicitly import. This mostly affects large npm modules like core-js and meteor-node-stubs


Basically modern Meteor makes much of what I did back then obsolete. My critical CSS cleansing is about the only thing I would still need to add. I haven’t worked on a project that required fast first render times in a while though so I have not maintained this.