You may be wondering “Why would I want to do this?” By default, like most CMS’s, Statamic generates images using software called “GD” (Graphics Draw). For most cases, this will probably be an OK default, but from my experience using ImageMagick as alternative image processing software generates superior images—especially with larger, more noticeable images.

Installing ImageMagick Locally

Even if you're comfortable getting ImageMagick installed on your production server, installing locally will likely be a different process.

1. Open yoursite/config/statamic/assets.php

2. Search for driver and change the value to imagick

3. Make sure you have homebrew installed. To check if you have homebrew installed, you can run brew -v. If Terminal tells you the version number, then you're good to go. Otherwise, download homebrew from https://brew.sh/

4. Run brew install imagemagick. Check for any errors. At this point in the video, I was prompted to run a command to remove some leftover files.

5. Run brew install pkg-config

6. When prompted with Please provide the prefix of Imagemagick installation [autodetect] : just hit enter.

7. Once complete try running valet restart and refreshing your site. You'll know ImageMagick is successfully installed if 1) it generates Statamic Glide images correctly, and 2) if you go to yoursite/cp/utilities/phpinfo you should a new full section with the headline imagick, with the first row of the section detailing the imagick module version

Fixing Errors

In my experience development environment things seldom “just work”—there's either something you forgot to set or some error you need to deal with. While ImageMagick usually runs smoothly you'll see in the video I ran into an error. The good news is you can usually Google search-engine your way out of an error when it comes to popular software—and luckily ImageMagick is relatively popular.

Before you start searching for fixes it may be worth clearing the cache first with:

php please glide:clear

This didn't help the error I ran into—which in this case was:

warning: mkdir(): File exists in System.php on line 294

I eventually found an article by Patrique Ouimet, which detailed a fix—thank you, Patrique! https://patriqueouimet.ca/tip/installing-php-and-pecl-extensions-on-macos

In this case, you needed to run:

pecl config-get ext_dir | pbcopy

then type:

mkdir -p

followed by pressing cmd + v to paste the value you just copied to your clipboard.

Once this command has been run, and the directory has been created, try running pecl install imagick again and maybe run php please glide:clear to be on the safe side. Finally valet restart and go back to your Utilities > PHP Info in your control panel. If everything's worked out, you should now see an Imagick section here.

What is SEO?

SEO stands for 'Search Engine Optimisation’, and it involves trying to optimise the content on your website so that search engines may understand it better. Hopefully, this means you can rank higher in Search Engine Results Pages (SERP).

Where Is Google in All This?

It isn't easy to talk about SEO without mentioning Google since they are the most widely used search engine by a long way. There are others of course—such as Yahoo, Bing, and Duck Duck Go, but for simplicity, in the video, I'll use Google interchangeably with search engine results since this is what people are used to.

Understanding Search Results

Search results are usually split into two different sections.

The first section is made up of paid-for advertisements, and are labelled as “sponsored” results. Sponsored search results are artificially boosted listings. To appear in this position companies need to pay search engines.

The next section is made up of results search engines think might be relevant. These are known as “Organic results”. They're called organic because they are not artificially boosted. Search engines think they may be useful to you purely based on their website content.

A company's strategy may appear in both of these sections but aiming for a good organic rank is always best because it's sustainable—and it's virtually free apart from your time and effort.

How Do Results Work?

Each result is made up of a title and a description. You can control both of these things, which is really powerful for persuading people to click through to your website.

You can kind of cheat and see what your title will be by looking at the title of a browser tab. On the other hand, if you don't explicitly set it, your listed description is naturally taken from the first few words on the page. This is OK sometimes, but it's undesirable most of the time since you want to curate more of a quick alternative ‘elevator pitch’ for people scanning search results.

How to Set Your Page Title and Meta Description

Unfortunately, this totally differs depending on which CMS (Content Management System) you're using. For example, if you're using WordPress, then you may be able to set this within the Yoast SEO plugin settings, or if you're using a more bespoke CMS, I suggest you try and find some kind of “Page Details” section where it might have the option to set Title and Meta Description.

When writing a Meta Description bear in mind, this should be a summary of the content on the page—it may even be very similar to the first paragraph, but tailored slightly.

Once you've updated your Meta Description, you may need to be patient before search engines update this in their listings. Search engines deploy “bots” to “craw” the internet, and it may take a few days to understand that your content has changed.

If you're a confident computer user, it's possible to see the Meta Description broadcasted on your site by looking under the hood of your web page. It may differ slightly depending on your browser, but with Chrome, for example, you can right-click anywhere on the page and select “View Page Source”. A new tab will open up, showing the page's underlying code. Here you need to find something called <meta name="description">. The easiest way to find this is by using the ‘find’ tool in your browser. You can typically use this by pressing cmd + f on macOS or ctrl + f on Windows. This will open up a small find dialogue (it may appear in the corner of the screen. If you type ‘description’, it will highlight every instance of this word on the page.

What Does Google Want From Your Website?

The reason Google is so popular is because it tends to give people the best search results. It'll serve you well to remember that Google's number one goal is to find the best content/give people what they want, so it can continue to be the most popular search engine.

For this reason, the best way to climb higher in search results is to improve the quality of your content. Search engines continuously ‘crawl’ your website to understand what kind of content you have. Every search engine will have its own algorithm to try and understand the value of your content. This algorithm is constantly being tweaked, and no one knows exactly what it is—it's each search engines ‘secret sauce’. However, they do publish tips and articles to help you understand what they're looking for.

Invest in Good quality content

The most frequent recommendation from search engines is to put out good quality content as often as is relevant to your website.

I recommend you put time aside—maybe every week—to write a single blog post. Most SEO specialists will tell you to write a blog because they add in-depth miscellaneous content to your website without bloating your site structure. Pick things you enjoy writing about or topics where you have the expertise, so it's easy for you to develop the habit. If you're unsure about a topic, maybe ask a local group what they'd like to know—engage with your audience and tell a story.

I recommend writing long-form articles that are at least 300 words on a particular topic. A really great example of this is a site in the web industry called CSS-Tricks. Content posted on this site is regular and deep, and because search engines see this, the site is recognised as a source of authority. If you search anything to do with websites or code, you'll find CSS-Tricks at the top of results.

It's important not to attempt to ‘trick’ search engines here because it could backfire long-term. When search engines were young, some SEO “experts” would push businesses to use underhand tactics to fool search engines short-term. This may have worked in the past, but since search engines’ algorithms are ever-evolving, it may no longer work, and you may even get penalised if an underhand tactic is recognised.

• Be specific and be original—the more you target a post or page towards a specific topic, the more search engines will understand the page you're writing about.

• Make deep pages—I've seen many clients tempted to make “single-page” websites simply because they're trendy. In terms of SEO, this is generally a bad idea. The more varying content you have on a single page, the more you'll confuse search engines. Conversely, deep isolated pages on a single topic will help search engines recognise it as a source of helpful content on a specific topic.

• Structure your content—in most content management systems; you can use different heading ‘levels’ to describe the content structure to search engines. For example, a Heading Level 1 is very important; a Heading Level 6 is the least important. You can do other things to convey semantic meaning to search engines, for example, using 'bold' (technically known as ‘strong’), ‘italic’. Using different formatting tells search engines that certain words have a weight or emphasis.

Improving Your Rankings Through Schema

Improving your content's meaning through schema is useful if you have a specific type of content on your website. A good example might be a recipe or a review.

Using schema helps search engines understand you're talking about specific things, such as cooking duration, instructions, or user reviews. To do this, you need to format the output in a particular way, using code that is not visible to users on the page. Because of this, you'll likely need a web developer to help you if you want to implement this—either that or you may find a specific website “theme” that has functionality geared towards what you do, e.g. a recipe theme that has a built-in schema.

You can use Google's documentation to get started or read up on the official Schema docs.

Advantages of using Schema

1. Search engines will typically place results that make good use of schema at the top of the page in a neat format, e.g. recipe cards or film reviews.

2. Implementing schema essentially means you're giving search engines—and therefore, people—richer information about your content.

Conclusion

Although you can do several technical things to improve your website's presence on search engines, the most effective thing you can do is to write helpful, in-depth content, as often as you can.

About Caching

Caching files is typically a good thing since it encourages the browser to reuse assets that have already been seen and cached to a temporary memory file.

A general best practice is to tell the browser to cache assets for a long time by setting header expires. Doing this means viewers do not need to re-download assets on repeat visits.

Problems with Caching

Caching can be a problem when you update your assets but the browser continues to serve the old ones because of the "header expires" you've set.

Caching Solutions

The solution to this caching problem is known as "cache-breaking", or sometimes "cache-busting". Cachebreaking involves changing the filename so the browser thinks there is a new asset to download.

For example, instead of trying to load style.min.css, we try to load style.min.1487201825.css. The browser thinks this is a brand new file, so it effectively resets the cache.

The typical way to deal with Cachebreaking is through an automated build process that changes the file names for you. You might do this through Grunt or Gulp for example.

If you're using a CMS such as Perch, however, since Perch runs on PHP which is dynamic, we can create our own caching solution using some PHP functions and rewrite rules.

Dynamic Cachebreaking in Perch

Part 1 — Serving a Filename Based on its Modified Time

The first thing we want to do is understand when our CSS or JS file was last modified. By understanding this we can prevent needlessly resetting/breaking the cache. We can get the last modified time by using the PHP filemtime function ("file modified time").

So in the PHP file which you're using to serve your assets (e.g. head.php) you would add a variable that gets the "last modified" time of a particular asset.

Get the last modified time of your CSS

The example below would get the last modified time of our minified CSS file. You should change this path to whatever's relevant for your particular setup.

$CSSversion = filemtime($SERVER['DOCUMENTROOT'].'/assets/css/style.min.css');

This variable would output a unique "last modified" time string such as 1487201825

We then want to call that variable when we call our asset. Here is an example:

<link rel="stylesheet" href="/assets/css/style.min.<?php echo $CSSversion ?>.css" type="text/css">

This would translate to:

<link rel="stylesheet" href="/assets/css/style.min.1487201825.css" type="text/css">

Get the last modified time of your JS

The example below would get the last modified time of our minified JS file. You should change this path to whatever's relevant for your particular setup.

$JSversion = filemtime($SERVER['DOCUMENTROOT'].'/assets/js/script.min.js');

This variable would output a unique "last modified" time string such as 1487201825.

We then want to call that variable when we call our asset. Here is an example:

<script src="/assets/js/script.min.<?php echo $JSversion ?>.js"></script>

This would translate to:

<script src="/assets/js/script.min.1487201825.js"></script>

In the above examples I'm covering both our CSS and JS assets but you can keep repeating the steps for different assets that you'd like to monitor.

So this takes care of breaking the cache whenever certain files have changed.

Part 2 — Rewriting Requests to Point to the Original Minified File

While the cache would effectively be reset/broken at this point, the problem is we don't actually have a file called style.min.1487201825.css! Instead, our file is just called style.min.css.

This is where you would ideally have a build process that would rename the file for you.

With an htaccess trick, we don't need that though. If you're running your site on an Apache server, the htaccess file is what's used to control any redirect or rewrite rules.

Your htaccess file is normally a "hidden" file at the root of your site, so make sure you have hidden files shown. Alternatively, if you have added a directory to a code editor like Sublime Text it will show hidden files for you.

In your htaccess file you'll need something like this:

<IfModule mod_rewrite.c>

    RewriteEngine on

    Options +FollowSymlinks

    # Cache Breaking

    # ---------------

    RewriteRule (assets/)([^.]*).min.+.(css|js)$ $1$2.min.$3

</IfModule>

As before, you should change the path to whatever's relevant for your particular setup. It's important we specify some of the paths so that we "ringfence" the rule. This prevents accidentally rewriting a plugin's CSS file or another directory in Perch.

An important note is that if you're using Perch Runway you'll need the cache breaking rules to appear above some of Runway's rules, so you might have something like this:

<IfModule mod_rewrite.c>
    RewriteEngine on
    Options +FollowSymlinks

    # Cache Breaking
    # ---------------
    RewriteRule (assets/)([^.]*).min.+.(css|js)$ $1$2.min.$3

    # Perch Runway <-- needs to come after Cache Breaking
    # --------------
    RewriteCond %{REQUEST_URI} !^/login
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule .* /login/core/runway/start.php [L]
</IfModule>

So what is our rule doing? It's looking for any path that starts with assets/ and ends with min.css or min.js. Htaccess is then rewriting that path, removing any middle ".something"'s, which means the "file modified time" number we inserted is written out.

If you inspect your page, we'll still see our style.min.1487201825.css example is showing but behind the scenes, it's been rewritten to style.min.css

You can play with this rule on Regexr (note that I've had to wrap square brackets around forward slashes on Regexr, but you shouldn't need these in your htaccess).

Notes

1. You could skip step 2 if you want to cache break using a query string e.g. <link rel="stylesheet" href="/assets/css/style.min.css?v=1487201825" type="text/css">, however, this does not seem as favourable as renaming the file because some delivery services do not automatically treat files with a query string as a new asset

2. This is a great article for further reading on automatic versioning

Credits

Thanks to Martin Underhill for his suggestion to use PHP to cache-bust, Duncan Revell for his Regex help, and Caden Peters for his suggestion to rewrite in htaccess rather than use a query string.

At first, I was pretty happy with the way RWD solved the problem layout on different sized devices. However, with the accelerated growth of mobile devices + high-resolution screens we've got another problem on our hands—serving whopping high-resolution images by default to all devices. Now if we're serving the images via CSS, this isn't a problem; we use our default stylesheet to serve standard resolution images to mobile devices, and then we might decide to swap the image out for a larger version on bigger screens or higher resolution devices, using Media Queries.

The problem really arrives when we're looking to serve images within our markup. For example, WordPress serves images dynamically, depending on which page you're visiting. Because we can't use CSS Media Queries to control what our WordPress database serves us, we need to think carefully how we manage our content. Thinking of high-resolution devices down the line (iPad 3?, and then what next, Apple? Retina Desktops?).

We need to start the ball rolling so that all of a sudden our sites don't look awful when a visitor hits them on a high-resolution screen.

I admit, I started advising clients that any images they upload via a CMS need to be twice as large as they actually appear, so that in future when the image is exposed to high-resolution device and scaled to 100%, it still looks crisp. Now say we're dealing with a large image at its default size (maybe 800px wide). This means I have to tell the client they need to upload a 1600px version, for when someone lands on their site with an iPad 3 (or whatever the Android equivalent is, Ice cream Sundae Sandwich with a 99 Flake?). All of a sudden any advantage we're gaining with Media Queries has been blasted away by these data-hungry high-resolution images.

So enough complaining, what's the solution? Well, in short, there's not a solution yet. It's still a work in progress; in fact a new discussion was kicked off the other day here. Reading Mathew Marquis' post, it really is depressing to think that it's probably going to be a while before this gets any traction. Further more, I don't know how the proposed solutions would integrate into a Content Management System like WordPress. However, do not fear, Matt Wilcox has come up with a great solution for the time being, which he calls Adaptive Images.

Bad news?

Under 'limitations' Matt points out that the solution relies on Javascript and cookies. But honestly? No big deal, it's better than doing nothing about our sticky situation. You can read more here.

Good news?

It's easy to use and it's a completely non-destructive solution. Ever want to change your approach to handling large images? Just remove the script and delete the cache file. That's it.

I was pretty upset that publishing the Build Script broke my previous workflow using Espresso's built-in FTP, and eventually had to resort to FileZilla, a self-contained FTP program, to get things working smoothly. But once you tweak it a bit, publishing your Build-Scripted WordPress theme becomes a snip!

Filezilla is a free FTP program available on Mac and Windows, you can download it here.

Here are the filter configurations I talk about in the video: