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… Continue reading “Tiny Web Perf Insights”
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 set up 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).
Right after creating my first WordPress plugin, Auto Maintenance Mode, I came across a situation on a high-traffic blog where the visitors just rush to the website immediately after a blog post is published and shared (automatically) via social media. It created chaos in the server and the initial visitors didn’t get the cached version of the blog post, because it wasn’t even ready.
It isn’t uncommon to see freemium plugins in the official WordPress repo. The basic functionality of the plugin would be free. Some fancy features would come with a premium price. There is nothing wrong with such business model. What’s bad (business model) is switching the free features into paid features without notification. How does it feel if WordPress Foundation started charging a small fee to use the theme customizer?