Leverage Browser Caching for third party resources

As @TimFountain says, you have "no control" over resources served from a third party. The request goes to the third party server, not your server - so any code you place on your server is simply never processed when the third party resource is requested.

Google Analytics and Tag Manager are served from Google's servers. Only Google controls Google's servers!

However, if Google has decided not to cache these resources then there may be a very good reason why it has chosen not to do so. Not everything should be cached.

Attempting to implement caching on these "Google" resources (perhaps by serving these resources from your own server instead - not recommended) - whilst satisfying the PageSpeed test - could have a negative effect on your user experience and Analytics data. The PageSpeed tool is a guide only. You shouldn't blindly accept the recommendations.

This question over on StackOverflow specifically discusses Google Analytics and PageSpeed Insights:

• https://stackoverflow.com/questions/29162881/pagespeed-insights-99-100-because-of-google-analytics-how-can-i-cache-ga

Your htaccess rules will only affect assets served from your server. There is nothing you can do to affect caching of assets served from third party servers - you have no control over these.

I'm replying after a year, so by the time, you might have already fixed this issue.

I was also getting the same points, but that's for the third party resources other than Google Analytics and Tag Manager.

I applied Leverage Browser Caching plus also applied resource prioritization methods to fix this issue. Here is the brief.

There are four resource prioritization methods:

Preload<link rel="preload"> informs the browser that a resource is needed as part of the current navigation, and that it should start getting fetched as soon as possible.

<link rel="preload" as="script" href="super-important.js">
<link rel="preload" as="style" href="critical.css">

PreConnect <link rel="preconnect"> informs the browser that your page intends to establish a connection to another origin, and that you’d like the process to start as soon as possible.

<link rel="preconnect" href="https://example.com">

dns-prefetch There’s actually another <link> type related to connections: <link rel="dns-prefetch">. This handles the DNS lookup only, so it’s a small subset of <link rel="preconnect">, but it’s got wider browser support, so it may serve as a nice fallback. You use it the exact same way:

<link rel="dns-prefetch" href="https://example.com">

Prefetch <link rel="prefetch"> is somewhat different from <link rel="preload"> and <link rel="preconnect">, in that it doesn’t try to make something critical happen faster; instead, it tries to make something non-critical happen earlier, if there’s a chance.

It does this by informing the browser of a resource that is expected to be needed as part of a future navigation or user interaction, for example, something that might be needed later, if the user takes the action we’re expecting. These resources are fetched at the Lowest priority in Chrome, when the current page is done loading and there’s bandwidth available.

<link rel="prefetch" href="page-2.html">

For your issue, if you have other non-critical CSS, JS resource , then you might like to use <rel=prefetch> in your HTML.

You can read in details from here: Resource Prioritization – Getting the Browser to Help You