A Newbie's Journey using WP Static (continued)

Site Performance Optimization
#1

[shout out to (obviously) @leonstafford and @john-shaffer again for their invaluable pointers]

My previous 2 deployments involved using existing WP sites (ie already attached to their domain names) built and managed on GCP, and exporting to AWS S3, and then configuring Route 53 and Cloudfront Distributions. This was using WP2Static. Both also landing pages so nothing overly-complicated

THIS TIME AROUND

  1. Staging Site
    Created on GCP using their quick-launch WP sites with IP address xxx.xxx.xxx.xxx
    Built site on WP using
    Elementor / Rank Math / SuperPWA / WP Optimizer / Insert Headers Footers (for GTM tracking)

  2. WP2Static or Static HTML Output 6.6.21?
    This time around Static HTML Output 6.6.21

  3. Configurations S3 bucket + Route 53 / www to root
    For some reason, (compared to previously, when using WP2Static) my www to root redirects resulted in a bunch of

" xxxx has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource. "

Largely solved by adding appropriate policies in the S3 Bucket adjusting Behaviours on Cloudfront and selecting but a couple of stray errors which pop up with a manifest warning

“Manifest: property ‘start_url’ ignored, should be same origin as document.”

I did not experience this with my previously workflow - had simple redirect of www → root in my DNS records

  1. Configurations CloudFront Invalidations for Expiry Headers
    Didn’t discover how to do this until now!! (v exciting)
    After running GTMetrix tests, i identified all the files that required long expiry headers.
    Did this manually but the improved results on testing made it all worth it :grinning:

Q: Should WP2Static / Static HTML Output Generator be doing this for me already? Or did I miss something in the settings

  1. PWA
    To pass my Chrome Lighthouse PWA score, i used aforementioned Super PWA plugin to create the manifest files. I think @leonstafford mentioned this would be incorporated later on, but this time around it was a bit more fiddly because i am was using a staging site, so the staging site URL reflected in the manifest was obviously xxx.xxx.xxx.xxx
    Not a big problem, i edited those files and rewrote the URLs before then manually uploaded to S3
    bucket.

  2. Missing files
    Previously favicon.ico and sitemap.xml exported fine
    Sitemap generated by Rank Math (but again, using staging site IP address of xxxx.xxxx.xxx.xxxx)
    Favicon manually uploaded
    Used 3rd party site to generate a sitemap.xml file to upload

  3. Google Analytics / GTM
    Sacrificed my 100% YSlow score by having these in → hahaha!

This was before Google Analytics/GTM inserted

jxyz_hosting_speedtests_20200911_GTMetrix
jxyz_hosting_speedtests_20200911_GTMetrix1261×855 106 KB

This was after

jinguruxyz_speedtest_20200912_v2
jinguruxyz_speedtest_20200912_v21255×843 157 KB

  1. Images
    In general - the sites i have converted to static so far don’t have many resources.
    Also - “over-optimizing” the images, whilst suggested by the speed test sites, usually means compromising on the quality of the image, so i have largely ignored those recommendations.
    In these instances, UX from an image quality perspective overrides speed and scoring.
    =============================================

IN SUMMARY

Happy with the results and adjusting the workflow this time around.
Obviously less issues to deal with given that my project(s) thus far have been 1-pagers/landingpages with few(er) assets to consider.

Next step for me will be to deploy this workflow to a more “dynamic” site with blogs that are updated regularly etc. What would i have to consider outside my existing workflow?

If you made it down this far - thanks for your time.
Any advice for this noob here always appreciated :laughing:

2 Likes
#2

w00t! Great to hear your journey!

Expires headers aren’t set by WP2Static at this point.

It would make sense to provide users with templates to use for AWS/Cloudflare/Netlify/GCP, etc. Not just for expires headers, but possibly also to handle form submissions/search and any other serverless functions to augment a static site.

1 Like
#3

@leonstafford

In your experience, should i just add expire to heads to only the files/assets stated in the (GTMetrix) test results?

Or can i just imply get away with using a long-dated wildcard --> /*
Is this good/bad practice?

#4

Personally, I’m more interested in initial page load speed for new site visitors, assuming that for subsequent visits, they’d be more invested/motivated, so the speed is less important. So, I only really try to get high scores in those areas as a point of pride and some fun to beat the system.

I’m more concerned about total download size for the page, ie my latest project: https://accessible-minimalism.netlify.app comes in at 1KB.

Where that kind of expires cache really comes into play, is when you’re serving massive amounts of traffic and minimizing requests saves you a significant amount of cost. Also, if it were not a static site, then each additional request to the dynamic web app would be taxing the server and desirable to limit.

Whether you do all static files or just your images/JS, etc will depend on your invalidation strategy and the site’s use case in general. ie, keeping a shorter client expiration on the HTML files allows you to force serving new img/JS/CSS using cachebusting strings, ie /my-style.css?cb=1234546.

Your HTML content should also be a lot smaller than any images, so that may help you choose what to prioritize.

1 Like
#5

Great - thanks for the advice @leonstafford
Will take that all under consideration.

In terms of the a site with a blog that is updated regularly is the process merely running the exporter, with the plug in already recognising which files exist from previous (and don’t require replacing/altering etc?

#6

I was looking at some ready-tailored solutions like Strattic, but first time i tried, i wasn’t overly impressed by the results tbh.

What is your opinion of them?

Maybe i should revisit…

#7

In terms of the a site with a blog that is updated regularly is the process merely running the exporter, with the plug in already recognising which files exist from previous (and don’t require replacing/altering etc?

That’s the goal. How well that works today though, you’ll need to try for yourself. Caching of any kind is hard. I prefer to redeploy everything to know exactly what I’ve got.

#8

I haven’t tried them much. The end result of a static site export should eventually be the same between all options. The biggest downside for my usage, is that you need to host your dev site with them. I think Shifter allows deploying to other static hosts for your generated site, I don’t think the others do.

Sitesauce is unique in not needing you to host your dev site with them.

None of our solutions are greatly better than what you can achieve with HTTrack/wget or specialised website downloaders and some extra scripts to handle forms, etc.

So, each solution has its pros/cons and will never be a one size fits all :slight_smile: