It’s interesting to see Google really pushing AMP (Accelerated Mobile Pages) and featuring sites that are AMP-ready more prominently in its mobile search results.

What’s AMP? Good question. It’s one I’m going to let my friend and colleague Jen Lombardi, owner of Kiwi Creative, explain, as she did in this blog post for the EdUI conference. She says:

With faster cellular data networks and increased access to Wi-Fi, people have come to expect that websites will load quickly and be easy to explore. But what if pages didn’t just load fast…but instantaneously? That was the goal of a group of publishers and technology companies that started the open source initiative named The AMP (Accelerated Mobile Pages) Project.

Introduced by Google on February 24, 2016, AMP pages now load 85% faster than standard mobile web pages…and this speed matters. According to one study, mobile pages that load one second faster experience up to a 27% increase in conversion rate.

Google says this:

The Accelerated Mobile Pages (AMP) Project is an open source initiative that embodies the vision that publishers can create mobile optimized content once and have it load instantly everywhere.

It’s interesting to watch Google reach into this space. Many of our sites today are responsive, but I find that even when responsive, the sites are huge, often unoptimized messes. This is especially prevalent in WordPress, where each plugin adds its own javascript and CSS files, and it doesn’t take long for a simple one page website to be well over 1MB in size. That’s crazy, especially on mobile.

AMP is forcing developers to reconsider the information they’re presenting, but the reward is more visibility in Google.

While AMP pages are getting pushed big time by Google, implementing this new technology can be tricky. For example, all your CSS must be inlined and not in external files. One more thing – that CSS has to be less than 50k. Search Engine Land has a deep dive into how to create these pages.

Want to see an AMP page in action? Here’s a post I did about Instagram a few months ago, but in AMP format. Have a look not only at the design but at the code inside it. You’ll get a taste for how much you have to shift, style wise, from external files into the actual HTML file.

As this site is created in WordPress, I turned to an AMP plugin created by Automattic.

Spoilers: there’s no setup or config for this. You install it, turn it on, and that’s it. It does all the work in creating the correct template, inline CSS, and body copy in all the ways Google wants it to be. My pages are also passing the AMP Validator tests. Yay.

AMP validation results for this site

This plugin also adds a meta tag to your regular WordPress theme, again with no added work on  your part, alerting Google that an AMP version of that page exists. It looks like this:

<link rel="amphtml" href="https://highedwebtech.com/2016/06/07/instagram-breaketh-their-api/amp/" />

That’s enough for Google to know there’s and AMP version and present it, if necessary, to site visitors via search.

Now, if you’re like me, you’re mind is traveling down the rabbit hole of all sorts of web development issues – issues like SEO, analytics, design, and more.

Read Jen’s post above as she covers SEO and design nicely, but AMP does allow developers to do analytics, ecommerce, and even advertising. This post from Google talks about how to integrate Google Analytics into AMP pages. If you use Jetpack and WordPress stats, this is another thing that the AMP plugin sets up automatically for you.

If you use WordPress, you should try this plugin. If you don’t use WordPress, the process to implement AMP can be more difficult and time-consuming, but if you rely heavily on Google, the reward may be worth the effort.

If you’re attending this year’s UBTech conference, and you’re using or are looking into using WordPress at your institution, I highly recommend you come to our WordPress SIG, held Monday morning before the conference officially opens.

This is the 3rd year we’ve done this SIG, and it’s been great to share our experiences being WordPress campuses, and it’s been really cool to see what other schools are doing, the challenges they face and to answer questions from people who are new or considering WordPress.

In particular this year, we’ll talk about the state of WordPress, and look at the recent increase of security issues WordPress faces, what it means to us as administrators and what it means for our campus users.

Here’s a bit more about our session:

It can be argued that WordPress is now a “mature” software platform. There is a robust ecosystem of developers, users, and service providers who develop many different types of websites, services and resources for and in WordPress. In fact, nearly 20 percent of websites today run on WordPress, including many higher education websites.

In this, the third UBTech WordPress SIG, Mike Richwalsky and Curtiss Grymala will share the state of WordPress today and how it’s being used for many different uses in higher ed.

The highlight of this meeting is its interactive nature – if you launched a new site in WordPress, you can share it, your successes and challenges. If you’re thinking about starting a project using WordPress, this SIG is an opportunity to ask questions from other participants and the facilitators, who have used WordPress for many years. Please come ready to share sites, ideas and questions!

I really look forward to this SIG, as it’s a low-stress, low-key way to share, learn and ask questions. Learn more about our session here.

When using WordPress, I often find myself needed to query out posts or other information that isn’t easily available courtesy of one of WordPress’ built-in functions. While it’s a normal thing to do, it can come with a cost: performance.

Every time a query is written to pull out specific data from WordPress, it adds another query to MySQL which adds time and performance. Singularly, it’s not a huge cost, but if your site has any decent level of traffic, it can add up.

Screen Shot 2013-12-09 at 10.56.01 AMCase in point: we recently relaunched our internal campus news site as a responsive site.

Every day, we post news stories for various audiences and some of these stories are for events happening today, which is information we wanted to feature for our readers.

We have a custom field in our WordPress backend that allows us to note the day of an event, so even if the story is posted a month ago, on the day of the event we can query it and display it for the user.

That query is pretty simple. It looks like this:


$args = array(
 'numberposts' => -1,
 'offset' => 0,
 'orderby' => 'post_date',
 'order' => 'DESC',
 'post_type' => 'post',
 'post_status' => 'publish',
 'year' => $current_year,
 'meta_key' => 'date',
 'meta_value' => $today,
 );

$go = get_posts($args);

With over 3,500 posts in this site, that’s an expensive query. You’ll notice we help narrow that query down a bit by only having WordPress look for posts in the current calendar year. No sense in looking at 2011’s posts for an event in 2013. Even with that reduction, there’s still several hundred posts to sort through.

There are a few ways to reduce the load that query creates. The best way is to cache the results of the query, which will allow us to serve that faster from memory/database then having to make a whole database call with all sorts of parameters.

One way is to use WordPress’ built-in Transients API. It’s a fairly straight-forward system to set, fetch and delete data inside WordPress. This is perfect for things like queries and other rendered data that you’re going to need often.

Setting up and fetching transients is easy.


$transientname = 'hewt';
$cachetime = 60;

if(false === ($go = get_transient($transientname))){
	$go = get_posts($args);
	set_transient($transName,$go,60*$cachetime);
}

That code, in a nutshell, is first checking to see if the transient variable exists and can be fetched. If it can, great, move on. If it can’t or doesn’t exist, run the WordPress query and save the results in the Transient API for an hour. We can start using the $go variable as needed after that.

The trick about WordPress transients is they are stored in the database. But Mike, didn’t you say that having to query the database every time is a performance hit? Yes, but…

Transients are inherently sped up by caching plugins, where normal Options are not. A memcached plugin, for example, would make WordPress store transient values in fast memory instead of in the database. For this reason, transients should be used to store any data that is expected to expire, or which can expire at any time. Transients should also never be assumed to be in the database, since they may not be stored there at all.

The other way to do some as-needed caching is to use a PHP caching solution, such as APC. I’ve talked about caching WordPress queries using APC in this post.

You’d write your PHP code to save to APC the same way.


$transientname = 'hewt';

if($go = apc_fetch($transientname)){}else{
    $go = get_posts($args);
    apc_add($transientname,$go,3600);
}

Same idea here. We’re checking APC to see if the variable is available. If it is, great, move on. If it’s not, run the WordPress query and save the results for the next time the page is loaded.

What’s neat about APC is that instead of writing the values to MySQL, APC stores them in memory, which means its much faster to read data than having to query the disk.

The challenge with APC is that it isn’t installed by default in most LAMP setups. You have to compile it in, and set some initial values. If you’re running WordPress on a shared server, chances are APC isn’t available.

Where I’ve run into challenges with the Transient API is when I need to delete the cache. There isn’t a button to just clear it out. You can do it programmatically using built-in functions, such as

delete_transient( $transientname );

The other catch, WordPress doesn’t delete old cached transients unless you ask for them by name. WPEngine wrote this about Transients API:

But with the WordPress Transients, you get different but still very undesirable behavior. Because the values are written to the database, not a fixed-sized block of RAM, they all stick around. Which means even with the heavily-loaded site, you still have your session data. Awesome!

Or so you thought. Because what isn’t said in the Transient API is what happens when you use unique keys like sessions. And what happens in with the built-in method is that the options table fills up indefinitely! Because: WordPress’s “old data clean up” only operates when you request the key (as we covered earlier). If you just leave the key, it’s left in the options table, forever. There’s no separate process that cleans these up

Stu Miller had this method for cleaning out old transients:

function purge_transients($older_than = '7 days', $safemode = true) {

Clearing out APC can be done in a few ways. You can delete a particular key:

apc_delete($transientname);

APC comes with a web app where you can view data about the cache, status of keys and more. You can log in to the backend and delete a variable there.

You can also do it with PHP outside WordPress by using something like this:

apc_clear_cache();
apc_clear_cache('user');
apc_clear_cache('opcode');

In review, WordPress transients are easy to use, built into every WordPress installation and don’t require additional plugins. Be aware though, that deleting expired and old values can be tricky and require additonal code. APC is fast, PHP-based and easy to access, but may not be available on all installations or server environments.