If a client wants a good page speed score, you can explain why optimizing for that may negatively impact other things. If they still want it, why not just do it and charge them for the hours? You could also give them a different tool to try, like webpagetest or gtmetrix.

Client have heard that load time affects SEO ranking. This is official Google's tool so client believes that the score here affects the rankings so they need to get 100 by any means.

Are they wrong? (got a citation for it that I can point curious clients at?)

Technically not, but for SEO ranking, it's one of a hundred factors that even if you max it out, it's a rather small one: https://searchengineland.com/seotable

Talk about diminishing returns here.

Source: We've got an Angular 1 SPA as a website that despite maxing out in the 70s for page speed (because we can't get rid of 700k of blocking JS) still ranks like hell, because we do all the rest right.

Google actually doesn't use their PageSpeed score -at all- in search rankings. They may factor in speed, but it's not the PageSpeed score. Moz did a study with this a year or two ago and could find no correlation. There was a correlation with TTFB though.

Any examples of the bad advice that would slow down the page?

A very basic example: if you had a large site, you can raise my Google Page Speed score by inlining all CSS and JS, but that would be stupid because it doesn't take into account the next page load and caching. I've seen some render blocking optimizations slow the overall page too. Getting rid of query strings is nice, but sometimes you need it for cache busting and other things, but it penalizes your score. Even Google's own tag manager/analytics scripts lowers your page speed score when they are on the site.

>> Even Google's own tag manager/analytics scripts lowers your page speed score when they are on the site.

I never understood why Google doesn't fix this. I want to use Google Analytics but their own tool penalizes me for it because it gets unproperly cached on Google's own servers? That's just stupid.

It's just a tool with a random score - why does it matter? Most of the recommendations are now outdated. Focus on overall experience and there are plenty of RUM monitoring scripts you can use (that take advantage of the very fine grained performance timings available in browsers today).

> sometimes you need it for cache busting

So it’s not good for speed

> Even Google's own tag manager/analytics scripts lowers your page speed score

Well these don’t exactly speed up loading your page.

Inlining assets is even less important and more of an overoptimization as HTTP2 pipelining takes over. Its like threading..used to be expensive and a sign of bad code whereas now, since everyone has cores to spare, its a sign of good algorithm use.

Http 2 handles loading multiple files better. So bundling isn't that important anymore.

Also, no need to put assets in a different domain anymore ( limit on loading resources per domain simultaneously)

> Also, no need to put assets in a different domain anymore

It's even considered harmful since extra domains means extra dns lookups which could take quite a while.

I’d say bundling is more important than ever right now in the modern JS ecosystem where an average site or app uses dozens of NPM modules.

As mentioned, in Http2 and server push... No need for bundling.

I agree on http 1.1. Sorry that you downvoted on a lack of knowledge ;)

No, I understand HTTP2 and the advantages server push brings (on paper). When you consider it’s inconsistent implementation across browser vendors and that it really works best only in a scenario with optimal connection quality, I’d say it’s bad advice to tell people to stop bundling JavaScript especially in today’s world where an average codebase is likely going to have a ton of modules.

>> Any static site is going to load fast though, it's when you have to make database and API calls when things get hairy

This is incorrect. Static assets are often the source of many problems, due to poor caching headers for static assets, missing gzip encoding, unoptimized images, etc. The time it takes for the backend to return a response will usually result in more overall savings in load times, but it's astounding just how inefficient frontend choices can be. It's not "micro-optimizing" to focus on improving the frontend instead of only focusing on the backend.

That doesn't really relate to what I just said. I'm assuming that you're using compression and have optimized images. But if you took a page, saved it as a static HTML document and compared it to the "live" version the static HTML document will outperform it virtually single time, even on a slower server. That is essentially what this script is doing, and what people do with tools like Jekyll.

Not all types of static files will slow down the loading of a site. JS scripts will block loading of the page. Web fonts will block text rendering (and they are usually heavy). CSS files sometimes can block rendering and sometimes will not. But images do not affect loading time. Even without images the page is readable and usable.

You can always not accept such clients. Why make life harder than it already is?

Because at the end of the day it's their money.

In other cases the client is a company client, and you might not be in a position to say no.

Nothing stopping you from explaining your opinion as an expert on the tech, and if it's extra time (==money) also communicating that. If that is ignored and you're getting paid for your time, that's the best you can do.

This is usually what happens, though in my case my boss (Lead Dev) is already telling them what isn't possible and what doesn't make sense. Some clients just insist for months until we finally give them what they want and they see we're not talking out of our rears. But yeah I understand all that, it's just silly to me to waste time and money doing things that will not be useful for the end-product. I guess I'll be numb to the silliness eventually...