What is a Core Site and Should You Have One?

What is a Core Site and Should You Have One?

Earlier this month I wrote about Google deprecating their AJAX site crawling scheme. In that article I mentioned the concept of a core site. I have mentioned it a few times on this blog and covered the concept in detail in my High Performance Single Page Web Application book. I first heard the term from Andy Hume at a Smashing Conference a few years back. Since I had not fully explained the concept here I thought I would take some time and demonstrate the concept.

What is a Core Site?

In summary a core site is a legacy version of your modern web site. One that is served from the server fully rendered with some basic CSS, maybe even targeting obsolete browsers and little if any JavaScript. Your goal is to serve something that works in these out dated browsers, like Internet Explorer 8 or early Android browsers. It is a way to have a progressive enhancement solution available for your modern, single page application, when there is no real rich client-side support.

Classic Server-Side Web Platforms

In contrast a modern, single page web application, has the markup served from the server, but not rendered or merged with data. Instead data is retrieved via an API call and rendered on demand in the browser. The benefits are what we call a richer user experience. Applications load faster and content is rendered quicker. This means you can not only eliminate many of the traditional user experience latencies inherent to a classic, server-rendered web site, transitions between views or pages can also be animated and the user never feels like they are using a web site, but more of a native application.

Unfortunately there are still many end users that are not using a modern browser, which means they cannot run a single page application. Sure developers could create something that works, but this is an expensive, time consuming process. A core site offers a good alternative, in fact existing web sites can and should be used as the core site.

The way you determine if you need to serve a core site or the rich version is to do some simple feature detection. For example I normally check 4 properties, which typically takes care of things for me:

  • querySelector
  • addEventListener
  • localStorage
  • matchMedia

Feature detection to load a core site or SPA needs a very simple script. Note this is what you should do instead of browser sniffing to determine if a browser supports required features. This script checks for the features, but then directs the user to the version they need. It accounts for link sharing from either version. This is where you send a SPA link to a user that has an old browser. They will automatically be redirected to the core site. In the opposite case if you get a core site URL you get quickly redirected to the SPA version. This way you can share links and the end user will get the appropriate version.

<script> var ef = "?_escaped_fragment_=" ; if (!( 'querySelector' in document) || !( 'localStorage' in window) || !( 'addEventListener' in window) || !( 'matchMedia' in window)) { if (window.location.href.indexOf( "#!" ) > 0) {window.location.href = window.location.href.replace( "#!" , ef);} else { if (window.location.href.indexOf(ef) < 0) {window.location.href = window.location.href + ef;}}} else { if (window.location.href.indexOf(ef) >= 0) {window.location.href = window.location.href.replace(ef, "#!" );}} </script >

If these features are not supported I redirect back to the core site using Google's AJAX crawling scheme as a guideline. The nice thing about the specification is it matched the pattern I needed to implement the core site support as well as ensure my applications could get indexed by the search engines.

Core Site Detection Logic

Core Site Reality

Supporting a core site means you must still maintain a traditional server-side infrastructure that is married with a modern single page application. Because I spend most of my time in ASP.NET MVC I wrote a library called SPAHelper that extends MVC to enable the server-side concerns of a single page application.

SPA Helper has pieces that identify if the request is for the SPA or the core site and serves the content accordingly. Of course the Home (default) view is much more complex than a normal index.cshtml file, but this is to be expected.

When implemented you have an application that has working versions for both modern and legacy browsers. However now you have 2 versions of your application to maintain. Often this means maintaining two sites within a single code base. Trust me that is not much fun. ASP.NET used to have a feature that would do that using a sever-side device detection library. They deprecated it because it just did not work and was a pain for them to maintain.

A classic Web Site Example

While most developers are struggling trying to learn how to build single page applications, they do not want to keep maintaining legacy web applications either. As a business you need to determine how much you want to invest in maintaining support for legacy browsers. Are those users financially worth your expense? Are they going to upgrade their browsers soon, if not when?

Microsoft officially drops support for Internet Explorer prior to version 11 this January. Sure there are some outlying exceptions to dropping support, but those cases almost do not exist. For example how many users are on old Windows Server operating systems? Is Windows 10 going to be adopted by enterprises and when? What about old Android devices? There is no real way to know when this will transpire. What we do know is it will happen and probably sooner than you expect.

Defining a Browser Support Policy

This leads to another question, what level of browser are you going to support? This topic is too deep to cover today, but you really need to start adding it to your application requirements it you ever expect to have any control over user experience.

I like Google's browser support policy, n-1. That means Google officially supports the most current browser version and the previous version. This makes support much easier and encourages users to keep their browsers up to date. A core site is just a way to provide some sort of interface for these old browsers.

Modern Browsers

Rather than focusing on specific browsers and versions move the support level to technical features. I go back to my core site redirection script. Focus on features you need to make your application work. We have and have had a great deal of rich APIs available in the browser for some time now. I think most developers are not aware of their presence, like offline, geo-location and more. Personally I get more excited about these types of APIs than syntactic sugar of ES2015 and ES2016, they don't add much value, just developer coolness. I would much rather have new user experience features.

Back to what browsers you should support. Learn about the features offered by HTML5, CSS and browser APIs. This is where you can make money by making richer user experiences. But this can be tricky, how soon do you adopt something?

Tracking browser support is easy, I recommend CanIUse or Microsoft's Status site. You can look for a feature and it will give you a nice support table. Stay away from HTML scorecard sites because they are often out of date and lack impartiality.

Again if you have traffic from legacy browsers and it is financially important then maintain a core site. But do not let it be something you invest more than the profit those visitors bring your company. That is just good financial sense.

With the deprecation of the Google crawling scheme and the impending death of legacy Internet Explorer versions I think it is time to consider dropping the hassle of the core site. Instead it is time to start focusing on building fast, single page applications with less and less code. This also means the life span of isomorphic JavaScript is also coming to an end. And I say good riddance.

I know there are going to be certain circumstances where supporting legacy browsers is mandatory. For those of you with that burden my condolences. It is time we start moving forward and let the past be the past. This is not something that just happens with the snapping of the finger, but something we need to phase toward.

If you currently have a working version of an application based on 'legacy' server-side techniques feel free to keep it running. But invest more resources in building a new, modern version. Implement my cutting the mustard script and marry it with your existing site. I also encourage you to somehow inform your customers to possibly upgrade their browser so they can get the rich experience with new features.

Share This Article With Your Friends!