4 ms·
The value is in the bit where the client also have to fetch 15 JS and CSS files from you. Getting those from Google instead is very likely to be faster. Also, t
by mseebach 15y ago
The value is in the bit where the client also have to fetch 15 JS and CSS files from you. Getting those from Google instead is very likely to be faster. Also, they may very well minify and compress them, and lump them in with other sites that uses the same (ie. automatically making you use http://code.google.com/apis/libraries/ http://code.google.com/apis/libraries/).
Also, if you get a prominent link to your somewhere, this services will very likely be able to discover that all the searches for "cute kitten" returns the same page, and cache the results for you, keeping your server from crashing.
Yes, sure you and I know how to make a site fast by employing these techniques, but (a) not everyone does (b) why should we spend time on this if Google can do it for us?
- apgwoz 15y agoI can already use a shared jQuery or other library, I don't need Page Speed for that, though if Google can discover that the library I have is actually exactly the same as one it hosts on it's own CDN, then of course it can rewrite my page to make use of the CDN one. My javascript on the other hand is (likely) not useful to someone else's site, and therefore that example isn't a very effective use. I just remembered that Page Speed also has an image optimizer, which could be very effective here. The search example obviously has some flaws, because yes, caching is likely to be effective at least for a few seconds (think Twitter search). What happens in the case of protected resources where a session cookie or XSRF token make the page uncacheable?