React, Flux, GraphQL, Hack, HHVM...? All of this and more!
For Angular 2 one of the capabilities developers have been coveting from React.js ecosystem which is isomorphic rendering. This means that the first view is rendered on the server to improve initial load performance and enable best possible search engine visibility. In Angular 2 the framework gains this functionality with Angular Universal.
While Angular Universal is a great way to ensure SEO visibility, it does add complexity to the server side deployment of Angular 2 applications. There are dependencies on the backend technologies, so it's not a given that developers will be able to enable Angular Universal.
There is discussion for bringing Angular Universal support to PHP and Twig, but details are unknown. This is why many Angular 2 applications will be continue to be deployed without server side rendering of applications.
In an experiment on how well Google's own Search Crawler GoogleBot is able to render Angular 2 applications, we'll take a look at how GoogleBot is able to render the example application from the Angular Team, Tour of Heroes.
Using the Google Webmaster tools you can get the GoogleBot to visit your page and render your site. You can also get a rendered view of the page two formats:
So for individual pages it is clear that GoogleBot can execute and index raw Angular2 applications, however when using the "Crawl this URL and its direct links" option on indexing record you can see that there are no entries to other pages of the application.
This means that when you decouple from a CMS with Angular 2, for example, individual pages will be available - but it will not be able to natively follow all the links in the page. You'll still need to take care of SEO when deploying Angular 2 applications without Angular Universal.
In addition it's worth noting that by default Angular 2 now uses the "HTML 5 pushState" style for routing. So the issue when decoupling websites with a REST API and 404 pages continues to remain relevant:
If your custom backend does not handle checking if the content exists or not, then you'll likely get 404s, heading to a broken page. You could fix this by always sending a template with the HTTP 200 (OK) message, but that would be breaking the internet. If a page does not exist, it should return a 404.
- REST, Angular HTML5 History API and not found (404) pages
When Decoupling CMS other applications with a REST, it will be better done in the future with a separate rendering server with Node.js with Angular Universal enabled. This will make hybrid solutions more difficult and add complexity - but is a necessity for best Search Engine visibility.Tweet