What’s the best way to handle landing pages for Meteor apps? Do you host it on a separate server, with the Meteor app under a subdomain? Or is the landing page a part of the app itself? What are the costs and benefits for either method?
For example I’ve noticed that Kadira hosts their app separate from their landing page.
Every additional connection to a Meteor app adds some load to the server. If 99% of visitors are only looking to read your about page to find out what you do, you can just serve them static HTML on a separate domain, it doesn’t make sense to point them to your actual Meteor app.
Thanks @sacha. Yep that’s pretty much the main concern. For apps that serve individual pages, it’s no bother for the landing page to be part of the same server because only the portion that matters for the landing page is processed and served to the client.
But for a meteor app, the entire client-side portion of the app is served with every landing page request, even if 90% of it will not be used. And so if you’re experiencing a large influx of traffic from, say, hackernews or reddit, most of the traffic will just be people viewing the homepage and leaving (and by most, I mean > 90%). Should the rest of the app users suffer from that influx of home-page traffic?
And aren’t there stacks better built to serve static content than Meteor anyways (clearly I’m playing devil’s advocate here)? It would be great if more people chimed in on how they’re addressing this, especially for higher-traffic apps.
the initial startup time for a meteor app is a big problem right now because of the issues you mention where the whole app is transferred before anything shows up. arunoda’s fast render package is designed to mitigate that, but i haven’t found it much help.
a simple static site or SSG page is a much better option.
I think percolate guys rebuilt their landing pages in react so they can serve it up as a static page using SSR. this will also be better for SEO (if you have a bunch of landing pages, eg for different SEM campaigns)
Still it makes sense to just host it separately. I don’t think that will change pretty soon. It allows you to separate risk and performance in a very simple way. Next to that your web designers don’t need access to your app codebase which might be an advantage. And you keep your app as small as possible which is also an advantage.
Also you can even show if the app is down on your website when you have issues.
I don’t see a direct disadvantage of hosting it separately except when you would want a login form which is reactive inside the landing page. But that would make most of the advantages disappear anyway.
For a landing page (just to present info and land conversions), just host a static site on an AWS S3 bucket, and slap CloudFlare caching on it. Done. Your app itself is at app.mysite.com, which people can get to from the landing page, or just bookmark it. I don’t think having the subdomain is confusing at all, personally.
Question: the sub domain approach seems reasonable, but what about Google analytics and such - can it track across, from the landing page to what the logged in user will be doing? this since usually you tell GA what domain you will be tracking . thanks everyone in the thread. Very helpful.
I have to agree. We often assume that we ourselves are the end-users, but the reality is that the average user isn’t as tech-oriented as us. Little things like use of subdomains can make a big difference as far as usability. Subdomains are complicated for the average user to have to type in, for the same reason as a TLD that isn’t .COM makes your website more complicated for the average person who isn’t tech-oriented. Yeah you can do it, but there is a cost involved since it’s not what the average person expects to have to type into the browser. But if your user-base isn’t the average user (for example if your app is for programmers) then by all means tell them to visit app.coolapp.io instead of coolapp.com