In recent years the web development world has been flooded by many frameworks and libraries that introduced a completely different approach to web applications and web sites developed with the purpose of significantly improving the speed and fluidity of the application itself, leading to a much more enjoyable user experience and satisfaction.
Such frameworks are designed to build a web application where data is frequently modified. As the data is updated, the views change without reloading the page.
These types of applications are called Single Page Applications (SPA). That means that the whole application is an HTML document with a basic structure that loads the required script, which is responsible for content rendering. The static document is dynamically updated with content without reloading.
The technology behind this allows us to establish more fluid interactions with the user than ever before.
Although SPAs are primarily intended to stand for web applications where the user can add, delete and search various data, such technology is more extensively used to create dynamic websites that offer fluid browsing experiences through pages with beautiful transitions and without the wait for content to load.
Since this type of development is conceived for applications that require a user to log in to access them, there is no need to invest time in optimization for search engines because the content doesn’t have to be searchable.
But what happens when we use the same technology to build a modern website?
SEO Challenges
When creating a presentation website in such a way, we encounter problems with Search Engine Optimization (SEO).
Because the initial HTML document consists of a single element and a script, search engines do not see any content and therefore ignore the page and can’t index it.
Admittedly, Google has a well-developed SPA indexing technique because Google crawlers wait about thirty seconds for JavaScript to render content and then scan the page after they receive the HTML document.
The problem is that other search engines like Bing are not (yet) doing this, so it is necessary to think about this problem, whose solution has multiple benefits for the web owner.
Except for search engines, if necessary, the site should also be optimized for sharing on social networks. For example, if a user copies a URL and shares it on Facebook, a post will show information about the page which is fully customizable by defining page’s Open Graph tags.
Understanding SEO
In order to more easily understand the problem with SEO on SPA, we need to briefly explain what SEO work. When optimizing SEO, it is necessary to pay attention to content keywords, URLs, meta tags, internal linking, and OG tags.
Content
Content on the site should be smart and logically organized. It should include carefully selected keywords to increase search traffic. Keywords need to be investigated to see how users are already searching for information and then place the keywords in the ideal content locations.
URL
URLs play a big role in SEO, whether on static or SPA websites, as they contribute to better search engine results. URL slugs should be clear, separated by "-" and should contain the most important keywords related exclusively to a specific page.
Meta tags
Meta tags are very important for categorizing web pages properly. The most important meta tags that every website should include are title, keywords, description, and content-type.
Internal linking
Placing the main navigation at the top of the page and positioning the network of the links within the content allows crawlers to access pages faster.
Open Graph tags
Open Graph (OG) tags are used to add a page description when sharing on social networks, as we pointed out in the previous chapter.
The problem is that anytime the URL changes, meta tags, and OG tags should be updated dynamically aswell., In static web pages, each page has statically defined meta and OG tags.
Solutions for SEO challenges
There are several options for solving SEO problems:
- Develop SPA in combination with backend in eg PHP / Laravel in such a way that everything that is made as SPA is rendered as static HTML as well (in this case the page works even if JS is turned off)
- use NodeJS that delivers static HTML to search engine crawlers and SPA to the user
In this post, we will dwell on the first option since we used it on the SPA project ourselves.
The basic SEO problem is that the content of the SPA site is not immediately available for crawlers. For this reason, it is necessary to develop a static web page that loads all content, including metadata, og tags and more. A static web page will load instantly, allowing the crawlers to reach the content.
A second later, the script loads and the content is generated once again but this time as an SPA site with all its benefits. This is a solution for search engines, but what if we go to a page from navigation? The content changes but the metadata remain the same because we did not resubmit the request for new content and refresh the entire document. In this scenario, all metadata should have been dynamically updated to fit the page on which they are located.
When this is done, we can say that the universal app is ready for testing and production.
Functional problems developers had to face
The idea of ​​a web, developed with a combination of these technologies, requires a little more engagement on the part of the development team as it is necessary to consider the operation of dynamic and static websites where each mode of development carries separate challenges that seek effective solutions.
Considering this, development itself takes more time and the overall cost to the client is slightly higher. However, when customer needs are met, the return on investment is significant.
To develop single-page applications our development team uses the ReactJS framework. The high-end issues the developers had to face included:
- A need to create two separate components that control routes, one for server-side rendering (SSR) and the other one for SPA Static content appearing for a millisecond on the first load
- Page navigating issues (Browser history)
A need to create two separate components that control routes
The problem that arises right at the beginning of development is how to handle the retrieval and display of data or in this case the web content from the server, and how to forward data between components.
If it is a classic SPA, it is enough to create one main JavaScript file to define the routes for each page. Each route will call a component that will generate content based on the passed information.
In this situation, it is necessary to define a route for each view or page in order to be able to reach a specific link, eg "mywebsite.com/about". To clarify, components are meaningful segments (elements) in an application. For example, the “Latest posts” section is a component containing the “Blog post” component, etc.
The component used to generate content contains all components used on the web, it calls them and render them depending on what the route is about.
The combination with SSR complicates the situation because the content is retrieved from the server each time the page is loaded. This means that one load is equal to one view.
This means that it is not necessary to define routes for each page. A basic route that calls a particular component (let's call it SSRController) to which the content for that particular page is passed is sufficient.
The route management is handled on the server where the content is also rendered and delivered to the browser, where it is displayed.
To simplify, when using SPA in conjunction with SSR, more time is required to set up the project so that content can be managed at both the server and client-side to obtain a fully functional website that is eligible for SEO setup and content delivery when the browser does not use JavaScript.
Static content appears for a millisecond on the first load
The fundamental disadvantage of the SPA application is that the first load is relatively long because it waits to load a JavaScript file, which is responsible for rendering the content on the web page.
The longer the file is loaded, the longer the user sees the blank content. If it is a pure SPA the gap lasts a fraction of a second and the content will load immediately the next time due to the JavaScript already being cached.
But what about when content is rendered on a server as well? The content is instantly displayed and then JavaScript is reloaded to render the content. The user sees the content loading twice which is an unwanted user experience and becomes a challenge for the developer.
The simplest option would be to add an overlay over the content. Before loading the content (rendered by JavaScript), a loader will show up and disappears after a second. This covers the gap at the beginning and creates the impression of waiting to load.
A potential problem, however, is if the JavaScript is disabled. The overlay over the content would be visible, creating a blank screen for the user.
The final solution here would be to add a small script at the top of all scripts which checks if JavaScript is enabled or not. If it is, all content will hide, if not, the content will remain visible. This way provides an elegant, user-friendly transition.
Page navigating issues (Browser history)
Generally, browsers save visited URLs to a history list, recording the title of the page and the last time it was visited. This allows the user to utilize the previous and next buttons to easily navigate within the same domain.
SPA works by changing the views but, since the pages are not refreshed, the previous views are not saved. If the user clicks the back button, nothing will happen, leading to an unnatural response for the user.
It happens because the browser thinks that the user is still on the home page, although, technically, he had already visited several pages.
The solution to this problem is the implementation of an HTML5 History API which gives access to browser navigation history via JavaScript and provides the ability to save the state of SPAs.
The following navigation problem is best exemplified by the following example.
Let's say we have a website with a list of news posts that uses load more that reveals new posts below the existing ones. A very handy feature for pages with many blog posts, where clicking the link leads to the next set of blog posts.
When a user opens a blog post, they come to a URL like "/news/post15" and want to use the back button to return to the list of posts. The browser, by default, returns him to the top of the previous "/news" page where the first 10 posts were loaded.
In such a case, the user experience is disrupted because the user expected to return to where he left off and not to the very beginning.
The solution to this problem is to create a function that, when loading a page (after clicking on the back button), checks which post the user has clicked on, the page the post was on, and the position of the clicked post on the screen so the page scrolls down to that post.
Conclusion
Web applications can be developed in many different technologies and in different environments that sometimes require different approaches to the development itself.
The use of frameworks both on the front end and the back end has been on an upward trajectory for years as they offer a myriad of options that ultimately result in fluid and highly functional websites and web applications.
Depending on whether the web application is public and intended for all users or is closed only to logged-in users, development requires certain adjustments and attention to the environments in which the application or page will be used and with which tools and search engines will it "cooperate" with.
Throughout this process, developers are faced with a number of challenges that need to be addressed and problems that need to be overcome in order for the release-ready application.
In this post we have listed and explained the following problems from our own experiences:
- Search Engine Optimization issues
- Route control issues
- Content appearing issues
- Page navigation issues
These problems require a certain approach to development and a time to create an application ready for all conditions, is accessible, is fast and is usable to the end-users.
If you need help making your SPA search engine optimized, give us a shout and let's do it together.