JavaScript, WordPress and the REST API: Sorting Fact from Fiction

JavaScript, WordPress and the REST API: Sorting Fact from Fiction

Are you thinking about using the REST API for your WordPress site? Maybe you’ve been reading all about it, are intrigued but are put off by some of the disadvantages of working with JavaScript that you may have heard about.

When it comes to getting to grips with JavaScript and the REST API, it’s not unusual to be a bit nervous. After all, if you’ve been creating WordPress themes and plugins using PHP, or you’ve been downloading third party themes that are written in PHP (as pretty much all of them are right now), you’ll have to learn a whole new skill set or get used to a different environment.

You might also be worried about what making the switch means for your site’s performance and your users. Will it affect the user experience? Will it impact on your SEO? How fast will your site run? The REST API is very new so it’s sometimes hard to find concrete answers to these questions.

In this post I’m going to look at some of the things that might concern you when you’re considering working with the REST API. I’ll identify which of these you need to worry about and which you don’t. Hopefully after reading this post you’ll have a better idea of whether the REST API is for you.

I’m going to look at:

  • Browser compatibility,
  • Performance,
  • User experience,
  • SEO, and
  • Accessibility.

But first, let’s just remind ourselves of what the REST API is and the possibilities it offers us as developers.

The REST API: What Is It?

REST stands for REpresentational State Transfer, which I’ll admit doesn’t tell you much at all. Wikipedia clarifies things a little:

“RESTful systems typically, but not always, communicate over Hypertext Transfer Protocol (HTTP) with the same HTTP verbs (GET, POST, PUT, DELETE, etc.) that web browsers use to retrieve web pages and to send data to remote servers.”

In WordPress terms, that means using HTTP to access the data in your site’s database, rather than sending database queries directly using PHP or SQL.

Still confused? I know the feeling! More simply put, the WordPress REST API means that the data in your site can be accessed by an external application other than WordPress. You do this by using JSON (JavaScript Object Notation) and JavaScript itself. So you can build a website or an application on JavaScript instead of PHP.

This opens up two main opportunities:

  • By building a site in JavaScript, you can create something called a Single Page Application (SPA). If you’ve ever used Google Docs you’ve already interacted with one of these. A SPA is a website that behaves like an application and in which the content of the page changes following your interactions with it, without you having to switch to another page. Which makes things much more dynamic and interactive.
  • Because you’re not limited to PHP, you can build applications based on your WordPress data on other platforms, such as mobile. So you could have a normal PHP-based WordPress site and also build a mobile app that uses the data from that site, updates that data where relevant, and can have a completely different design from your website. You could also build a desktop app like Automattic’s Calypso app for

So if you’re creating simple websites (brochureware, blogs or information repositories, for example) you’re unlikely to need to use the REST API. But if you want to build something that’s much more interactive and reacts quicker to user inputs, then the REST API opens up all sorts of possibilities.

Now let’s move on to looking at the potential barriers to using the REST API and which ones you should or shouldn’t worry about.

Browser Compatibility

The most obvious thing about building a site in JavaScript using the REST API is that it will only run on browsers that have JavaScript enabled.

Try accessing a SPA you use frequently (something like Google Docs) and turn JavaScript off in your browser. It doesn’t look good:


Everything disappears! That’s because the application runs entirely on JavaScript. So if your users don’t have JavaScript enabled, they’ll be unable to even see your site, let alone interact with it.

But how many people are likely to not have JavaScript enabled? Well, on desktop that’s not many at all. All of the major browsers run JavaScript, so unless your users have decided to turn JavaScript off, they’ll have access to your site.

On mobile browsers you shouldn’t have a problem either. The major mobile browsers run JavaScript, even Opera Mini if it’s on a recent operating system. It used to be that Opera Mini’s method of rendering content via a proxy server meant that it didn’t play nicely with JavaScript, but in more recent releases that isn’t the case. However if your target audience is likely to be running older operating systems, then I’d advise checking which browser versions they’ll be running and what the JavaScript compatibility is.

If you do think you’ll have users who don’t have Javascript enabled, then you can add some content to your site which will only be visible to them. You put this inside a <noscript> tag. This tag hasn’t always been well used: developers sometimes use it just to tell users that they aren’t running javaScript (as in this very unhelpful example from W3Schools). But you can use it in a way that helps your users. Instead of telling them they’re not running JavaScript, give them information on how to turn it on and, most importantly, provide a link to an alternative page which isn’t running JavaScript. That way they can still access your content.


Everyone wants their site to perform as well as it can. Increasing your site speed will minimize the risk of losing visitors and boost your search engine rankings. If you aren’t already running a performance plugin (like our Hummingbird optimization plugin) on your WordPress site, you should.

But what does using the REST API do for performance?

Well, the biggest concern is around page load times. If your page is dependent on scripts then the browser will wait until it has loaded any scripts before moving on to the next element in the page. This is where JavaScript differs from CSS: when the browser comes across styling, it carries on loading the content after it and loads the CSS at the same time, while with JavaScript it stops what it’s doing until it’s loaded the scripts.

This means that you should resist the temptation to load all of your scripts straight away on loading your home page or SPA’s main page. Any scripts that aren’t necessary on page load should be loaded at the end of your page and not in the <head> section.

wp_head hook - Codex page
It’s bad practice to attach scripts to the wp_head hook in WordPress, as that means they’ll have to be loaded before anything else.

Of course, if you’re building a SPA which is completely reliant on JavaScript, this could be tricky. But think about the aspects of your application, the interactions, animations and anything else you need to load, and consider when they’re actually needed straightaway. Order things as efficiently as you can.

But it’s not all doom and gloom. Working with the REST API can improve your site’s performance in other ways. This doesn’t relate to page load but to the speed of interactions. As the REST API lets you store data locally in the client (i.e. the browser) rather than on the server, it means that when your user does something that means more data needs to be loaded, then that will happen much quicker.

So the answer is that using the REST API will only impact on your site’s performance if you don’t take care of your code and that once a user is interacting with a page it can improve performance.

User Experience

Which brings us on to User Experience, or UX. Using the REST API to build an app-like site can significantly enhance UX, but only if you understand your users and what they expect.

Whatever kind of site you’re building and whatever technology you’re using, good UX doesn’t stem so much from the technology as it does from an understanding of your users and their expectations and needs. If your users come to your site wanting a nimble application that responds quickly to inputs and lets them manipulate data in a way they can’t with a standard WordPress site, then the REST API will help you achieve this. But if your users expect to consume content, then what’s more important is the ease of accessing that content and the speed with which it loads. The REST API won’t add anything here.

Another area in which the REST API can improve UX is by making it easier for you to build a mobile app that supports your desktop site and mirrors it in a way that’s designed for mobile. Don’t just port the design of your desktop site over to mobile and expect that to work for your users. Developing a mobile app is a very different discipline, and you need to understand your users’ expectations of the interface and of how your app will work. Working with the REST API makes it much easier for your to do this than if you simply developed a responsive site, for example.

Make sure you have a thorough understanding of the interface you’re working with and your users. Do user testing and research and if you’re developing a mobile app, familiarize yourself with the guidelines on the interface for the operating systems you’re developing for.

If you're using the REST API to develop and app for Android or another operating system, make sure you follow their guidelines.
If you’re using the REST API to develop an app for Android or another operating system, make sure you follow their guidelines.



SEO sometimes feels like the holy grail of web development. When I’m talking to clients or potential clients, all they seem interested in is how high their site ranking with Google will be.

There’s more to it that that of course – you need to maximize conversions, so that once you’ve hooked those visitors using SEO, they do what you want them to and don’t leave your site.

But it is important to consider the potential impact of developing in JavaScript on your site’s SEO.

Developers often worry that a site built using the REST API won’t be crawled by the search engines. This is because the content is loaded by scripts after a page is opened, making the content invisible to some bots. But Google and the other search engines aren’t stupid. They know that if they’re going to provide useful information to their users in an environment where more and more content is being rendered via JavaScript, they need to crawl that content. And the good news is that they do crawl sites built on JavaScript.

The site for Themeconf, for example, is built using the REST API. When I search for it on Google, it shows up just as you would expect:

tehmeconf - a google search

However, you do have a little less control over what search engines crawl when your site is built on JavaScript. This test found that Google crawled almost everything in a web page that was loaded using JavaScript, with one exception: nofollow links. So if those are common on your site you may experience some issues. Otherwise, you should have no problems.

There are some bots that don’t see the JavaScript on your site. If your users past a Facebook link to your site, for example, it won’t be displayed correctly:

a link to themeconf on Facebook shows no image

So there may be an impact on your social media links but not on your SEO directly.


I’ve already talked about browser compatibility and the fact that modern browsers fully support JavaScript. But what about users who aren’t using a browser to access your site, but a screen reader or other assistive technology?

There is a perception that users of screen readers don’t have access to JavaScript, but this isn’t the case. In fact, a 2012 survey by WebAIM showed that 98.6% of screen reader users did have JavaScript enabled.

So this doesn’t mean your JavaScript site or SPA is necessarily going to be inaccessible. However, it does mean that you have to put the work in to make sure that it is accessible. Lots of developers will assume that JavaScript isn’t relevant to screenreader users and so they’ll provide a non-JavaScript fallback without considering the accessibility of their JavaScript.

If you’re developing a site using the REST API, it’s going to be reliant on JavaScript and you won’t want to be putting in extra effort to build an alternative accessible version: it’s more efficient to make your main site accessible. And given the number of screen reader users with access to JavaScript, you shouldn’t be anyway. But there are things you’ll need to do to ensure your site is accessible.

WebAIM say that:

“A web page containing JavaScript will typically be fully accessible if the functionality of the script is device independent and the information (content) is available to assistive technologies…. The only way to ensure JavaScript accessibility is by evaluating each page that utilizes scripting and devising a unique solution to any accessibility problem found.”

So, to make your site accessible you should:

wave accessibility tool
A tool like wave will help you asses your site’s accessibility

Conclusion: Things Are Better than You Might Think

Starting out with the REST API can feel daunting. There are a bunch of new skills to learn and you’ll most likely be building something quite different from the WordPress sites you’ve created in the past. On top of all that, there are the concerns you might have about how switching to JavaScript affects performance, accessibility, SEO and other factors.

But these aren’t as big a problem as you might assume. The good news is that Google and other search engines can crawl your JavaScript site, the vast majority of browsers will support it, UX and performance can be enhanced if you’re careful, and accessibility needn’t be an issue as long as you develop in an accessible way.

So what’s stopping you? If you’re still hesitant, our guide to using the WP-REST API will help you get started.

Are you using the REST API? What benefits has it brought you and what challenges have you had to overcome? Let us know in the comments!
Rachel McCollin
Rachel McCollin Rachel is a freelance web designer and writer specializing in mobile and responsive WordPress development. She's the author of four WordPress books including WordPress Pushing the Limits, published by Wiley.