Rich's Tongfamily (Richtong.net add-on)

OK, this has been on my list for a long time, I first started by saying I would learn Go first, but that is going to take a long time, with so many blogs that I need to get running right away, I decided to just bite the bullet like last time and start again. I read one review that said that Hugo is the fastest at site generation. Yes, Next.js and NUxt.js have more features being React-based and using Javascript and Vue.js respectively, but for me, these are sites that aren’t going to change much so simplicity is king.

The last time I did this, I couldn’t get the CMS to work properly, but in the year, Netlify open-sourced their CMS and renamed it Decap and it seems to work much better.

I first tried the create from a template on the Netlify site and it just didn’t work. It worked for Nuxt.js and the others, but when I went to the Decap site, the deployment to Netlify worked great. You authenticate against your GitHub account and it automatically creates everything you need. The main trick then is that it also enables Netlify Identity, so you can create a login with an email and you can now edit.

This is a huge advance over last year when I couldn’t get any of this to work. Decap successfully edited a post and then posted a git commit to put it back in the repo. Yes!

Cloudinary and Images

The net thing to worry about is image management. Netlify discontinued their Large File management so you can either use the native Git LFS (which costs $5/month from Github) or you can use a free Cloudinary account. That sure sounds good to me.

I’m eyeing moving my main tongfamily.com site over there and it has about 3GB of images mainly for the post images so Cloudinary supports more than enough.

The other thing is that Netlify changed their program so they will host for free only public repos. That doesn’t make much difference for the vanity sites that I’m making, they are just framework sites anyway. The net is the whole thing if you work it is free. A pretty good price!

WordPress Cloudinary and JetPack, not WP-Optimize

The next step is to try Cloudinary on my WordPress site. I had not used it in a long time, but their Cloudinary Plug-in seems to work for me and it is pretty easy. It automatically syncs images from your WordPress system and pushes them to Cloudinary. It is fault tolerant because if Cloudinary goes down, you can still use the WordPress images.

One area to note of some conflict is that the free WordPress JetPack also does Image Content Delivery. Also, on upload, I was using Smush to compress the images, but this appears to be part of Cloudinary as well, so I’m not sure if I should still use it or not.

I also tried the third-party WP-Optimize, but ironically this seems to slow everything down. I guess it probably conflicted with JetPack. As a reminder, you have to turn this on by setting WP_CACHE as true in your wp-config.php. Mines is read-only so I had to manually edit it. Beware of that. The site itself is pretty lousy, it gets a 36 on Mobile and 43 on Desktop which is a D. So I’ve got to work on site speed. For now, I turned on Cloudinary and all its optimizations and then used JetPack for the rest.

For about a day the site has been really slow showing 100% CPU utilization. I can’t tell if this was running WP-Optimize or not, but it seems to have stabilized to 10% and Cloudinary says 80% of the assets have been optimized and that they are half the size, so that seems good.

WordPress site speed: 7 seconds to 5 seconds with Any to Any

So I know the site is a bit slow and this got me curious about what is going on. I see that the images I’m putting into each post a 2-3x too big. This is something I get when I connect to the site and somehow WordPress knows about it in the browser. I wonder how.

So I cranked up GTMetrix.com to see what was going on and it showed a 7-second load time. Wow, that is crazy high. It was 3.6 seconds of just a blank screen before it showed anything. Geez. Besides that, the images are really big 300-500KB for each image. Much larger than they need to be. I see that they are being served from the instagram.com CDN which is what I presume Cloudinary is using. So a lot of work to do here.

I also see that there are many connections to Facebook etc which I think is because I have two layers of sharing icons. I’ll work on those. I got rid of AnyToAny and now am just using the JetPack Sharing buttons and this cut time to 5 seconds which is still terrible. The big problem seems to be server startup.

Another thing I noticed is that JetPack caching is turned on, but I did set it to use the theme’s page-down behavior, turning this to the default seemed to help, but this didn’t seem to help. And it looks like I had Smush on which may have been redundant.

Trying to remove all the plugins including Cloudinary, no difference

So the next thing to try is to remove all the plugins to see if there is any change. The main issue is that I need some of them like Post to Buffer to get LinkedIn, Twitter (which is set to private), and Youtube. I leave the 30 free social posts from JetPack Social to Facebook since I don’t post more than 30 times a month there. And there is a separate Mastodon toot plug which gets me to all my channels but Threads and Bluesky.

And I found that things got faster. I think it’s Cloudinary causing the issue.

I also tried to enable php-imagick as well although this isn’t supposed to make a difference

Could it be the Related Post? No difference

Suddenly everything is faster once the Related Post comes up but then it didn’t

Missing Page Cache? The Solution Super Cache which JetPack Boost doesn’t do

I mistakenly thought that JetPack does page caching, but looking at it, it looks like I was wrong, current JetPack has image caching but not page caching, so on to adding Super cache which Automatix the makers of JetPack just acquired. When running JetPack Speed Boost, this moved the site to A and saved an entire second.

Note that JetPack Boost actually competes with the image optimizers, so you don’t need those and seems to overlap with Cloudinary as well, so looks like you can probably turn off image optimizations for JetPack if you are using Cloudinary. I left both on for now.