THE PENDING DRAFT

Website Obesity

January 4, 2016

There is only one honest measure of web performance: the time from when you click a link to when you’ve finished skipping the last ad.

Everything else is bullshit.

Amen!

This is probably one of the best and most entertaining articles about web performance i’ve read lately. Go read it, and don’t forget to make performance a priority in 2016!

The Website Obesity Crisis

Eric Meyer on Content/Ad Blocking

September 22, 2015

Eric Meyer’s primer on Content Blocking is spot-on.

The ads that are at risk now are the ones delivered via bloated, badly managed, security-risk mechanisms.  In other words: what’s at risk here is terrible web development.

Granted, the development of these ads was so terrible that it made the entire mobile web ecosystem appear far more broken that it actually is, and prompted multiple attempts to rein it in.  Now we have content blockers, which are basically the nuclear option: if you aren’t going to even attempt to respect your customers, they’re happy to torch your entire infrastructure.

I used an Ad Blocker on desktop for a long time now, but i also have many sites set to “do not block”. These are basically all sites that respect me and treat me as a human being. And if you are a publisher, ad-provider or anyone else working in this industry and don’t respect your customers, i couldn’t care less if you’re going downhill from here and i would suggest you to go back to the drawing board as fast as you can.

Or, as Kontra eloquently phrased it on Twitter:

Eric Meyer – Content Blocking Primer

Gabor Lenard on what he learned during two weeks of painfully slow internet

July 10, 2015

When we went to Hungary during the Christmas period last year I bought a 1GB data plan on a prepaid card. However, soon after I went online with my laptop the entire data allowance was used up. Strangely, I wasn’t able to add another data package. Instead, T-Mobile limited my internet access to 32kbps till the end of the month.

Since there was no easy way to fix it and I had nothing critical to do I decided to embrace the situation as an opportunity to understand how it feels to be on a slow network most of the time. I had already started reading the book Responsible Responsive Design at that time anyway so I was curious.

To be on a slow connection for a longer period of time can really be an eye opening thing if you work on the web. As Gabor mentions in his post it’s not only that pages load slowly, but some just won’t load at all.

I experienced the exact same thing in the last weeks when we were on vacation in Spain after WordCamp Europe. I had a 200 MB mobile data package, and at our AirBnB apartment we had a very slow WiFi. So i had to choose between a moody and sluggish WiFi or the tiny bit faster but crazy expensive mobile connection.

It was frustrating, to say the least. But if you work on the web, you should force yourself into this situation while developing. Gabor recommends to turn on device mode in Chrome and simulate a slow connection right from the beginning, because as he puts it:

I need to feel the pain as soon as possible so that I immediately notice the changes that are bad for performance.

This should be an exercise we should do on a regular basis and – even better – we should integrate them into our project workflows. Imagine if everyone involved, from your client, project manager, boss to the content creators would have experienced a few weeks of bad connection first hand.

I’m sure performance wouldn’t be an afterthought anymore.

Three takeaways for web developers after two weeks of painfully slow internet

Improving Code Quality

July 9, 2015

If you’re building things with WordPress, it’s important to deliver quality code. Especially if it’s going to be released to the public or used by a client. There’s a good post on the WPMUDEV Blog covering many aspects from HTML/CSS, JavaScript or PHP to the WordPress Coding Standards or Accessibility.

It’s a great starting point if you are unsure how to improve your code but also a good reminder for experienced developers.

Stop Cowboy Coding: 10 Tips for Improving the Quality of Your WordPress Themes and Plugins

CSS-Tricks: Performance Tools

June 8, 2015

A comprehensive list of tools and WebApps related to Web Site Performance and Optimization, catalogued by CSS-Tricks.

Weekend roundup time! From the multitude of Grunt and Gulp plugins to web apps that can help us visualize our websites with data, learning all the ins and outs of performance tooling is tough. I thought it might be useful to catalogue as many tools out there as I could find.

CSS-Tricks – Performance Tools

WordPress Plugin Profiler

April 29, 2015

plugin-profiler

Contrary to popular belief, adding plugins to your WordPress site is not necessarily harmful to the performance of your page. One “bad” plugin alone can potentially bring your site down while the site can run smooth with a 100 installed plugins. It all depends on which plugins you install and how they are built.

Luckily, there are tools like this little plugin i just found called Plugin Profiler by Danny van Kooten. It measures the loading time with all plugins deactivated, all activated and both in combination with a plugin you specifically choose.

The only thing you need to do for it to work properly is manually add a file in your mu-plugins folder and after that it’s really easy to use. Choose which plugin you want to check and how many test-runs you’d like and let it do it’s work. Kinda like magic.

I don’t know how accurate the results are and what exactly is going on under the hood to measure them, but i’m sure it’s a good indicator if something is going wrong with a plugin.

What do you use to check Plugin Performance before installing/activating?

WordPress Plugin Profiler

Optimizing a Custom Query in WordPress

April 14, 2015

With the WP_Query class WordPress provides a powerful tool to query things from the database. But as with most powerful things, you can also mess things up quite a bit if you’re not careful enough.

With great power comes great responsibility.

(Voltair, Yoda, Uncle Ben in Spiderman or whoever said it first)

Let me give you an example of a query we needed in a project and how we implemented it.

The Goal

We want to get the IDs of all Attachments (images in this case), that are attached to any post of a particular Custom Post Type.

The Wrong Way

The good thing about WordPress is that you can find a snippet for pretty much anything with a simple Google Search. The bad thing about WordPress is that you can find a snippet for pretty much anything with a simple Google Search. Often it’s as easy as throwing a snippet into your plugin or functions.php in your theme and it just magically works.

Here’s the first “solution” i found somewhere on StackOverflow:

// Query for all posts of post_type 'post-type-name'
$cpt_query = new WP_Query(
  array(
    'post_type' => 'post-type-name',
    'posts_per_page' => -1 // get everything
  )
);

// Create an empty array for our attachment ids
$attachment_ids = array();

// Run a Loop through our CPT-Query
if( $cpt_query->have_posts() ){
  while( $cpt_query->have_posts() ){
    $cpt_query->the_post();

    // Inside the Loop, get all attachments which are children of this post
    $attachments = get_children(
      array(
        'post_parent' => get_the_ID(),
        'post_type' => 'attachment'
      )
    );

    // Add the attachment id to our array
    foreach ( $attachments as $attachment ) {
      $attachment_id = strval( $attachment->ID );
      array_push( $attachment_ids, $attachment_id );
    }
  }
  wp_reset_postdata();
}

 

While this worked perfectly as it should, it had a pretty expensive overhead. Right now we query for all posts of that Post Type, then load all information about that post, loop through every single one of them and inside that Loop we query again for all attachments, load all data and again loop through every single one of them to get the ids.

We add a lot of queries post per post while looping through them, not good! This might not be a problem when you only have some posts with a handful of attachments. But because of the way this query was built the queries would increment for every post which would easily lead to thousands of queries when more posts and attachments are added.

So, what can we do to fix this? Let’s see.

First of all, it’s important to realize that you have a problem, preferably before anyone else does. I use the Query Monitor Plugin during development to display the amount of queries (among other useful information) in the admin bar. On top of that, it’s a good idea to test your plugin/theme not only on a blank installation but also to create, delete, add, move as much as you can to check if there are issues you won’t notice otherwise.

‘fields’ => ‘ids’ to the rescue

Inside WP_Query we can define which fields we want to retrieve by adding 'fields' => '...' to the query. That way we won’t load every single piece of information about the posts we find, but only what we need: the IDs.

$cpt_query = new WP_Query(
  array(
    'post_type' => 'post-type-name',
    'posts_per_page' => -1,
    'fields' => 'ids'
  )
);

 

This will get us an array of IDs. We don’t have to loop through them anymore and can directly make a second query to get our attachments.

$attachment_query = new WP_Query(
  array(
    'post_type' => 'attachment',
    'posts_per_page' => -1,
    'post_status' => 'any', // Not sure if this is needed, but it makes sure we really get every attachment
    'post_parent__in' => $cpt_query->posts, // Look for children of the ids from our first query
    'fields' => 'ids' // Again, we only want to get the ids
  )
);

 

This second query gets all attachments that are children of (attached to) one of the posts we got in the first query. The result of $attachment_query->posts will again be an array of IDs, this time for the attachments.

This means instead of potentially thousands we will only ever have two queries, regardless of the amount of posts and attachments.

The Solution

To sum up here’s the complete code we use today in our plugin (we added some more parameters and checks, but it’s technically identical).

function pdr_get_attachments_from_cpt( $query ) {
  $cpt_query = new WP_Query(
    array(
      'post_type' => 'post-type-name',
      'posts_per_page' => -1,
      'fields' => 'ids'
    )
  );

  $attachment_query = new WP_Query(
    array(
      'post_type' => 'attachment',
      'posts_per_page' => -1,
      'post_status' => 'any', // Not sure if this is needed, but it makes sure we really get every attachment
      'post_parent__in' => $cpt_query->posts, // Get children of the ids from our first query
      'fields' => 'ids' // Again, we only want to get the ids
    )
  );
}

 

In our case we hooked that function to the pre_get_posts filter to exclude those attachments from all queries, I left that part out for the sake of simplicity. Let me know if you want to see the complete code.

This is exactly the kind of thing I meant when I wrote about taking things apart as a regular learning habit. It didn’t took a whole lot of time to figure out what was going wrong with the original function, I fixed a piece of code which would have gotten us into trouble later on and I learned a few things about how queries in WordPress work.

What did you learn today?