Optimizing Code in a World That Doesn’t Want to Optimize

Premature optimization is the root of all evil.

It is a common saying among developers. It makes sense. Optimizing prematurely can mean redoing work down the line, and time is the developer’s most finite resource. It can mean spending that precious time optimizing for scenarios that do not yet exist for a product’s users. It can mean writing code that is harder to understand with unclear performance gains.

While participating with the WordPress theme review team about a year ago, I came across that nugget of advice once again. Premature optimization is the root of all evil. The reply was to a theme author who was looking to decrease the number and weight of scripts their theme needed to load. On one hand, the theme author could load a 1.29 kb script with no dependencies to get the job done. The other option was to use the jQuery-dependent script included in core WordPress for a total of 105 kb because “most” WordPress sites are loading jQuery anyway.

For me, the answer was simple. Use the smaller script unless the core script was already loaded on the front end. I did not think of it in terms of premature optimization. I thought of it as plain old, run-of-the-mill, everyday optimization.

Developers should not confuse premature optimization with the concept of making smart design decisions early in the process. Nor should they wait until the final stage of development to start optimizing, a time when the focus is on getting a product out to end-users. That is a sign of a poor product design process.

Over the past year, that conversation stuck with me. It helped me become more cognizant of a terrifying trend, not just in the WordPress developer community, but with web development in general. Far too often, developers are so far removed from normal users and the technology those users rely on that optimization is little more than an afterthought. Instead, it should always be at the forefront of any developer’s mind.

The overreliance on this misused quote has helped push the trend of measuring page weight in megabytes instead of kilobytes. It is too often used as a catchall justification for not doing any optimization in the development phase while making up for it with file compression and caching in production.

Part of writing quality code is optimizing that code during every stage of the development process. It is about making hard decisions to cut unnecessary things as the software comes together. Caching should be a last resort after everything else has been cleaned up.

Premature optimization is more about attempting to optimize when there are no clear gains or working on micro-optimizations that alter the software’s design for little-to-no benefit. It does not mean overlooking obvious performance boosts during development.

Not Everyone is on Gigabit Internet

Most developers I know are on super-fast internet connections, often with 1 Gbps download speeds and unlimited data. In that situation, it is easy to forget that large chunks of the world are still on slow connections with data caps.

Some may even associate slow connections with third-world countries where millions of people are on 2G cell phone technology. However, there are large swaths of the United States and other developed countries that have no direct cable or DSL lines, which are commonly available in cities and suburbs.

This disconnect is directly evident when other developers have initiated chats with me. In the past couple of years, it has been increasingly common for them to ask for a video chat. It is not even questioned whether such a thing is possible (video chats are unreliable at best for me). The ability to video chat at any time is taken for granted.

There are two internet service options in the area that I live in: satellite or dial-up. Even the local telephone company refuses to offer DSL in this area because of infrastructural costs with decades-old phone lines. Because of the prohibitive costs of satellite internet access, which typically comes with data limits, many are stuck with dial-up. Cell phone companies are changing the game to a degree, assuming service is reliable, but there are downfalls with going that route, which can include data or hotspot limitations.

For such a technologically-advanced country, many of its people are barely catching up to where others were a decade ago.

While I am fortunate enough to choose where I live and have nothing holding me back from moving, most do not have that option. They are stuck with the best they can afford. Even in rural areas, the internet is an inescapable part of daily life, and developers are not making it easy for these people.

While this is anecdotal, it is the stark reality of rural life in pockets of the US.

The upside of living in the backwoods of Alabama is that it has changed my perspective as a developer. It has meant that I needed to question every code decision for every plugin and theme I built. With data caps, I needed to make sure that I was not using too many resources.

More than anything, having a data cap changed how I used the internet. I now run an ad-blocker. I have an extension to kill videos from auto-loading. I disable JavaScript on heavy sites that I need to use. Some sites seem interesting, but I never return to them because they are resource hogs.

When you live in a place where every byte matters, you tend to avoid wasting them.

While not always successful, since my transition to small-town life, I have attempted to build applications in a way that served people who are not privileged enough to have blazing-fast internet access.

Pointing this out is about making sure developers are aware that optimization matters. It matters at every stage of the development process. It matters because these people with slow connections and data caps also need to buy products, use services, read content, and do all the other things that people do on the web.

If you are a developer who is thinking about adding that slider, swiping mechanism for mobile, or some other slick gadget, think about those of who must wait for that feature to load. Check that its dependencies are not loading too many extra resources. Do some research to see if you can locate a lighter-weight implementation. But, first, ask yourself if it is necessary.

The themes and plugins that WordPress developers build should never be the bottleneck for a website. We can do better.


25 responses to “Optimizing Code in a World That Doesn’t Want to Optimize”

  1. This is a very important reminder for all of us. Not just for developers – I have clients who add too many images to their homepage slideshow because they can with WordPress, or designers who design websites with slideshows and lots of images/or processor heavy interactivity, or SEO consultants who want to track everything at the expense of loading loads of external scripts from every tracking company out there. Nobody wants to wait for all that extra stuff to load.

    I enjoy and always learn something from your articles Justin. Thank you for your sharing your writing with us. :)

    • Where possible, I find it is helpful to limit the number of size of images which can be displayed on the site. This prevents site admins from unknowingly bloating their pages. Of course they then send an email demanding you remove the limitations, but at least I can say I tried to stop them from wrecking their own site :D

  2. @justin – Glad you are bringing articles like this to WP Tavern. I recently did a custom site for a 501c4 homeowners association of a few thousand people who live in the hills. They have few services, much like you. We had to build a very powerful website for them that would load quickly over slow internet connections and mobiles. It has been a joy optimizing for the needs of the remote audience.

  3. Hi Justin,
    true words… and it reminds me of the fact why mobile phones get faster and need more CPU power each year… because developers don’t care.
    If you look at the original iPhone – amazing technology and a 400MHz CPU. Was fast enough, but then people started overusing it and not caring about performance… thus a faster CPU was needed…
    Same for the web. In my opinion most developers are simply not aware of the fact, that the internet might be slow or fail.
    So – good article!

  4. Just a quick two cents worth.

    In my experience, developers who pursue “premature optimization” usually do so to the significant detriment of maintainability.

    Some developers are so focused on performance that they write code that is a nightmare to maintain for those that follow them, and ironically those that follow them often make modifications that are have significant performance costs, in large part because the “performant” code is far to clever for others to easily figure out.

    So I think the phrase “premature optimization” is really more about making sure developers also focus on other really important aspects of coding instead of getting fixated on performance at all costs.

    And as I said, #jmtcw.

  5. As owner of a WordPress theme development company i have always tried to have less and less scripts which would mean lesser fancy stuff and bundling of plugins at the cost of speed.

    We have always kept our themes simpler for that very reason with no plugins bundled in order to have a faster website experience for all of our users.

    Because most of our customers from developing countries still use 2G or 3G speed internet.

  6. Funny post at wptavern. Somebody should check just this post – 116 HTTP requests! Yes, 116 one blog post :) Almost half of 1,4MB page is javascript :)
    Loading more than 4s from Europe.

    This website looks like a satire to optimization. Even somebody cool will optimize this website and remove 50% code, it is still bloated mess.

    I think this is state of the web and state of the WordPress in 2019.

  7. Hear, hear!

    Web design is getting out of hand to a point when the size and performance impact of sites and apps keeps growing at a much faster rate than even the powerful processors of today can keep up with. Many sites are almost unusable without an ad/script blocker. Just look at google.com – this page looks pretty much the same is did a decade ago but uses a lot more JS and is bigger in size.

    When hunting for WP themes, my eyes are always on the lookout for ones that have “speed and small size” as one of their selling points. Unfortunately, none of the default WP themes seem to care all that much about loading scripts and stylesheets like there is no tomorrow. GeneratePress is currently my favorite theme, although there are many others to choose from as well.

  8. Thank you for eloquently stating what I have felt for years.

    I spend half the year in Truckee. It’s 3 hours from San Francisco and it gets a bunch of rich Bay Area tourists so you’d think the internet would be fast.

    Nope. Slower than molasses.

    Using a 100kb slider library when Unslider at 5kb would have sufficed hurts me up there. A lot.

    The problem isn’t helped by performance testing tools like GTMetrix that are on extremely fast connections. 1Mb loads on those tools in about the same amount of time 1kb would. The DNS lookup takes longer than the data transfer when your connection is that fast.

    This misleads people into thinking bloated web pages aren’t a big deal. But they are.

    For many of us, in the real world, internet speed is the main bottleneck.

    I made various videos promoting Oxygen’s performance and mocking other builders that output hundreds of kilobytes of bloat. The typical response from the other side (if they’d even respond) was that I was exaggerating the issue, playing it up for marketing purposes, and that internet connections are so fast now that no one notices.

    A blank page created with Divi now loads approximately 1Mb of scripts and styles.

    I hope that Gutenberg does not go the same way. A default WP install now loads Gutenberg’s default styles on all pages of the site, even if Gutenberg was not used to write the post.

  9. I don’t envy you! You have a lot to think about in the US. Here in EU, things are totally different. We have adequate basic services for everyone, including access to the Internet. (The government sees to that, it’s one of the reasons we pay firm taxes, especially rich people.) Mobile connections are fast, we’re now transitioning from 4G to 5G.
    It’s safe to say that the vast majority of the EU-based websites are targeted for EU. This means that loading a block of common library code isn’t really worth the fuzz unless your website is meant for users in the third world or US.
    30 years ago every KB -or should I say every byte- counted; I remember stuff being coded in assembler just to make it run faster and be able to fit it on a floppy disk :) I’m glad those days are over in EU and we can now focus on UX – including speed perception. I hope some day US will catch up again!

    • That’s not true at all. I also live in the EU, and plenty of people here have horrendously slow connections. In particularly, once their mobile data runs out, they’re throttle capped to 64 kbps.

      And even if they have no data cap, that’s no reason to needlessly load a bunch of JavaScript. Even if it downloads quickly, the poor browser still needs to parse it all.

  10. Thanks for highlighting this issue.

    The number of times I see jQuery loaded just for one teeny tiny task which could be done with a few lines of vanilla JS is ridiculously high. I often even have to convince people that jQuery isn’t present in every WordPress site by default. People seem to think it’s the standard tool for every single job.

  11. You are quite right. I have lost hours and hours trying to make simple, reduced and optimal solutions in the first steps of so many projects. The line between, as you said, smart decisions and premature optimization is so blurred.

    But as a general rule, the simpler the better works fine. Despite the fact that sometimes complex solutions must be built.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.