Preferable Tactics For Single Page Application

Single page application also uses JavaScript to load other content when users are navigating to other parts of the single-page application. These are often called views rather than pages. This technique allows us to load views without the browser doing a full reload and allows us to use custom transitions between the different parts of the application. Single-page apps might use an architectural pattern called the app shell model, where the shared parts of the UI in code, like menus, headers, footers, and so on, are loaded when initially loading the single-page application. And the different views are dynamically loaded into this shell, reducing the amount of data needed to send over the network. Okay.

So what do we need to look out for when building single-page apps? – I think it is time to look at our sample app, test it, and then improve it where we see potential. Our example application is an e-commerce web app You can browse different product categories, learn more about a specific product, and you can put it into your cart. It also uses the user’s location to display prices in the local currency. When we run the mobile-friendly test, there is a bit of an issue. The main content doesn’t show up. Time to investigate this.

In the JavaScript console messages, we can see that there is a problem with our code. We are incorrectly using an unsupported feature. That’s an important point here. Sometimes, we do forget that code doesn’t always take the happy path. In our example, we assume that we always get the user location. But we forgot to deal with situations where that isn’t available. It’s important to make sure that you cover all code paths to avoid these scenarios. Googlebot, for example, declines the request for the geolocation. I also noticed something else when using the shop. It does not change the URL when navigating between different views. But as Googlebot uses URLs to locate these different “pages”, or views in our case, this would mean that Googlebot would only see our homepage and nothing else.

To fix this, we can use the history API and proper link markup with href attributes to expose the other views as URLs within the links. It’s also a good idea to take a look at the titles and meta descriptions for our different views. Right now, all views have the same generic title and meta description. This isn’t really helpful when people are searching for the one specific product or a specific category in our shop. With a little bit of extra JavaScript, we can fix this quite quickly. This will look much better in the search results. A very common problem is the way that single-page applications are dealing with error scenarios, such as invalid URLs. In our example, the application displays an error message, but the server reports an HTTP 200. That is a bit of an issue, specifically, in single-page applications because the server doesn’t really do the error handling anymore. Usually, the server serves the web app in all cases, and then the JavaScript and the browser decides if it wants to display an error.

But HTTP status codes do help Googlebot and browsers decide how to deal with the response. So we should fix this. Here’s the JavaScript that deals with the error situation. It reads the URL and fetches the data, and if that fails, it displays an error message. But we can’t just tell JavaScript to report a different status code because this status code can’t be changed once the server sent it. What we can do, though, is to configure our server to respond with an error code for a specific URL, like /not-found gives a 404 and/maintenance gives a 500, and so on.

When we do that, we can use JavaScript to redirect to the designated error URL. This signals to the browsers and Googlebot that the page is just a redirect to another URL, and this URL is an actual error. Alright, now our web shop can be crawled and indexed, gives useful product information and search result pages, and behaves properly when there is an error.