Although search engines have come a long way when it comes to handling JS-heavy websites – and they claim there’s no need to worry (time and time again) – the tests continue to tell a different story.
Fortunately, Prerender was designed to break this barrier.
The Prerender Process
So, how does Prerender solve this problem? Here’s a breakdown of its process:
- First, you install the appropriate middleware to your backend/CDN/web server. Unlike hardcode solutions, Prerender can be integrated into almost any tech stack. Here’s a complete list of all available integrations, including ExpressJS, Rails, Cloudflare, Java, C#, PHP, Python, and more.
- When the middleware detects a bot is requesting your page, it’ll send a request to Prerender.
- If it’s the first time, Prerender will fetch resources from your server and render the page on its server – it could take a few seconds. Alternatively, you can submit a sitemap (which Prerender will crawl every seven days) or push URLs through our rest API to avoid the first-time cache delay.
- Next, it’ll take a snapshot of the fully-rendered page and send it back to the SE (cached).
- From then on, Prerender will serve the cached version when it detects a bot user-agent, making the response near instant. (Note: In most cases, we see websites scoring 90-95 on Page Speed Insights tests, while they were scoring lower than 30 before implementing Prerender.)
- If the tool identifies the user-agent as a real user, it’ll send the traffic to normal server routes.
This is what’s called dynamic rendering.
Search engines will get a rendered version of your pages, boosting your crawl budget and fixing indexation issues. While users will be able to experience the full extent of your website – dynamic content and all –, increasing engagement and conversions without sacrificing organic traffic.
No missing content, crawling issues, or indexation delays.
How is Prerender Different From Other Solutions?
There are three other potential solutions Google has been pushing lately:
- Server-side rendering (SSR)
- Static rendering
- Hydration rendering
Server-Side Rendering (SSR)
To implement SSR, you need to build a backend capable of fetching the resources and (pre)rendering the HTML document before sending it back to the client. This is great for SEs because your server would handle the rendering process and serve them a static HTML document they can crawl and index.
However, there are several challenges and limitations you’ll need to overcome with SSR – you’ll:
- Need to write your application in universal code that runs both on the server and client
- Be locked to a Node.js server to be able to (pre)render your pages
- Need to set up and maintain servers and server environments – which might require 10-100x more computation power
- Take care of more complicated dependency management and caching, and more
All these complexities also mean more money, time, and resource. You’ll need to build an engineering team capable of handling the project as your website scales, or you’ll face many costly rendering issues.
Building a high-performance server capable of handling the rendering process might cost anywhere from $10k to $50k or more (depending on factors such as processor, RAM, storage, networking, cooling, power, and backup equipment).To this upfront cost, you also need to add engineering time. Developing and implementing the software for SSR can take anywhere from one to six months or even more, based on your teams’ experience and size.Considering a team of 3 developers at $50/hr, working full-time (160hrs/month) for 3 months, we’re talking to an investment of at least $72k.
On the other hand, when using Prerender, you’ll save on all this overhead and get your pages rendered properly. In fact, unlike other solutions, Prerender uses its own Puppeteer instance (using the latest chrome technologies) to ensure that the page is fully rendered no matter which technology you’re using.
Now, there are two more important distinctions:
- Rendering the page on the server takes time, which will inevitably slow your time to first byte (TTFB) – which Prerender manages using the cached version.
- Second, SSR is a solution to handle your own JS, not third parties. So the client, and thus search engines, will have to fetch and render these resources. This is not a problem for Prerender, as the only thing we block is common analytics, like Google Analytics, to avoid messing with your data.
Static rendering consists of generating a separate HTML file for each existing URL ahead of time instead of rendering the page on the server when a user-agent requests it. As you can imagine, it allows the server to respond very quickly as the response was generated ahead of time.
The problem with this approach is that it also requires a lot of time and work to pull off correctly.
Second, you’ll need to know all URLs ahead of time, and if you can’t predict what all URLs will be or the site has a large number of unique pages, static rendering won’t be sufficient because of its template-driven approach.
In the case of Prerender, it generates and caches a static HTML version of every page a search engine requests and gives you control over which pages should be ignored in the process to ensure you’re getting all your pages pre-rendered and avoid wasting your budget on unnecessary ones.
In addition, you can set Prerender to update your cached pages as frequently as you need without extra work from your end. This way, you can always serve the freshest content to search engines.
Hydration – or rehydration – is a combination of server-side rendering and client-side rendering.
For example: Despite the page rendering on the server and giving the client access to the HTML faster, it still needs to execute the client-side JS before becoming truly interactive. This process can take a few seconds or even minutes – especially on mobile devices.
This is not an issue for Prerender as all JS is executed on our server before being sent to Googlebot or crawlers alike – no missed content, no delays.
However, the Web.dev team itself recognizes it’s not the best solution:
“Performance metrics collected from real websites using SSR rehydration indicate its use should be heavily discouraged.”
The reason it’s simple. If your page’s content loads fast, but it takes several minutes to become actually interactive, you’re leaving the user in a weird limbo where everything seems like it should work, but they can’t take any action and don’t know why.
In contrast, Prerender allows you to serve a fully rendered (all JS executed) version of your page to search engines and route human users to the normal route of your site. So they can get the full experience of your dynamic website.
Prerender is About the User Experience, Not for Cloaking
Now, it’s easy to understand why Google is also pushing these other solutions. After all, even if your website is not well-optimized, using Prerender will improve all technical performance metrics for you.
This is often where problems arrive.
We’re well aware of how dynamic rendering and cloaking seem similar. Both techniques consist of sending a different version of your page to search engines and people, right? No!
Prerender is, first and foremost, a technical SEO tool designed to help you focus on user experience by helping search engines crawl and index your dynamic content properly.
“Googlebot generally doesn’t consider dynamic rendering as cloaking. As long as your dynamic rendering produces similar content, Googlebot won’t view dynamic rendering as cloaking.”
If you’re still worried, you can read our four rules to avoid cloaking penalties when using Prerender, but in the end, it’s about how Prerender works and how you manage your site.
Here are a few resources we’ve put together to help you:
- 5 Ways to Maximize Crawling Efficiency for Faster Indexation
- 19 Technical SEO Issues That Hurt Your Ranking + Solutions
You have more resources like these ones available in our blog.
The Benefits of Prerender
|Improve Page Speed Scores (Including Core Web Vitals)||After Prerender caches your fully rendered page, Google will get a near-instant server response with a fully-rendered, interactive-ready HTML page. Read how Softonic used Prerender to get a 92/100 Page Speed score.|
|Prerender will score different technical SEO elements when rendering your pages to help spot and solve issues.||Identify Technical Issues Holding You Back|
|Search engines need to invest additional resources to render your pages. Resources that could be used to discover new pages or (re)index changes.By taking away this extra step, Google can increase your website’s crawl budget and discover pages more quickly.||Improve Crawl Budget and Crawl Efficiency|
Enterprise SEO Solution, Minus the Hefty Price Tag
Prerender Offers a Clear and Adaptable Pricing Model
There are no hidden fees or complex concepts to understand when choosing a plan.
Prerender only charges you for caching tasks – like the first time a page is cached or recaching processes to pick up page updates. Because we cache your rendered pages, there’s no need to charge you for every request from the search crawlers, and we take care of caching storage and any other overhead, so you can rest assured you won’t find any surprises on your bill.
Get Your Updates and Optimizations Indexed Faster
You can set recaching intervals to match how frequently you update your pages. Once the interval is up, Prerender will recache your page, replacing the old snapshot and serving the newest version to search engine on-demand. This ensures search engines will always get the latest version of your pages, helping you get faster benefits from your efforts.
Identify Improvement Opportunities
During the rendering process, Prerender will check for technical expectations and best practices and assign an SEO score to your pages. You can access these analytics from your dashboard and organize your pages based on these scores. Using this feature, you’ll be able to spot underperforming pages that need your attention, adding an additional layer of performance monitoring to your current setup.
Cohesive Desktop and Mobile Performance
Most pages are responsive, so they don’t experience any issues. However, for those pages that serve a different version to mobile users, Prerender is able to cache both versions and serve the correct one based on the user-agent. (Note: To avoid confusion, Prerender will only cache mobile versions of your pages when a mobile crawler requests them.)
Serve Pre-rendered Pages to Any Bot You Need To
Although we cover all major search engine bots, you have the flexibility to add uncovered bots with a simple integration. No matter the situation, Prerender adapts to your needs!
Try Prerender for Free
You’re a Prerender expert now!
We try our best to make everything as simple and transparent as possible, so you can be sure you’re making the right choice. If you’re ready to take the next step, don’t hesitate to create a free account and try Prerender for the 1000 renders/month. Our team will be ready to help you set everything up.
See you in the SERPs!