My name is Gary Hall. I am using CF for my wife’s WordPress site running on SiteGround.
Images started of at about 50% of the bandwidth. My wife has cutback on the number of images in her blogs, so it is down to about 25% of the bandwidth. Still, with a WordPress site running plugins, any speed up is helpful.
I am also using Auto-Minify and RailGun.
My site uses https/htst, but since the free plan does not send the htst header with the base domain, I am doing htst from SiteGround in my .htaccess.
Welcome! These good questions - are you able to raise a topic for this in the performance section? Note you may need to acquire the right permission by reading a few topics first - see trust levels and permissions for more information.
That’s true, but images are not really a problem when it comes to website speed I believe. That’s because they are not render blocking, can be compressed with services like Kraken.io or Tinypng.com, and are (read: should) not that big to begin with if done properly for a blog.
(I’m assuming here that a typical blog has no need for 1000px+ big images. )
I’ve taken the liberty to look up what’s probably the website we’re talking about – www.jennystampsup.com.
I’ve performed a webpagetest here to look for possible areas for improvement. Based on that test and what I see in my browser, I’d look into improving the following:
Reducing the amount of CSS files. I figure that at least a couple of CSS files are unneeded for certain pages. For instance, the homepage loads the plugins/pdf-print/css/style.css file, which seems to be something for blog posts.
You might want to defer load the CSS files that are not necessary for the webpage to begin rendering. (Google for several ways in which you can defer CSS.)
Your images (in /wp-content/uploads/) have a max-age cache control header of 4 hours. This can easily and safely be much, much higher – like 6 months or higher.
Your images can be compressed to be much smaller. For instance, the May-2017-thanks-for-your-order.png file is 96kb big, but is after compression with Kraken only 31kb big (-67%). Best yet, this has no visual effect on the image itself.
There are several resources loaded that have a redirect (see the bottom half of the webpagetest). I can’t quickly see what causes that, but you might look into the plugin that does so.
The site uses a lot of Javascript, and I mean really a lot – 41% of the page’s size is Javascript code whereas images are only 31%. Because Javascript is render blocking (the browser first has to run the Javascript code before the webpage can be generated), probably a lot of speed gains can be achieved by removing any unnecessarily Javascript code. You might also want to look into plugins that offer their features without the need for Javascript, like social media shares without Javascript code.
There are also a lot of requests for the page. And while you use HTTP/2, combining your 200+ requests into fewer increases the speed at which a file can be downloaded and the overall compression.
Your website references 54 other domains (see here). This is quite a lot because each domain needs to be looked up by the browser before the files can be downloaded. If possible, less external resources make your website quicker.
It might be my browser and adblocker, but it seems you have one small YouTube thumbnail on the frontpage with the latest video. Is that correct? If so, I would replace that thumbnail with an image or logo of the YouTube channel. That way you don’t have to load 450kb+ of Javascript, 40kb of CSS, and reference the YouTube domain. Because the embedded video that I see on my computer is the size of the Shift keyboard key, I figure that not many people are going to watch it on the website itself (and so are already going to the YouTube channel itself for watching). And so you can make the website quicker by not loading this “unnecessary” stuff.
The widget.js file that’s loaded from the widget.privy.com domain is very big for a simple widget (144kb of Javascript). I don’t know Privy, but Googling them suggests that they create email opt-in forms. Perhaps you can replace that opt-in form with another plugin, preferably one that uses less Javascript or at least doesn’t require downloading several files from the privy.com website? (I see that your website code also contains references to MailChimp; if you already use them, perhaps their forms are an option for you?)
I see that your website also loads reCAPTCHA files from gstatic.com (71kb of Javascript). I don’t see something on the site’s front page where I can spam, so I don’t know if these are necessary?
I see that your website assets (like HTML, CSS, and JS) have the x-proxy-cache: MISS header added to them. This seems to be a header from Nginx, which is what I assume is what SiteGround uses. You might want to look into why the Nginx caching over at SiteGround doesn’t seem to work. If files are cached properly on your webserver, files can be accessed quicker by Cloudflare (if it hasn’t been cached by Cloudflare yet).
You’re referencing several external fonts (Lato, Roboto, Merriweather) from Google Fonts. While custom fonts can make a website more pretty, they also need to be loaded (the regular font but also its italic and bold variants) and processed by the browser. This reduces the website speed, both for desktops and mobile devices. If possible, I’d look into reducing the number of webfonts used or just use plain fonts – which can often be just as pretty and readable, but require much less downloading and processing.
There are more things you can do, but to summarise my advice and suggestions: focus on ‘less is more’ and removing clutter from the website. This also fits nicely with the shop’s tagline (“Clean and Simple”).
(I’m not a WordPress user but did use that platform extensively in the past. Anyway, I’m hoping that people more knowledgeable about WordPress also jump into this thread!)
PS: For fun’s sake and to emphasise the point of pushing back on the amount of Javascript, here’s a video that shows how quickly the website loads without any Javascript (on the left) and how quick it loads with Javascript (right). When you turn off Javascript, the total load time is more than halved.
Of course, it’s unrealistic to remove all Javascript. But this does show that the Javascript usage is a big area for improvement.
These are all great suggestions from @JuM here - your Cloudflare edge caching configuration is good and all static content is cached. There’s a couple of Cloudflare features you might want to consider:
Consider enabling Polish with webp support on our Pro plan - this will automatically compress your images and webp in particular will reduce the amount of bytes the browser needs to download to render your image content
Experiment with RocketLoader potentially to combine your Javascripts - this may help but it’s best to test before and after to understand the impact
The x-proxy-cache: MISS is also seen on your HTML - it may be worth investigating whether this proxy cache can also cache the static HTML (e.g. page views for non-logged in users) to save your WordPress server the time & effort to generate it. This would reduce the time taken to deliver the initial HTML and work nicely with or without the Business plan feature I mentioned to put this HTML in our edge cache
I’ll honestly say that I’m super disappointed by the reception of my above post. No reply from the topic starter (which hasn’t even logged in for 14+ days now). If my post took 10 minutes to write it wasn’t such a big deal, but unfortunately for me I spend much more time (too much?) on it.
I had at least hoped I could have made one valuable suggestion for the topic starter, but apparently not.
I guess I should clarify. I am on partial set-up through my host SiteGround. Here is the response from support:
Your on a partial setup through SiteGround which means that Cloudflare cannot protect the root domain.
A partial setup means Cloudflare can only protect and have our features enabled on subdomains, which is why you will not see a HSTS header.
. Also adding some tags.