Category Archives: Tech

CC By Sherrie Thai -

How I sped up WordPress 4x on mobile

With new Chrome, we got even more developer tools. Newest version has a feature “Capture screenshots”. It will record your page load and display how it looks as it’s downloaded to your browser.

After watching Paul Irish comment on some of the large media sites, I started wondering – how is Val 202 doing? It’s getting a decent amount of traffic on mobile devices. It also has a large amount of traffic through Facebook and Twitter, meaning that they probably don’t have our assets cached.

First test – 3G, no-cache: 9.34 seconds until title is displayed!

slow-1Ok, that’s clearly bad. It also means that they potential readers will probably abandon page load and go watch kittens that load from a faster domain.

Looking through all the assets that our theme loads, I see a bunch of potential problems:

  • Plugins that we’re starting to deprecated, but they still load resources
  • External assets and iframes that we don’t even display on mobile
  • Disqus for comments, that we could hide
  • Images that are lower on site, and we could lazy load
  • We load all our assets from our domain, so we hit the limits of how many resources browser downloads in parallel

I try to disable as much of above functions, just to see if it’s worth of development time. Here’s my second measurement (3G, no-cache): 5.65 seconds until content appears.


I got the page to load in about half the time. Better, but not good enough.

As I cut even more things, I try to disable TypeKit and with it, time to content falls dramatically. Aha!

Reading TypeKits’ documentation reveals that it waits 3 seconds by default, to ensure that fonts load and there is not flash of unstyled content. But on mobile, we could decide that we’re ok with the flash as long as we show our reader content as soon as possible.

Third measurement (3G, no-cache), with async TypeKit: 2.5 seconds until content appears


Still not the best, but it’s a 4x faster than current version.

For now, I’ll try to load TypeKit in Async mode for devices that have smaller window width:

While this approach is not optimal, it gives us a quick win, while we work on streamlining the rest of the frontend code.


WordPress is great for quickly iterating and running content experiments. The problem is supporting this in the long run.

It’s also easy to forget elements of previous experiments in code – custom fonts, icons and whole scripts. It’s good to take a step back and reevaluate our code in terms of new usage patterns and best practices.

WordPress Analytics Engine


I think I’m obsessed with numbers. They give me a feeling of control. Page views, trends, visitor count and more. Not measuring things, makes me sad. If we have a historical data, we can check if our changes worked. Are certain topics more popular? Which stories are more popular on Twitter compared to Facebook? Infinite amount of questions.

I’d like to build a better analytics engine for us. I’ll explain my constraints, and how I’d approach it. Primary plan is that someone can say – “just use X”. If that fails, I can still build it.

Problem definition

We have multiple WordPress installations with overlapping authors. They create blog posts, that are shared to Facebook and Twitter. Each post can include multiple embeds, that they produce – Sound Cloud, YouTube and similar. For each blog, we can also lookup into Google Analytics API and get stats on sessions, page views and time on site.

There are two primary limitations of these external data sources. Firstly, we’re rate limited – so we can only query them about once a day – per post URL. Secondly, we mostly get aggregated data.

We would query these external API’s about once a day. The only limitation we have is that we get aggregate/sum data from them. Facebook only gives us total number of likes, so we need to make subtract previous value. This way we get number of likes in that day.


Having all the information in one place, it would allow us a couple of things:

  • Weekly reports for authors – sending them encouragements on how their stories did
  • Information for content editors, what got most attention that week
  • Identify old content that suddenly got interest
  • Get information on success of embedded content (Sound Cloud, YouTube)
  • Develop customised indicators – authors with most viewed YouTube videos

Potential Solution?

When researching this topic, there is a software stack that almost fits. It’s LogStash with Kibana. LogStash provides data storage and logging capabilities. Kibana support display of data in many different ways.

The other approach would be to just code it any web framework. But it seems like a huge duplication of work.

Technical Questions

Would ELK stack work? Can LogStash provide input filter that will automatically normalise data for me? It is the right technology stack at all?

Is there anything that solves this in a much better way?

Content Questions

Is it worth building this at all? Is it a good idea to attach numbers to (journalists) work? Did I miss any questions that would be worth exploring?

Would you use such a service?

Jeff Kubina -

How to Super Charge your WordPress with Microservices

Confession: I’m amazed at the authoring experience that WordPress provides. Users are productive from the first hour and UI doesn’t get in their way. The story is similar for developers, if you stay inside the world of theme development. Try to do anymore complex and with tests, and it gets complicated. That is where (micro)service oriented architecture can help us.

At the Open Education Consortium, we use a mix of all the different approaches.

1. Let the WordPress call external API’s


At OEC, we provide functionality of Course search. While I could build it inside WordPress, it wouldn’t be optimal. I’ve developed it in Django with REST Framework. We get API Documentation for free and our Main WordPress site is using the same calls as everyone else.

To call an external API, you’ll need to extend template_redirect, init,
and query_vars actions and filters.

This way, you can format output inside your WordPress theme.

2. Let the Javascript call external API’s


This is not strictly WordPress, but it solves the other half of the problems you might have. If you don’t need to have output visible to Search Engines, you can render it with JavaScript. In one example, we’re showing a map of where our members are. We have a separate portal, where members can edit their contact information.

On WordPress side, Leaflet library calls the GeoJSON endpoint and displays it on the map. The data is always up to date and we’re using the best tool for the job.
This portal then exposes GeoJSON API, that Leaflet then displays.

3. Embed your WordPress output


For our Directory feature, I needed a flexible membership system. I ended writing it in Django with Solr. Django provides powerful form editing, that I didn’t want to replicate inside WordPress.

What I ended doing, is that I exposed API from WordPress with header and footer HTML. That way Django can just include 3rd party content. It also simplifies keeping the themes in sync.

I could do it using iframes, but then I would have problems with urls and the size of iframe content.

There is also a possibility for a future upgrade. Because we’re running on the same domain, we can read cookies from WordPress. This would allow us to check if user is logged into WP Dashboard and elevate their privilages inside Django app.


Modern Web applications are moving away from monolithic, one size fits all, solutions. While it’s common to see such infrastructure in the backend, it’s time that we start embracing it also on user facing sites. I wish some of the infrastructure inside WordPress, would make it easier, but I guess that’s an opportunity for a new library.


How to approach learning new Framework and not get overwhelmed

It’s that time of year where everything old is new again. JavaScript is the hottest kid on the block and it is time to update my approach to writing complex Web Applications. Django and WordPress are fine, but they are safe choices that do most of the computation on the server. What I want to learn is, if it’s easier to make Single Page Applications.

After I realized last year that Angular 1, does not work for me – I decided to give Ember.js a try. Their web site resonated with me. It tells a story of community driven framework. It felt like Django, but with JavaScript. It’s also a huge framework that felt overwhelming the first I tried to follow their official tutorial. It also does not help that they are in a middle big transition to a major 2.x release.

After not making much progress in first two days, I have decided to change my approach. I opted for a complete submersion into Ember.js community.

There are several steps and mistakes I made along the way:

  • First mistake was trying to build a new app, while learning fundamentals. Too many new things and wrong assumptions on my part.
  • I stopped reading about fundamentals from tutorials on blogs. They’re just too short for someone without prior experience to understand what’s going on.
  • I bought a book – (Ember Cli 101) and forced myself to do all the examples in book. By typing them out – no copy/pasting. As Kathy Sierra tells us, we learn best when we write good examples of code.
  • Writing the code (and making mistakes) helped me learn ecosystem. It’s also a good practice in how to use build-in debugging tools, what do coding errors look like and how to fix them.
  • I started listening to podcasts with Core Team members. They provide a general overview of ideas that are usually skipped at technical talks.
  • I started listening to talks given at different (Ember) conferences in the last year. It helped me understand the terminology and the technical challenges that community is facing. They’re also great source of inspiration for the kind of apps, that people are building.
  • I started lurking on official IRC channel. It turns out, that if you read Q/A that goes in there, you’ll learn answers for problems you don’t have yet. That way it’s easier to identify later.
  • I’ve started to follow the discussion forums. It’s a good way to see longer discussions on common topics.
  • I’m starting to read different bug reports and RFC’s in Github.

All these activities are happening in parallel. After a week, I now know how to read the documentation and how to solve issues. I also understand what to watch out for and rough roadmap for the framework. I have yet to write my first app from scratch, but now I have example app that I can borrow code from.

To make it easier for other developers that are coming to Ember.js ecosystem, I’ve started documenting my journey as I Learn Ember.js.

So that was first 30 hours of deliberate practice with Ember.js. Several hundred to go.