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.
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. :)