I'm working with a startup that's using React for a site where SEO is really important, which means we need to do Server Side Rendering well.
We tried various traditional SSR solutions, but it always required front end engineers to set up and maintain servers. It was often quite slow in spinning up and generating responses, we'd lose flexibility in how we wrote our code, and it hampered our ability to ship features quickly. We'd need to deal with separate code paths for different user agents, and roll our own analytics to make sure we were sending the right thing to the right crawler. It was... non-trivial.
We tried some pre-rendering solutions, but they don't always come with built in caches, and if they do the first responses are always painfully slow. For a site that updates dynamically this is a deal breaker. In addition to that, users don't actually need to receive a server side rendered response most of the time. Only crawlers do. Making the experience slower for users.
So we decided to build something new. We combined really fast pre-rendering with a crawler and analytics service that pre caches the pages that search engines visit (with different user agents and devices), and shows you which user agents are utilizing your pages in different ways. It integrates easily with analytics services like honeycomb and can be deployed as an API on the edge (just send an API request on crawler requests), or you can CNAME a whole domain to it (we'll handle serving only to crawlers). It gave us the control we needed to not slow down our engineering teams, let frontend developers write frontend code without worrying about deploying servers, and give us the SEO insights and performance gains we needed to start utilizing React for a site where SEO is important. We also extended it for people who don't use react, as it'll work in front of any SPA.
It's finally polished up to the point where we can start letting people in off the street to kick the tires. Check out the demo on your own site and let us know what you think!
1 comment
[ 2.9 ms ] story [ 17.5 ms ] threadWe tried various traditional SSR solutions, but it always required front end engineers to set up and maintain servers. It was often quite slow in spinning up and generating responses, we'd lose flexibility in how we wrote our code, and it hampered our ability to ship features quickly. We'd need to deal with separate code paths for different user agents, and roll our own analytics to make sure we were sending the right thing to the right crawler. It was... non-trivial.
We tried some pre-rendering solutions, but they don't always come with built in caches, and if they do the first responses are always painfully slow. For a site that updates dynamically this is a deal breaker. In addition to that, users don't actually need to receive a server side rendered response most of the time. Only crawlers do. Making the experience slower for users.
So we decided to build something new. We combined really fast pre-rendering with a crawler and analytics service that pre caches the pages that search engines visit (with different user agents and devices), and shows you which user agents are utilizing your pages in different ways. It integrates easily with analytics services like honeycomb and can be deployed as an API on the edge (just send an API request on crawler requests), or you can CNAME a whole domain to it (we'll handle serving only to crawlers). It gave us the control we needed to not slow down our engineering teams, let frontend developers write frontend code without worrying about deploying servers, and give us the SEO insights and performance gains we needed to start utilizing React for a site where SEO is important. We also extended it for people who don't use react, as it'll work in front of any SPA.
It's finally polished up to the point where we can start letting people in off the street to kick the tires. Check out the demo on your own site and let us know what you think!