React is designed to create interactive modular and cross-platform interactive user interfaces. Currently, it is a very much popular JavaScript framework for writing effective front-end applications. Originally developed for writing single-page applications (SPAs), React is now used to create complete websites and mobile apps. If you have experience in web development and you switch to React, you will find that your HTML and CSS code is increasingly converting to JavaScript. This is because React doesn't recommend creating or updating UI elements directly but rather describing the "state" of the user interface. React then updates the DOM to match the state in the most efficient way possible. Therefore, any changes to the user interface or DOM must be made through the React engine. While this is convenient for developers, it can have longer loading times for end-users and more indexing tasks for search engines. In this article, we'll look at the challenges you face in building SEO-optimized React apps and websites and outline strategies you can use to overcome them. Google gets over 90% of entire online searches. Let's understand via pointers about its crawling and indexing process.
Note that there is a clear difference between the processing step that parses the HTML and the renderer which executes the JavaScript. This distinction is made because JavaScript is costly to implement, given that Google bots must display more than 130 trillion web pages, according to the search engine land. When Googlebot crawls a web page, it immediately parses the HTML and then queues the JavaScript. The Google documentation says that the page stays in the view queue for a few seconds, although it could be longer. Also, it is worth mentioning the concept of crawl budget. Google crawling is limited by bandwidth, time, and availability. It is based on Googlebot instances. It allocates a certain budget or indexing resources for each website. If you create a large, content-rich website with thousands of pages (such as an ecommerce website) and those pages use a lot of JavaScript to display the content, Google may read less content from your website. Why is SEO Optimization for React Challenging? Software developers need to identify potential problems because of search engines while crawling, and indexing React pages. We will see the closer on what makes React SEO complicated or challenging and what developers can do to overcome this issue: Empty content of the First pass: React applications trust mostly JavaScript and often have trouble with search engines. This is because React uses a standard application shell model. The original HTML contains no meaningful content, and the user or bot must run JavaScript to display the actual page content. This approach means that Googlebot will find a blank page the first time it switches. Content is only visible to Google when the page is displayed. This slows down content indexing when you are working with thousands of pages. Loading time and user experience Javascript takes time to fetch, parse and execute. In addition, JavaScript may have to make network calls to get the content, and the user may have to wait a while before displaying the requested information. Google has introduced a number of web metrics related to the user experience used in ranking criteria. Longer loading times can affect user experience rankings and cause Google to rank pages lower. Page Metadata: The <meta> meta tag is useful because it allows Google and other social media sites to display relevant page titles, thumbnails, and descriptions. However, these website relies on the <head> tag on downloaded web pages for this information. This website does not run JavaScript for landing pages. React displays all content, including meta tags. Since the app shell is the same for the whole website/app, it can be difficult to customize the metadata for each page. Sitemap: A sitemap is a file that you use to provide information about the pages, videos, and other files on your website and the link between them. SEO like Google read this file to help index your website more intelligently. React has no built-in way to create sitemaps. If you're using something like React Router to manage your routing, you can find tools that can create sitemaps, though it might take a bit of work. Other SEO considerations: These considerations apply to developing good SEO practices in general.
We can solve various problems described above by using server-side rendering (SSR) or pre-rendering. Enter Isomorphic React: The dictionary of isomorphic dictionaries is "equivalent or similar in the form". Under React, this means the server has a similar client form. In other words, you can utilize the same React components on both the server and the client. This isomorphic approach allows the server to display a React application and send a visualized version to end users and search engines to see the content instantly as JavaScript is loaded and running in the background. A framework like Next.js or Gatsby encourages this approach. It should be noted that isomorphic components can differ significantly from traditional React components. For example, they can contain code that runs on the server, not on the client. They can even contain API secrets (though the server code is removed before being sent to the client). It should be noted that this framework abstracts a lot of complexity but also provides an interesting way to write code. We'll look at the performance tradeoffs later in this article. Website performance indicators: Let's see some of the factors that search engines use to rank websites. Google believes that a good website should not only respond quickly and accurately to user requests but should also have the following characteristics: • Needs to load quickly. • Users can access content without waiting too long. • Must be interactive with user actions early on. • It should not fetch redundant data or execute costly code to prevent user data or battery draining. These functions roughly correspond to the following indicators:
Next, let's understand the different rendering paths available to React developers. Road rendering: We can display the React application in the browser or on the server and give different results. Two functions differ significantly between client and server visualized applications, namely routing and decoding. Client-side rendering (CSR): Client-side rendering is the core rendering path for React SPA. The server serves applications that do not contain any content. The HTML content is loaded or displayed as soon as the browser downloads, analyses, and executes the existing JavaScript source. The client application manages the routing by managing the browsing history. This means that regardless of the route requested, the same HTML file will be served, and the client will update its display state once it is displayed. Code splitting is relatively easy. You can break your code using dynamic imports or React.lazy so that only the required dependencies are loaded based on the route or user action. If a page needs to fetch data from a content rendering server - for example, a blog title or product description - this can only be done if the required components are installed and rendered. Users will most likely see a "Data Loading" sign or indicator when the website pulls additional data. Client-side Rendering With Bootstrapped Data (CSRB): Imagine the same scenario with a CSR, but instead of fetching data after the DOM is rendered, the server sends the appropriate data loaded into the HTML. Server-side Rendering to Static Content (SSRS): Imagine a scenario where we need to render HTML on the go. The generated HTML has a fairly simple structure, and we don't need to React to manage and manipulate the DOM once the generated HTML has been served. So we only deliver HTML and CSS content. You can use the renderToStaticMarkup method to do this. The server completely handles routing as it has to recalculate the HTML for each result, although CDN caching can be used to serve faster responses. CSS files get cached by the browser to speed up page loading. Server-side Rendering with Rehydration (SSRH): Imagine the situation same as above, but this time we need a fully functional React client application. We do the server rendering first and send back the HTML content along with the JavaScript file. React rehydrates the markup provided by the server, and the app behaves like a CSR app from now on. React has a built-in method for performing this action. The server processes the first request, and the client processes subsequent rendering. Therefore, such applications are called Universal React applications (which appear on both the server and the client). The routing processing code can be shared (or duplicated) on the client and server. It's also worth noting that ReactDOMServer only does the flat rendering. In other words, even if visualization methods are called on your component. This result in revising your code to provide data to your components using alternative methods. This approach has had mixed results in terms of page yields, as we will soon see. Pre-rendering to Static Content (PRS): What if we could display the web page before the user requested it? This can happen during construction or dynamically as data changes. We can then store the generated HTML content on the CDN and wait more quickly when the user requests it. This is known as pre-rendering. Before rendering the content, the user requests. This approach can be used for blogs and e-commerce applications because the content is usually independent of the data provided by the user. Pre-rendering with Rehydration (PRH) We may want the pre-rendered HTML to be a fully workable React application when the client renders it. After submitting the first app, it behaves like a standard React app. This mode is similar to the SSRH described above in terms of routing and decoding functions. Summing up: Pre-rendering to static content (PRS) leads to the most efficient website, while server-side rendering with hydration (SSRH) or client-side rendering (CSR) can lead to miserable results. It is critically good to use several approaches for various parts of the website. For example, these performance metrics can be so important for a website that they can be indexed more efficiently, while they can become less relevant once a user has logged in and viewed private account information. Each rendering path is a tradeoff. What is important is that the development team can identify and discuss these tradeoffs and choose an architecture that maximizes user satisfaction. To truly harness the power of performance analysis, you have to understand the digital and eCommerce assets role in your business, define appropriate SMART goals and KPIs, and finally, adjust your digital content based on an analysis of your customer behaviour. This is the way to make your data-driven strategy work. At Katalyst, we help companies leverage their data and help them in optimizing their performance. Contact us now.
0 Comments
Leave a Reply. |
Archives
October 2020
Categories |