Getting Pagespeed to 100%

[dan (Dan C.)]

@Fuellemann said…
I am just a longtime user, not a developer. But since I do make my money with websites, here are my 2cents.

When I look at how Google rates websites, I want RW to be as compatible as it can be. Speed, libraries, all these things which gives my customers a good feeling whenever they throw my site into Pagespeed, Lighthouse and more.

Then I can convince more website developers to look at RW and to buy e. g. stacks and Foundry. I want and need the best tool, not the best marketplace for add-ons. This is - in my eyes - what RW could promise.

It’s interesting @Fuellemann brought this up as I’ve just started to tune up the Realmac Software website (homepage to start with) and there were a couple of things that blocked me from getting 100%

I wonder how we can get these fixed up @Isaiah @Elixir - any ideas?

[Elixir (Adam Shiver)]

Not sure I see much to fix there. A 96 is better than Google does for their own site.

You’d have to likely restructure the way RapidWeaver builds things in the theme files. The placement of javascript, CSS, etc.

That said, Google is changing all of these Page Speed insights in the coming months as I understand it.

[dan (Dan C.)]

Yeah, but it’d be a great selling point if RW produced 100% google search engine lovin’ websites wouldn’t it…

[Elixir (Adam Shiver)]

That is going to vary from user to user though. If you promote it that way and a user doesn’t get a 100 every single time, they’re going to be irritated. It’ll feel like a gotcha moment instead of a feel good moment most of the time.

As I said though, it would require you all re-thinking how RW handles theme files:

You’d have to likely restructure the way RapidWeaver builds things in the theme files. The placement of javascript, CSS, etc.

[dan (Dan C.)]

Ya gotta shoot for the moon though, right?

RW has been stagnant for too long, it’s time to shake things up a bit!

[Elixir (Adam Shiver)]

Go for it! I’ll keep my eye out for updated theme APIs for v9.

[Bill]

Asynchronous loading of js files would probably be a very good thing.
Faster loading of head files could definitely speed things up.

[Fuellemann (Jan Fuellemann)]

The one thing that is necessary would be to fix any security issues that come up. I can’t do it myself so I have to rely on you

Next thing which comes up all the time is that some scripts etc. are blocking the loading of the site and cause delays. So this must be the rearrange thing

And to be frank - to compete with Blocs and other software I think you would need to stay ahead on these developments?!

[weaver (WeaverThemes / egoMade)]

Yep,

One App that is getting great scores and traction is https://getpublii.com/, it’s great what it does and how fast it generates websites.

[instacks (Jannis from inStacks Software)]

Forcing JavaScript to load below body would be a first step in the right direction.

[Fuellemann (Jan Fuellemann)]

@dan could you do that?

[joeworkman]

I would be willing to bet that I have worked more on page performance than anyone. Foundation 6 is damn fast. I can say that confidently because I have spent many weeks shaving microseconds off on as much as I can. I am working on a new homepage for F6. It currently has a score of 94. I am pretty confident I can get this to 100 since most of my errors are on image size and I have done zero optimizations on my images so far.

There are many things that are completely out of our control. However, there are things that could be done by RapidWeaver or us developers as a group. Here is a random brain dump, in no particular order.

Image Size + Compression

There isn’t much that RapidWeaver can do to help here. One thing that could be nice is to warn people when they are uploading files that could be too large. I had a guy just yesterday have over 50MB of images on one page. I investigated the JS performance APIs to see if I could build some early warning mechanism. However, it does not expose the size of resources on the page, only timing. Sad.

I do not think that RW should try and optimize on behalf of the user though. Many users (including myself) do not like optimization forced on me. However, maybe some kind of option could be enabled. Which would mean that it would probably need to be turned on by default for new users since they are the ones that don’t know what they are doing.

Many users are not aware of new formats for the web like webp. Maybe if someone adds an image into Resources, you could have a warning about size and format? Maybe an option to optimize inside Squash directly from Resources?

jQuery 3

This one is pretty much on us developers. Google warns about jQuery 2 but it’s a pretty minor security risk to be honest. Many of my products work in jQuery 3 but many others do not. It’s a lot of work. But it needs to get done.

JS at the Bottom

RW already has %plugin_header% for the theme API. However, why does it not have a %plugin_footer% API? This could be used so that the plugins can expose the JS script tags. I know that there is a extraBodyHTML in the plugin API. However, this does not expose anything for the themes to have control over where things go.

In order to keep backwards compatibility, there would need to be a setting in the theme plist that states the theme needs the header and footer separately. Or else everything should go into the header.

Foundation 6 has is own async loader that I have engineered. It will asynchronously load CSS in the head and all of the JS at the bottom. With my suggestion above, I wouldn’t really need that.

3rd party embeds

Not much any of us can do here. If people place embed codes on the page, the page performance will suffer. Most services do not follow good performance practices and it does hurt page speed scores.

Unused Code

Google will warn about unused code in both CSS and JS. I don’t really see how this can be optimized. There are build tools out there that can remove unused code like PurgeCSS. I just don’t see how this can be integrated into RapidWeaver. It’s a command line tool that requires you have tons of developer tools installed.

As developers we can try our best to only load external libraries when needed. I see so many themes load tons of fonts and libraries regardless if they are being used. I guess a better theme API could help with that.

Code minification

I minify the code in all of my stacks as much as possible. I think at one time RW tried to further minify published files but it was a failure. Many times minifying code that has already been minified produces errors.

Caching

Another common error is caching age of static assets. There isn’t much RW could do here since it’s a server policy. You can define a lot of this in your htaccess file. Maybe supplying users with htaccess snippets could be a nice thing to have.

I always thought that it would be cool to be able to ship snippets in my theme or stacks so that RW could read them in. Because they are in a theme/stack, they are then updatable.

I should add that RW’s cache busting links is good.

Gzip compression

Any good hosting company should be gzipping all network requests. Many cheap hosts don’t. Nothing we can do about that. I promote Cloudflare which does this for users if their host does not.

Excessive DOM size

This one is on us developers to code our stuff as optimized as possible. However, It’s ultimately up to the users in not adding 500 stacks to the page. You don’t need to jam everything onto one page.

I am sure that there is more to talk about but that is most of it… hope this helps.

[Fuellemann (Jan Fuellemann)]

JS at the Bottom

RW already has %plugin_header% for the theme API. However, why does it not have a %plugin_footer% API? This could be used so that the plugins can expose the JS script tags. I know that there is a extraBodyHTML in the plugin API. However, this does not expose anything for the themes to have control over where things go.

In order to keep backwards compatibility, there would need to be a setting in the theme plist that states the theme needs the header and footer separately. Or else everything should go into the header.

Sounds like the best approach for a quick win?

[isaiah (Isaiah Carew)]

@joeworkman That’s a lot. But I’m having trouble pulling out concrete changes.

But maybe if we focus a bit…

If you could pick just 3 things to change – 3 things that you think are actually feasible, what would they be?

Let’s try to talk through the details, try to find a good place to make the change, and make a plan.

[joeworkman]

I think that the %plugin_footer% idea really is the only low hanging fruit here. The rest are quite complicated problems to solve. And many of them simply are not possible for RapidWeaver to solve anyways. There are a lot more moving parts to website performance than just the code and assets.

[isaiah (Isaiah Carew)]

But we have to start somewhere, right? Not every problem is low hanging fruit. But that doesn’t mean we should ignore your whole big list.

Are there any other items on the list that you think are at all feasible within RW or Stacks?

You can define a lot of this in your htaccess file.

On of the roadblocks to innovation here is that RW prevents publishing of files that begin with “.”.

Of course there are good reasons for ignoring hidden files – but perhaps a better solution would be require a special API for publishing dot-files that’s more purposeful. That way it still avoids accidentally publishing inadvertent hidden files and can take special care for overwriting things like htaccess.

I don’t know what the API would look like, but it seems like it would allow plug-ins to contribute something in this space rather than it being a hard-limit roadblock.

Google will warn about unused code in both CSS and JS. I don’t really see how this can be optimized.

This is one of those challenging requirements that works AGAINST some of their other requirements.

To reduce extra code usually means making styles and scripts that are hyper targeted and optimized to a specific page. Loading as much inline as possible. This could be achieved by including styles/scripts in each stack – instead of a single stack. i.e. more modular stacks.

Improving caching means making styles and scripts that are more generalized and LESS optimized to a specific page but more to the site overall and moving as many shared resources outside the file. I think this is probably close to where we are currently.

We can do both by making things very modular and loading just the parts we need from many separate files. But this will be flagged as problematic by google as well. Theme files used to try this – but it means many separate http calls, which is very very slow. Although doing modularity in the back-end has most of the same benefits with almost none of the downside.

Some of these things are nice – but each one works against the others.

This is one of those benchmarking-optimizing challenges where I’m not sure there is a correct solution. Achieving the pagespeed=100% benchmark means actually producing a slower site for real humans – so as tool designers we have to choose:

• do the thing correctly (pagespeed=100%)
• do the correct thing (site is actually faster)

We had these problems back in the day when everyone wanted the “100% CSS Valid” checkmark – even when it meant a worse experience for visitors.

Sometimes in those cases, it’s best to provide a way to solve the problem, but leave it up to the user to choose which way to go.

So the takeaway here is that we probably need to do all of the above, at least a little:

• make frameworks more modular (that’s on the framework folks)
• do page and site optimization (i think that one’s on me)
• support back-end modularization if php is available (i think that one may fall on RW or RW & Stacks)