Categories
Deployment Optimization Weekly

Weekly: optimize everything!

Well a bunch of things happened this week but I think the general theme is to optimize everything. It’s just something that I do from time to time cause gaining efficiency pleases my soul (like the cost efficiency from switching hosting provider).

Speeding up my zsh shell launch

I was feeling like my shell (zsh) launches have been getting slower and slower over time with additional plugins and packages to make my life better. But my workflow revolves a lot around the shell, so the waiting was starting to bother me.

TLDR; I managed to reduce the loading times from 1.xx seconds to 0.2x seconds.

The improvement was constant across various devices, some actually took more than 2 seconds cause of all the helper plugins I was using. But on average it was 5 times faster.

You can use this command to benchmark your shell speed.

for i in $(seq 1 10); do /usr/bin/time zsh -i -c exit; done

personal laptop: before optimisations
personal laptop: after optimisations

There was definitely a noticeable speed up when I open up a new tab. And it made my 5 year old laptop feel way faster than before.

What did I do?

  1. Switched from zplug to antibody plugin manager.
  2. Use static loading for antibody.
  3. Follow the guide for speeding up zsh
  4. Debug what took the longest during new shell init
  5. Lazy load everything that I could

Lazy load everything because I work with various tools such as

  1. rbenv (for switching ruby versions)
  2. pyenv (for switching python versions)
  3. nvm (node version manager)
  4. tfenv (for switching terraform versions)
  5. thefuck (magic autocomplete for typos)
  6. some extra plugins here and there

Usually on shell launch it needs to load in all of the dependencies, alias and what not, and that takes a little bit of time, by lazy loading (aka. only load when use), it speeds up the shell by a lot and I still get all my tools on my finger tips. It just takes a fraction of a second longer to load those commands, but since it’s not something that I run on a regular basis it makes barely any impact on my workflow.

An example of what lazy loading would look like for nvm for example would look like this.

lazynvm() {
    echo "Lazy loading nvm..."
    unset -f nvm node npm npx
    export NVM_DIR="$HOME/.nvm"
    [ -s "/usr/local/opt/nvm/nvm.sh" ] && . "/usr/local/opt/nvm/nvm.sh"  # This loads nvm
    [ -s "/usr/local/opt/nvm/etc/bash_completion.d/nvm" ] && . "/usr/local/opt/nvm/etc/bash_completion.d/nvm"  # This loads nvm bash_completion
}

nvm() {
  lazynvm 
  nvm [email protected]
}
 
node() {
  lazynvm
  node [email protected]
}
 
npm() {
  lazynvm
  npm [email protected]
}

npx() {
  lazynvm
  npx [email protected]
}

Speeding up WordPress

I forgot to benchmark for this optimisation, but just by navigating around the site I felt like there was a noticeable responsiveness.

In the past, I used to use WP Super Cache and it worked extremely well for me, because the old site was quite responsive even though it’s running in a docker container on an underpowered VPS.

However, Hostinger uses LiteSpeed servers for hosting WordPress, it took me a while to understand that it was not simply a plugin but another type of server (like Apache) that is acting as a web host. This meant that I would be able to extract greater performance by relying on their LiteSpeed plugin on WordPress instead.

It came with reasonable defaults but I tweaked quite a few knobs to extract whatever more performance I could get from caching on a $1 web host.

  1. Cache everything possible including comments
  2. Combine CSS into 1 file and minify
  3. Combine JS into 1 file and minify
  4. Lazy load JS
  5. Exclude jQuery
  6. Async load CSS
  7. Async load Google Fonts (considering removing altogether)
  8. Enable HTTP/2 push for CSS/JS
  9. Disable lazy load images (relying on CDN)
  10. Automatic optimisation of images via cronjob
  11. Enable tight integration with Cloudflare CDN from within plugin
  12. Enable browser cache (still a bit unsure cause CF does this too)
  13. Rate limit crawlers

I wanted to enable memcached for objects but since the server doesn’t support it there’s not much I could do. But honestly with these additional tweaks in caching, everything flies, as long as someone has actually visited that page before.

Unfortunately, on the backend of WordPress everything still feels very sluggish from the lack of compute resources. But since all I do is write it doesn’t really bother me as much. (it’s sluggish because you can’t cache things that you expect to be dynamic and real time in the admin console)

I’ve also enabled extra security options and plugins which definitely adds to the load of the site (plus mandatory SSL for everything). But overall, I am pleased that this even works for $1/month. That’s like a bottle of coke man.

Other stuffs

Onto the other things that happened this week outside of work but has nothing to do with the theme of optimisations

  1. Deployed the new portfolio/landing page.
  2. Bought a new NAS (Synology DS918+)
  3. Continued to work on the Calculator (it’s weird that I have CD but no CI, probably write something about it another time)

That sums up the week. Decided to schedule posts to publish on Wednesdays instead, because Weekly Wednesday has a nice chime to it (:

Leave a Reply