![]() ![]() Eventually, it was slow enough to the point where I’m having difficulty even writing posts. I noticed, despite all this optimization work, it seems the site was still performing slow for un-cached users – i.e. That’s not an indication of something wrong with my site, per-se, but I do realize that it is very dial-up unfriendly. Unfortunately, when it comes to real user analytics like the one above, there are still long load times experienced by some probably due to their slow connections. In some cases, we’re down to 7 seconds for a whole load, whereas getting sub 20-seconds used to be a trouble. This improves load performance by overcoming browser-based limitations in the number of ports opened simultaneously to a given server.Īgain, quantifying the performance improvement is a little hard, but according to my checks with Pingdom Tools and seem to show much improved load times, when CloudFlare doesn’t have a stall. In what would be considered a basic move by some professionals, I’ve decided to share the loading of static assets from two alias subdomains ( and ). Even with the security settings set to ‘essentially off’, the level of comment spam dropped from manageable to virtually non-existent.īut even then, it could still be better. From their analytics data, they’re handling about 30-40% of the requests and saving me about 10-20% bandwidth – it might not seem much but it’s still something considering it’s free.īut one thing is that CloudFlare seems to have done wonders to the problem of comment spam. The impact of CloudFlare is a little harder to quantify – from my point of view, it definitely helps in terms of serving static assets. The super cache has a big effect on the response time of the server, as using rewrite rules avoids needing to invoke PHP, and does allow for the site to continue despite a temporary loss of database access. I noticed this early on, and have since forced the purge of the files on every new post which seems to make it achieve what I want it to.įrom looking at the Pingdom Tools website response time checker, it seems that it worked quite well. Then, I discovered that the preload feature in Super Cache doesn’t work quite as expected, and old super-cache files weren’t being properly purged, resulting in stale sidebars. Change of the structure somehow resulted in pingbacks working again, which was rather nice. Initially, a few interesting issues were discovered – Rocket Loader and Jetpack Comments don’t play well causing a duplicate post warning because of the timing of the posting and reloading the page, so I had to disable Rocket Loader. Furthermore, I decided to go with some caching in the form of WP Super Cache, improving the performance of the site by reducing the need to dynamically generate pages on each user visit. In order to do that, I have leveraged CloudFlare, despite my initial insistence to avoid it. In the past few site updates, I was on a quest to improve the website performance for visitors. Unfortunately, because of the amount of work that I’ve had to do, I haven’t been able to take a break to get these thoughts off my mind – but that wasn’t the only hindrance this time around. It’s been a few weeks since my last random post, and many things have happened in the tech world. ![]()
0 Comments
Leave a Reply. |