A Senior Developer working mostly with PHP and JavaScript, with a bit of Python thrown in for good measure, all on Linux. My tooling is simple, it's GitLab and JetBrains where possible.
I'd probably add "use caching where possible" into the mix.
With the majority of sites using a CMS database of some kind, skipping that whole database read can save a lot of time (relatively) if the content won't change regularly
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Pagespeed and lighthouse ignore cache so you will never get a better score adding cache. I've tried it many times using cloud flare and another services of that kind.
If you have static content there's no point on caching it out of your server, it will be slower than using server cache (no redirects, no third party implications), so you can simply use server cache module like memcached, opcache, pagecache or another, you'll need to check it depending on having apache or nginx.
A Senior Developer working mostly with PHP and JavaScript, with a bit of Python thrown in for good measure, all on Linux. My tooling is simple, it's GitLab and JetBrains where possible.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
yes, you mean on a dynamic site (which sometimes a server language will need to read from a DB to process the output content), of course it's useful to cache this sites even on a third party cache-proxy :)
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
You will always have caching (servers usually perform cache automatically by default) but the error you get on pagespeed about "Serve static assets with an efficient cache policy" is about resource cache headers (images, scripts, style sheets...) that implies cache lifetime. This means adding Cache-Control: max-age=31536000 (which is a 1 year lifetime cache).
BTW cache must speed up the downloaded resources, so logically (and practically) you must get more pagespeed score using a cache of 1 day than not using cache for example, but pagespeed request uses no-cache server request and avoids user/local cache, so the score will be the same using cache or not, that's what I wanted to mean .
The difference on pagespeed score about using 1 year cache lifetime on all assets and not using cache will be only about the weight of the error mentioned above. You can try solving all errors and performing all recommendations except this one and check how much it weights.
Another point to keep in mind is that if you are managing a web app which is constantly evolving and you set a 1 year lifetime cache, you'll probably need to purge the cache every time you deploy a version into production (recommended custom purge only for the assets you updated).
I'd probably add "use caching where possible" into the mix.
With the majority of sites using a CMS database of some kind, skipping that whole database read can save a lot of time (relatively) if the content won't change regularly
Pagespeed and lighthouse ignore cache so you will never get a better score adding cache. I've tried it many times using cloud flare and another services of that kind.
If you have static content there's no point on caching it out of your server, it will be slower than using server cache (no redirects, no third party implications), so you can simply use server cache module like memcached, opcache, pagecache or another, you'll need to check it depending on having apache or nginx.
That's what I was meaning by avoiding the database for CMS reads. I should have been clearer.
yes, you mean on a dynamic site (which sometimes a server language will need to read from a DB to process the output content), of course it's useful to cache this sites even on a third party cache-proxy :)
Lighthouse inspects cache-control headers, and if you don't have them set (or set properly) you will be penalized.
You will always have caching (servers usually perform cache automatically by default) but the error you get on pagespeed about "Serve static assets with an efficient cache policy" is about resource cache headers (images, scripts, style sheets...) that implies cache lifetime. This means adding Cache-Control: max-age=31536000 (which is a 1 year lifetime cache).
BTW cache must speed up the downloaded resources, so logically (and practically) you must get more pagespeed score using a cache of 1 day than not using cache for example, but pagespeed request uses no-cache server request and avoids user/local cache, so the score will be the same using cache or not, that's what I wanted to mean .
The difference on pagespeed score about using 1 year cache lifetime on all assets and not using cache will be only about the weight of the error mentioned above. You can try solving all errors and performing all recommendations except this one and check how much it weights.
Another point to keep in mind is that if you are managing a web app which is constantly evolving and you set a 1 year lifetime cache, you'll probably need to purge the cache every time you deploy a version into production (recommended custom purge only for the assets you updated).
Thanks for sharing this! 😊