I have a large, globalised web site (not a web app), with 50k+ pages of content which is rendered on a cluster of servers using quite straightforward NodeJS + Nunjucks to generate HTML. For 90% of the site, this is perfectly acceptable, and necessary to achieve SEO visibility, particularly in non-Google search engines which don't index JS well (Yandex, Baidu, etc)
The site is a bit clunky as complexity has increased over time, and I'd like to re-architect some of the functional components that are built mostly using progressively enhanced jQuery as they are quite clunky. I've been looking at React for this with the Redux implementation of the Flux pattern.
Now my question is simply around the following - nearly 100% of the tutorials assume I'm building some sort of SPA, which I'm not. I just want to build a set of containerised reusable components that I can plug into replace the jQuery components. Oh, they have to be WCAG AA/508 accessible as well
Does React play well with being retrofitted into websites and are there any specific considerations around SEO, bootstrapping, accessibility? Examples of implementations or tutorials would be appreciated.
You can mount react component to any DOM Node on your page, so it makes it easy to insert components in statically generated content.
Most of search engines like google would wait for js files to load before they index the page so it will index a page with react component perfectly fine. However if you want to be 100% sure that your page rendered correctly by all crawling bots you have to take a look at react server rendering. If you already use NodeJS for a backend it should not be a big problem.
I never encountered with that kind of problem but my best guess would be to use ReactDOMServer.renderToString to render component on the server and then replace a node in your static html layout. The implementation would depend on you template lang you use. You can use something like handlebars to dynamically create halpers from React Components. So in your static html page you would be able to use them as {{my-component}} But it's only my speculations on that subject, may be there is more elegant solution.
Here is the article that could help.
You'll be happy to know that this is all possible through something called isomorphic javascript. Basically you'll just use React and jsx to render HTML on the server which is then sent to the browser as a fully built web page. This does not assume your app is an SPA, rather that you'll have multiple endpoints for rendering different pages, much like you already have probably.
The benefit here is that you can use the React/Redux architecture but still allow you site to be indexable by crawlers, as requests to your app will yield static pages, not a single page with lots of JS to make it work. You're also free to gradually refactor by converting your Nunjucks rendered endpoints to React one at a time, instead of a big jump to SPA land.
Here's a good tutorial I found on making isomorphic React apps with node:
https://strongloop.com/strongblog/node-js-react-isomorphic-javascript-why-it-matters/
EDIT: I may have misread your actual desire which is to inject React components into your existing web pages. This is also possible, you'll probably want to use ReactDOM to render your components to static markup, and then you can inject that markup string into your Nunjucks via templating.
Related
For web development React or Vue seem to be a must have framework. Currently I just got some experience with NodeJs and Handlebars.
I know Handlebars runs a server side rendering, Vue and React run a client side rendering. Using Vue or React makes reusable components possible. Using a server side template engine requires a base layouting.
Let's say I have a website / webapplication with some routes. Why should I use Vue for HTML components instead of Handlebars HTML?
What I learned so far is that whenever I can
improve my SQL statement, do it before manipulating the data by code
do something at the client that can be done by the server, do it at the server because it has more power
Everyone is using Vue or React now, why should I leave the old structure and start outsourcing the code to the client?
I believe your question is more tied to the concept of server-side rendering and client-side rendering.
Server-side rendering has a few important points that you should consider when evaluating a problem:
Is faster to render the page in the server than in the client
It is much better for SEO(Search Engine Optimisation), since the crawlers can craw the entire page. Since some crawlers are not
evaluating/running javascript, a SPA(Single Page App) will probably
result in an empty page. Even though Google has improved quite a lot
with SPA SEO, server-side rendering is still the best option.
Client-side rendering, using SPAs, has different advantages:
Is much better to manipulate and maintain user state in the client-side, since you can have your webpage broken down into
components.
Faster interactions/page changes after the first load, since, in most cases, the entire app is loaded at once in the first request.
So with that in mind, you have to consider what you want to do. If you are building some website that reflects a more page-like structure, like a news or blog, server-side rendering is probably the best way to go.
On the other hand, if you are building a full-blown application that has loads of user interactions and state management, client-side rendering (or SPA) could be the best option.
There is no reason to outsource your code to the client-side without evaluating your problem first. That really depends on the problem you are trying to solve.
May I refer you to this article. As you can see it's not all black and white. From the cited article ..
Server-side pros:
Search engines can crawl the site for better SEO.
The initial page load is faster.
Great for static sites.
Server-side cons:
Frequent server requests.
An overall slow page rendering.
Full page reloads.
Non-rich site interactions.
Client-side pros:
Rich site interactions
Fast website rendering after the initial load.
Great for web applications.
Robust selection of JavaScript libraries.
Client-side cons:
Low SEO if not implemented correctly.
Initial load might require more time.
In most cases, requires an external library.
However, there are frameworks that do universal rendering such as next.js and nuxt.js (built around react and vue, respectively) that can leverage the powers of both the client and the server so you can have the best of both worlds. This usually involves sending the fully rendered application in the initial payload from the server to the browser and then loading the application code browserside afterwards.
I recently read an article about how HTML elements created with JavaScript are not picked up by the Googlebot / Google crawlers. The reason being, in its most simple form, the HTML the GoogleBot picks up is everything that is shown when you do View Page Source.
I'm about to start learning React, one of the reasons for this being that you can create template files and components, so common features such as headers and footers etc and be duplicated easily to keep your code DRY.
It worries me though that if I was to do this, the React / JSX generated HTML would effectively not be tracked by web crawlers, thus making it essentially invisible, which would create a large number of potential negatives, not least, inferior SEO.
My question therefore is - does HTML generated with React behave in the same way HTML generated with vanilla JavaScript does? I'm assuming it must do, but I can't find any proper answers to this when googling?
Many thanks,
Emily.
Reactjs is an isomorphic or Universal or environment agnostic.
You can build client side application and also server side applications.
As you are already aware of client side of it. Now you checkout the server side implementation in the below tutorial
https://scotch.io/tutorials/react-on-the-server-for-beginners-build-a-universal-react-and-node-app
you can also checkout the following boilerplates which provide SSR :
https://github.com/erikras/react-redux-universal-hot-example
https://github.com/TimoRuetten/react-ssr-boilerplate
The following is unclear to me. So far, I don't see lose Reactjs components embedded in views, but only in Single Page Applications.
I was wondering if one could use Reactjs in a Laravel application in combination with the blade template engine? I have a Laravel project and I like the way ReactJS binds to the DOM. But I do not need an entire JS SPA.
So is it possible AND a good practice to use different ReactJs components loosely in blade views? For example a React table component and a header message component, that also are able to communicate with each other.
There is a package that does just that.
However I would argue it would be a better practice if you separate the front-end and back-end completely. So you can use Laravel to serve the data using REST API endpoints and then display everything using a React app.
This way they will be loosely coupled and if you ever want to swap out one for the other (e.g. swap out React for Angular) then it would be a lot easier as your api endpoints wouldn't have to change at all.
EDIT: Some benefits of a headless CMS (taken from pantheon.io):
By shifting responsibility for the user experience completely into the
browser, the headless model provides a number of benefits:
Value: future-proof your website implementation, lets you
redesign the site without re-implementing the CMS
Sets frontend developers free from
the conventions and structures of the backend. Headless development
not only eliminates “div-itis”, it gives frontend specialists full
control over the user experience using their native tools.
Speeds up the site by shifting display logic to the client-side
and streamlining the backend. An application focused on delivering
content can be much more responsive than one that assembles completely
formatted responses based on complex rules. Builds true
interactive experiences for users by using your website to power fully
functional in-browser applications. The backend becomes the system of
record and “state machine”, but back-and-forth interaction happens
real-time in the browser.
Lets say you also want to build a mobile app using React Native that would use the same underlying code base as your React web app. If you have a decoupled CMS, so your backend is only serving data then you can make calls to this same backend from both your web app and mobile app without worrying about content types, response formats etc... In-fact, with React Native you can use the same React codebase for the mobile app along with the web app and you would only have to change some views around.
It's a great way to re-use your code with better modularity and seperation of concerns.
How you can see in React manual (ReactDOMServer):
If you call ReactDOM.render() on a node that already has this
server-rendered markup, React will preserve it and only attach event
handlers, allowing you to have a very performant first-load
experience.
So does it mean that if I use static index.html in which I just include my react app js file I don't have to use server-side rendering?
Btw which of react-app architecture better for SEO?
Thanks for you answers!
In theory, it's true that you can use static index.html. React will try to render the page on the client side and update your html. This has become much easier to do with React 15 as you no longer need to maintain data-reactid attributes.
Nonetheless, I'd recommend using SSR (server side rendering) because it makes life easier. Granted, it takes effort to set up but it's beneficial. You also get to make use of server side routing, critical path css, and more.
If you want SEO, universal apps are the way to go. Two excellent architectures are:
React redux universal hot example
React starter kit
Good luck!
So does it mean that if I use static index.html in which I just
include my react app js file I don't have to use server-side
rendering?
Of course. You can certainly use React purely on the client without any need for server rendering. However server side rendering can be beneficial for graceful degradation. It also helps from a usability perspective as your user won't have to wait for javascript to be downloaded and executed before any content can be shown.
Btw which of react-app architecture better for SEO?
Now search engines have significantly matured in their ability to crawl dynamic pages. However the support for javascript generated content is a work in progress in most engines. As Google Webmasters blog explains:
Sometimes the JavaScript may be too complex or arcane for us to execute, in which case we can’t render the page fully and accurately.
Some JavaScript removes content from the page rather than adding, which prevents us from indexing the content.
So from SEO perspective it is still better if you opt for server side rendering.
Articles on React.js like to point out, that React.js is great for SEO purposes. Unfortunately, I've never read, how you actually do it.
Do you simply implement _escaped_fragment_ as in https://developers.google.com/webmasters/ajax-crawling/docs/getting-started and let React render the page on the server, when the url contains _escaped_fragment_, or is there more to it?
Being able not to rely on _escaped_fragment_ would be great, as probably not all potentially crawling sites (e.g. in sharing functionalities) implement _escaped_fragment_.
I'm pretty sure anything you've seen promoting React as being good for SEO has to do with being able to render the requested page on the server, before sending it to the client. So it will be indexed just like any other static page, as far as search engines are concerned.
Server rendering made possible via ReactDOMServer.renderToString. The visitor will receive the already rendered page of markup, which the React application will detect once it has downloaded and run. Instead of replacing the content when ReactDOM.render is called, it will just add the event bindings. For the rest of the visit, the React application will take over and further pages will be rendered on the client.
If you are interested in learning more about this, I suggest searching for "Universal JavaScript" or "Universal React" (formerly known as "isomorphic react"), as this is becoming the term for JavaScript applications that use a single code base to render on both the server and client.
As the other responder said, what you are looking for is an Isomorphic approach. This allows the page to come from the server with the rendered content that will be parsed by search engines. As another commenter mentioned, this might make it seem like you are stuck using node.js as your server-side language. While it is true that have javascript run on the server is needed to make this work, you do not have to do everything in node. For example, this article discusses how to achieve an isomorphic page using Scala and react:
Isomorphic Web Design with React and Scala
That article also outlines the UX and SEO benefits of this sort of isomorphic approach.
Two nice example implementations:
https://github.com/erikras/react-redux-universal-hot-example: Uses Redux, my favorite app state management framework
https://github.com/webpack/react-starter: Uses Flux, and has a very elaborate webpack setup.
Try visiting https://react-redux.herokuapp.com/ with javascript turned on and off, and watch the network in the browser dev tools to see the difference…
Going to have to disagree with a lot of the answers here since I managed to get my client-side React App working with googlebot with absolutely no SSR.
Have a look at the SO answer here. I only managed to get it working recently but I can confirm that there are no problems so far and googlebot can actually perform the API calls and index the returned content.
It is also possible via ReactDOMServer.renderToStaticMarkup:
Similar to renderToString, except this doesn't create extra DOM
attributes such as data-react-id, that React uses internally. This is
useful if you want to use React as a simple static page generator, as
stripping away the extra attributes can save lots of bytes.
There is nothing you need to do if you care about your site's rank on Google, because Google's crawler could handle JavaScript very well! You can check your site's SEO result by search site:your-site-url.
If you also care about your site's rank such as Baidu, and your sever side implemented by PHP, maybe you need this: react-php-v8js.