← Back to Blog

Site Update

I launched this WordPress based version of my website in 2017 or so. Recently I went back and looked at the source code and recoiled in horror, as one usually does when viewing older projects. This made me think it might be time to do a little spring cleaning, so I went and tried to improve some of the problem spots.

I’d been using the Bourbon/Neat SCSS library as a helpful way to add in a grid system and other nice things without all the classes that Bootstrap and other frameworks force you to add to your HTML. These days with CSS grid, however, the need for a grid system isn’t really there as now we have a real standard for creating layout. In addition, the library added a lot of unnecessary complexity to what is a relatively simple site. So out it went.

At my new position at Venture Media, I’ve had a chance to work with enforced coding standards. This has made me think a lot more about how I organize and write my CSS. If I was starting from scratch, I’d probably try to go with a proper BEM or SMACSS system and throw in some linting for cleanness. Rewriting everything seemed a bit of overkill, so instead I went and split everything into partials, where previously I dumped most defaults into a large _theme.scss file. I switched to spaces instead of tabs for files (shortly after watching the relevant Silicon Valley episode) as previously I had unfortunately set my tab-size to 8 so everything looked rather dreadful.

I think my previous arrangement was heavily influenced by my experience working in an agency for so long. For smaller projects, especially if you’re switching rapidly between various ones, I think it makes sense to keep most of the styles in one sheet, as the sheet can then map more or less to the structure of the page (header styles, followed by general layout and sidenav and then footer). I’m trying to aim for more modular and repeatable styles for my code, however, so that’s a system I’m going to abandon.

The other big change was the homepage. I thought it would be fun to use CSS grid to create a non-standard layout, so after playing with it for a little while, I came up with the arrangement below. I’m not a great designer, but with the animations thrown in, I think it’s a fun update:

Screenshot of the homepage of eoinodwyer.com

Of course updating made me realize that my npm packages were out of date, but an hour of attempting updates made me realize that switching to Gulp 4 was going to be a battle for another day.

← Back to Blog

The Need for Speed

I’m very passionate about speed optimization when it comes to websites. In part, it’s because most of the time I get to do it is at the end of a project where I’ve been handed something that’s running a bloated theme, like Avada, that’s thrown on some low quality shared hosting, and has several images that are larger than a megabyte. By that point in the project, it’s hard to make things snappy, since you’ve invested in features that tend to add to the site weight. While you can still solve a lot of issues with image optimization and plugins like WP Rocket, there’s going to a limit on what you can do without removing features.

When I created this site, I started optimizing from the beginning. For optimization, I used:

  1. Gulp to minify and concatenate all theme CSS, JS, and images
  2. TinyPNG for optimizing media library images
  3. Web Font Loader to handle Google font loading
  4. W3 Total Cache for caching

Combining all these together, I managed to get some very nice scores on Google Speed Insights and Pingdom

Getting down to less than half a second was pretty nice. As I’m running on fairly cheap shared hosting, these scores are heavily dependent on whether the cache is being served up, so sometimes it’s not quite as snappy.

Still, I was wondering if I could push it down even more. My largest resource being loaded is the background image for the site, so I tried implementing the blur-up technique described here in CSS Tricks.

Short summary, in case you don’t want to read the article:

  1. Replace background image with a tiny 40px wide version.
  2. Run that image through an SVG image to get the blur effect
  3. When the page is loaded, load the large image in the background with a dummy <img> tag
  4. When that image is loaded, add a class to the banner div to load the larger image

I ran into some problems pushing this live, as the technique requires adding internal styling to the <head> section, which led to some conflicts with other plugins and the way WordPress serves up some things like emoji CSS. Ideally, I would just load the background banner styles first, but in the interest of time I just removed those other calls.

I ran this through the speed tests and pingdom gave me the speed increase I was expecting:

That’s a 42% reduction in speed by lazy loading that one image, which is pretty cool, putting me into the top 1% of websites in terms of speed.

However…Google disagrees. My score slips dramatically to 71/89 for mobile/desktop mostly because of blocking CSS/JS resources. It looks like whatever way Google is running its scoring system, the lazy loading system is interfering with it in some way. If I simply remove the <style> tags in the head, the other resources are no longer considered blocking.

Given that a user probably isn’t going to notice the difference between 460ms and 272ms, it probably make sense for me to roll back these changes later, as Google speed scores effect SEO rankings, and I’m noticing some draw issues on the new Firefox on mobile. The important takeaway is that if you do everything right, it’s not hard to push your site speed down below 1s or even 0.5s if you have a simple design. The trick is doing working on that optimization from the beginning.