How Did I Get On This Page?

Have you ever found yourself on a site, wondering how you got there?

The typical scenario for me is when I open several links in the background from another site, like Reddit or Hacker News.

Every once in a while, one of the sites I open is outdated or was an invalid link, or I forget what the purpose was when I clicked on the link. In order to figure out what happened, I want to know what page got me there. But if the link was opened into a new tab in the background, the tab doesn’t have a history.

This bookmarklet solves the problem. It opens a new window to the referrer (if there is one), which is the site that referred you to the current site.

Visit referrer

To install it, drag the link to your bookmarks toolbar, then click it next time you’re lost.

Bookmarklet to Clean Cruft From URL

Bookmarking articles with long, ugly URLs filled with analytics cruft is a nuisance. I also find myself bookmarking the same article multiple times without realizing it. My bookmarking manager of choice (Linkman) will tell me if a link is already saved, but if the links are different, Linkman doesn’t know it’s the same article.

And sharing long links is annoying too. Instead of turning to a URL shortener, give this method a try.

I’ve created a URL cleaning bookmarklet that removes everything but the domain and path without having to reload the page, leaving a shorter, cleaner link.

Note: It works best on articles, and it can break some links. If the cleaned link no longer works, hit F12 to see the original URL printed in the Console.

To install the bookmarklet, drag the link below to your bookmarks toolbar:

Clean URL

To use it, click the bookmarklet on a site with a long URL and the URL will be cleaned up right before your very eyes.

Here’s an example.

Exhibit A: The original link

Exhibit B: The clean link

Both links lead to the exact same article.

Which would you rather use?

WordPress Missed Schedule Posts

I just discovered that scheduled posts on my Riddles and Brain Teasers site hadn’t been working as far back as last year. Whoops! On the bright side, today saw a flurry of additions.

It’s a little odd that WordPress can tell you it missed publishing a scheduled post, but still doesn’t publish it. It’s like a butler coming upstairs to tell you he forgot to bring you something instead of just bringing it.

I spent quite a bit of time digging in to why it wasn’t working and eventually discovered the culprit was W3 Total Cache’s database cache. Disabling it solved the problem.

But I had already started using a real cron job on the server and I chose to leave it. It means WordPress doesn’t have to check for scheduled tasks on every request, speeding up page loads a little.

To recap, if your scheduled posts aren’t publishing and you’re using W3 Total Cache, you can just disable the database cache. Or, if you want to use a real cron job (which I already do for numerous other tasks), follow the steps below.

1. Add this define to your wp-config.php file.

Anywhere will work. I added it after the DB_COLLATE define, around line 36.

define('DISABLE_WP_CRON', 'true');

2. Create a cron job

If you’re not familiar with cron, it’s a task scheduler on Linux / Unix systems. Most web hosts will have it somewhere in their control panel. If not and you have shell access, run cron directly with crontab -e and add these two lines.

# Run every hour on the hour
0 * * * * wget --quiet --output-document=/dev/null ""

This will load WordPress’ wp-cron.php file every hour.

And now you can can get back to scheduling your posts.

Friendly Neighborhood Reminder To Optimize Your Images

My daughter is a big fan of Daniel Tiger’s Neighborhood and today I was curious who the voice actor was. I found the answer on Angela’s Clues (an 11-year-old named Jake Beale). I also found some pages loading really slowly.

I clicked my Google Pagespeed bookmarklet on the projects page and it got the lowest score I’ve ever seen.

12 out of 100 on Google Pagespeed

The #1 suggestion was to optimize images, claiming the images could be reduced by a stunning 3.8 MB. Sure enough, I tried optimizing one of the files. It started at 765 KB and after PNGGauntlet finished, the image was a mere 106 KB, 14% of its former size.

And there’s even better news if you use WordPress. Instead of optimizing images manually, install the EWWW Image Optimizer and it will not only optimize images you upload, but it can also optimize all of the images you already have on your site.

Speedy delivery isn’t just for the mail. Make Mr. McFeely proud.

Go vs Node vs PHP vs HHVM and WordPress Benchmarks

I have been impressed with the performance I’m seeing with Vultr VPSes, so I decided to do an experiment to see what the maximum performance could be.

I created a simple Hello world program in Go, Node.js and PHP, then tested them with ApacheBench 2.3.

Here are the three programs I used.

Go 1.4

package main

import (

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprint(w, "Hello world from Go")

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":4000", nil)

Node 0.10.33

var http = require('http');
http.createServer(function (req, res) {
    res.writeHead(200, {'Content-Type': 'text/plain'});
    res.end('Hello World from node');
}).listen(3000, '');

PHP 5.6.6 with Opcache enabled

echo "Hello world from PHP";

These benchmarks were run on a Vultr server with 768MB of RAM and a single 3.4MHz CPU with nginx 1.6.2. To perform the benchmarks I ran the following ab command three times to warm up, then I ran three more runs and averaged the second group of three.

ab -q -n 5000 -c 25 localhost/

WordPress had WP Super Cache enabled. Without it WordPress was getting around 30 requests/second.

Without further ado, here are the results. Higher is better.

Benchmark Results

Here’s the data in tabular form

Test TypeRequests per second
WordPress (PHP)854
WordPress (HHVM)1,259

Go is the clear winner, but I was surprised to see how close HHVM was to Node. I was also impressed that with HHVM, WordPress was approaching a simple PHP script. Of course that was with the caching plugin in place.

I planned to include the results of nginx serving a static file in the chart, but it made the other results hard to distinguish at a whopping 17,791 requests/second.

Lastly, I was concerned to find that sometimes the HHVM results went into the toilet. Most of the other benchmarks were fairly stable, but HHVM would average over 3,000 on the first three runs, then drop off on the next three. In one case it hit around 700, so something was clearly wrong, but I’m not sure what. I had already fixed the nf_conntrack_max issue, but it could be something else along the same lines.

My takeaway is it’s a great time to be a web developer. Getting WordPress to hit over a thousand requests a second on a $5/month server is impressive. And it’s only getting faster!