An old article (of mine), but discusses the importance of having one-way backups.
I prefer open-source software and have been a long-time advocate of OSS in general. Recently, I started liking WP Rocket plugin that offers some unique features. I already have a perfect Nginx configuration for WP Super Cache plugin (that I consider as the best full-cache plugin till date). Since, WP Rocket uses disk caching like WPSC, I wanted to quickly convert the existing configurations to fit WP Rocket. I did succeed in it and you can find it in my WordPress-Nginx repo. Here I explain how WP Rocket stores the cached content and how it could be integrated into Nginx.
In a local-staging-live workflow, often we have some restrictions on both local and staging / development environments. A common restriction is to disallow indexing of the development site that may introduce duplicate content in the search result, if indexing is allowed (that is not uncommon when we set up the live site and then copy it to develop further :-) ). There are lot more restrictions and workarounds in order to setup a perfect development or local environment. Here, let me share a particular solution regarding emails. Let me start with some of the use cases.
Preloading posts is one of the popular recommendations by most articles on the internet on how to speed up your WordPress site. Since, most WordPress sites (I’d say over 99%) have little or negligible traffic, it is highly recommended to get the posts preloaded in the cache so that the visitors do not have to wait to get the generated on-the-fly that actually takes some time. In this case, by the time the post is generated to be served to the visitor, the visitors may have gone to visit another website. So, do I recommend preloading? Yes (for low traffic sites) and no (for high traffic sites). Read more for a bit of explanation on this…
If anyone has been reading this site regularly (anyone?), you may have noticed that this site had the title “Tiny Web Performance Insights” for some time. It’s been my long term aim to promote tinywp.com, a domain, that I have been holding for long. Here are the primary reasons…
- I use an email associated with tinywp.com, as my primary email. Never used the email from tinywp.in even though I still have an email forwarder active with my Google Apps for Email (G Suite).
- Google thinks that “.in” extension someone targets only a particular geography.
- Originally, tinywp.in was started to write about WordPress insights. Recently, I wanted to write about web performance in general. So, tinywp.com has become a natural fit to write about web performance.
I have been using another tiny wp.com site, to put down my random thoughts. It generates decent traffic too. Any site with content that is useful for someone some day, will start to receive traffic.
My 52-week writing challenge will continue primarily in TinyWP.com, a site dedicated to sharing my insights on web performance. No, I am not going away from WordPress. Actually, I tried. Every time, I try to go away from it, I am pulled back due to various reasons that deserve a blog post of its own. :)
Coming back to TinyWP.com… while I love WordPress and I have made over $20k (accounted income) due to WordPress, I still want to know how the other side works, especially, the static site generators (SSG in short). I also do not want to spend much money on hosting. While searching for hosting static sites, I came across Google’s firebase hosting that has free-tier. The free-tier with 5GB storage and 10 GB bandwidth is enough for me for years! Firebase hosting uses Google’s global infrastructure. I also believe it uses Fastly’s Varnish CDN. Google Firebase hosting constantly outperforms Netlify in every way. TinyWP.com is based on Jekyll that I have used in the past to deploy status pages of WordPress sites. Love the Ruby eco system in general. So, wanted to get back into it with a small-step.
My immediate next step is to keep both TinyWP.in and TinyWP.com active by writing regular content on both. While, I love writing, I don’t feel like writing when I don’t put enough efforts to improve myself on a particular week. It’s a perfect way to remind myself, if I don’t write any blog posts. I love to share what I learned, no matter how basic such things are for someone experienced. There are always someone who begins with zero knowledge on everything. Hopefully, one such person will find my articles useful sometime in the future!
Happy blogging everyone!!!
There are plenty of scripts in the internet, some of them even open source, that helps us to install WordPress automatically in a (single) server. Bitnami is the most popular among them. However, none of them met my requirements. I have some design considerations, security requirements and performance checklists. Since none of the existing tools met all my principles, I started developing my own tool to setup a (single) WordPress site in a (tiny) server.
Caching ecosystem around WordPress grows constantly with newer caching plugins coming up every year. In order to arrive at the best solution for caching, one needs to understand how everything fits together in a cache. There are multiple caching layers available. When a user sends a request to a particular page in a domain, for example home page of this domain, the reply doesn’t come fresh from the site. If it needs fresh data, it has to be prepared from scratch by this site. That in turn would take a lot of time to prepare and then send it to the user’s browser. The visitors would have closed the website and would have turned to another site, if the request doesn’t arrive within a second (in most cases). In order to achieve this 1-second milestone, the sites incorporate different caching layers to serve the request. Continue reading “Full Page Caching Options for WP Blogs”
Amazon Lightsail by Amazon Web Services is targeted towards new webmasters, server admins, DIY enthusiasts among others. It provides much more predictable pricing than EC2 based servers where the pricing is calculated as a cumulative cost of individual components (server, disk, bandwidth, etc).