Testing is one of my favorite parts of building a website. The in-depth, detail work involved in quality testing is something that I’m really drawn to and enjoy building tools for. When testing, content is an integral part of making sure that there are no visual bugs or ticks on the website – however, spinning up a lot of content takes time. A lot of time.
The concept is simple – you choose how many posts to spin up (or keep it random), click the “Create” button, and the plugin will create those posts, assign them to appropriate taxonomies, pull in featured images, and even create metadata if available.
You can then delete the posts you created (and only those test posts – it won’t go wild on you) by hitting the “Delete” button. Simplicity is the key here – I wanted to make the process easier and quicker and this does the trick.
The tool is currently intended as a development tool and is thus only available on Github for the time being. When it’s built out to a place to be more applicable to a general audience I might push it onto the .org repo.
I hope you enjoy this small, free tool!
Imagine your dream, perfect, developer-focussed version of WordPress. What does it look like?
— Ryan McCue ⍨ (@rmccue) March 17, 2016
Ryan McCue pushed up a great monologue/question today on what would make WordPress more enjoyable to work with from a developer perspective. I’ve had several thoughts on this topic and figured the best way to share them is with a short blog post expanding on each of them.
Function naming has evolved over the last 10 or so years, but there’s been no decided consistency which makes it particularly difficult to learn how to use which function when. I can use `get_the_title()` and `get_permalink()` out of the loop, but not `get_the_content()`? And on those functions, we have `get_the_title`, `get_the_content`, but not `get_the_permalink`? We expect people to memorize all these differences instead of fixing the core issue.
There needs to be a concerted effort to refactor a significant portion of the code in core. It’s a disorganized mess and finding anything in core can take a lot of time. It’s common for me to track down 4-5 files to find the source and code of a single set of functionality. This is a HUGE task and would take a year or more in an ideal world – the easiest way to approach it would be to rate the worst-offending files and address those on down the list. Eventually the code would be dramatically more logical.
This goes along with the point above but deserves its own section. WordPress is FULL of admin files that have functions mixed in with display code which makes it a damn sight impossible to break down the code and make intelligent
The REST API landing in core and getting fleshed out will be a huge boon to making WP more developer friendly. It breaks you out of the shackles of using the WordPress templating system, which can be very frustrating to learn the first few times through. When a JS dev can jump in and build a WP frontend quickly, WP won’t be dreaded anymore.
I’m going to start writing sister posts to talks that I give to make it easier to reference the information. This post is attached to a talk I gave last year at the Fort Collins WordPress Meetup. You can find the presentation slides here.
Performance is a crucial piece of development and content marketing. Having a site that runs quickly and doesn’t frustrate your visitors will make you money and increase conversions significantly.
On average, each 1-second delay in loading time means:
If you have a site that loads in 20 seconds, you’re losing a huge amount of your traffic and potentially advertising dollars simply because your site is inconveniently slow. This means a loss of ROI on your site. On the flip side, your ROI increases dramatically from speeding your site up.
There are few concepts that are crucial to understanding front-end performance.
You have to load resources on a web page to display anything. Images, videos, CSS, JS all have to be externally loaded onto the page for a user to have a good experience. However, if we can decrease the size of each resource that we load, the user will have a much better experience.
On the same line, if we can reduce the number of requests, the user will see more faster. At the time of writing this, HTTP/1.1 is still the de-facto technology. HTTP/1.1 can only download so many objects at once, let’s say 5 at a time. So, if you have 60 resources to download on a page the browser will download 5, and then the next 5, and then the next 5 and on and on until we’re done. Each chunk takes a while and results in a slower site because it has to wait for the previous ones.
The site we’re talking about today is Cheba Hut. This client came to us at Old Town Media wanting changes to their site but we quickly discovered that it needed a complete rebuild.
We rebuilt the site in WordPress and ended up with a significantly faster product.
Pingdom Tools gives you a great 10,000-foot overview of the issues on a site. You can quickly work down the waterfall chart and see what’s taking the longest to load and get some basic stats on the the page you’re testing.
Diving in a little deeper we have Google’s Pagespeed Insights tool. Pagespeed tests and instead of giving you data about load time, it gives solid recommendations on how to fix any identified problems and even optimizes your resources and packages them up for you.
Webpage Speed Test is the powerhouse of all these tools. It takes quite a while to process, but gives more data and analysis than any of the others. You can run multiple tests at once from multiple locations and even run some powerful scripts such as a hosts re-direct.
The first step when optimizing a site is to get rid of every resource that you possibly can. Unneeded images, JS, and CSS are the the bane of an optimizer. By removing these unnecessary assets you can free up the waterfall for the important assets.
The assets that we did have to keep, we re-wrote and refactored. The below JS snippet is a re-written version of almost 800 lines of code to control a single function. This brings down the load time and rendering time of the JS file significantly and kept the JS from blocking the rest of the assets.
There are several approaches to responsive CSS but the newest and most effective from a performance perspective is mobile-first. Mobile first involves taking the basic styles that apply to both mobile designs and desktop designs and and placing them in you base stylesheet and then adding features via min-width media queries. This is progressive enhancement.
The theory behind this is that tablets and desktops are usually on stable, Wifi Internet connections whereas your mobile views are most likely to be on 3G or 4G networks and would take longer to load. By placing smaller assets in your base stylesheet and only loading the larger versions on a desktop view, you save your user’s bandwidth and loading time.
SVGs are code that represents paths and basic shapes. They can be used to replace large and unwieldy images in a site and prevent the loading of a huge image. In this case, I replaced a large and highly styled map of the US and franchise locations with a SVG version of the US – this saved me from having to use a 300mB PNG representation of the states.
mages are the largest type of resource that you’ll likely be loading on your website. Therefore, paying attention to the size and type of images used is very important.
The first and most important thing to do when dealing with images is to compress them for web. Images coming straight out of Photoshop or God forbid Illustrator are very heavy and generally meant to retain their quality. Photoshop was built for photographers and is therefore unlikely to shed any quality unless you force it. Running all of your images through a compressor will remove unnecessary EXIF data, leftover layers, and leave a much smaller photo.
If you can avoid loafing images at page load entirely, that’s even better. There are multiple ways to trigger an image to load, but the most popular is through lazy loading. JS plugins will watch the bottom of your screen as you scroll down the page and load an image onto the page only when you get within X pixels of the top of the image. This prevents it from loading at render time and keeps a smooth experience for the user.
We took a slightly different route and handled our sandwich selector on the site carefully. Previously, all ~40 images were loaded at page load time – one for each sandwich that Cheba Hut makes. Instead, we hid the sandwich from the page load and only loaded it when the user clicked on the sandwich, thereby expressing intent to view it.
Making sprites is the act of combining several small images and loading them in using CSS – thereby reducing the total number of resources loaded on the page. We used this to cut down on the number of images by 6.
Finally, choosing between a PNG and JPG image is vital to loading images wisely. PNGs and JPS each have their very specific purpose and choosing the right one can significantly reduce loading time:
PNGs should only be used when the image is extremely simple or has transparency in it. They should never be used for photographs or when there’s a large amount of complexity.
JPGs are best when there’s no transparency – background images, photographs, etc.
By using a JPG instead of a PNG for the map background on Cheba Hut, we dropped 50% of the file size on that single file – over 200kB!
WordPress hosts have the advantage f being able to optimize extremely well for a single application – WordPress and only WordPress. They’re more expensive, but it pays off because they can finely tune their server setup and caching to provide a huge speed boost.
If you can’t convince your client to go with an expensive WP host, use a caching plugin. This will compress and zip the files used on each page load and deliver them statically to each subsequent user.
Finally, CDNs are a life saver when it comes to performance. A CDN has servers all across the globe and the ability to distribute your cached site from whichever one is the closest to the user, shaving off microseconds or even whole seconds from the delivery of files to the browser.
I redesigned my blog this weekend with a focus on the text and photos – nothing else. I quickly found the last design to be incredibly restrictive when it came to any kind of custom layouts or reading more than a paragraph. Poor typography, narrow view for content, and the lack of contrast added up to a pretty unusable design. So, I scrapped it and rebuilt the whole thing to focus on dead simple basic. It weighs in at just over
100 kB 73kB (most of which is Google fonts) without a hero and the CSS is a measly 1.4k. Makes for a lightening fast experience!
I hope you enjoy the easier reading.
There comes a time in some projects where you have to just stop.
In the last several months we had to do this with one of our projects. It was built about 8 months ago on a tight deadline with loose parameters from the client and had a LOT of complex content and integrations built into it. We got it done on time but without enough testing and time quickly aged the site. It started to get to where 3-4 issues would be coming into this client’s PM every week and we would constantly be in and out of the site fixing little issues.
So I cut it off and said “we’re stopping”.
All development was halted, all incoming issues tossed into a single ticket instead of immediately addressed and I went through every page of the site on every browser we test on with every device in our device lab and proceeded to fix every single bug. It was expensive from a time perspective, it was pretty painful to see all that we missed, and it took away from our other active projects.
We’ve had 1 bug come through in the month since we did the audit & repair on the site. Where we were spending a couple of hours a week going in and out, we now are bidding out more work for this client and they couldn’t be happier.
Sometimes, you just have to step back, put on the blinders and ruthlessly fix everything that’s wrong on a project. It will be painful short-term but you’ll end up with a smoothly working site and happy clients.