As @Evgeniy has already covered in his answer, in order to add HTTP response headers to resources external to your site, you need to copy these resources locally - to a server that you control - so you can send the HTTP response header as part of the HTTP response.
However, whether you should do this or not is another matter and each instance should be assessed individually. Serving a resource "locally" from your application server may not improve visitors performance. It can also reduce functionality should the apparent "static" resource be updated or if third party cookies are being used (which may or may not be desirable).
The results from GTmetrix (and other "performance" tools) should be seen as "advisory" only. A place from which to start your own site analysis. You should not implement the suggestions blindly without first assessing the implications. It is not necessarily wrong to not have "a far-future expiration date". Implementing features to simply satisfy the "automated performance tool report" is wrong.
do I have to add expire headers for other links that I have mentioned in the question.
Note that, as mentioned in comments, these resources are not without
Expires headers (and more importantly the
Cache-Control: max-age header), it's just that they are not what you might call "far-future". The
gtag/js file is cached for 15 mins and
analytics.js is cached for a "reasonable" 2 hours. Coupled with the fact that these same resources are used by many other websites then they are probably already cached by the time the visitor hits your site and the cache time might even be sufficiently long enough for these resources to remain cached for the duration of the user's visit (and if they continue to browse other websites in other tabs then the resources will get cached again anyway).
Google serves these resources pre-gzipped from a fast CDN, so it's unlikely you will be able beat the initial download time by hosting it on your own server.
StackExchange (generally considered to do the right thing when it comes to SEO/performance) requests
analytics.js directly from Google (at the URL above) and does not copy it locally.
Google themselves do not recommend serving these files locally. However, Google doesn't state "performance" as the main reason:
get access to new features and product updates as they become
available, giving you the most accurate data in your reports.
Once you go the route of serving these files locally, then maintenance can be more of an issue. For those using WordPress, there are plugins available that specifically help with automating the process of checking for updates.
Served from Amazon CloudFront CDN and gzip'd. Whilst the
Expires header is expired! The
Cache-Control: public, max-age=86400 header ensures that all remotely mainstream browsers will cache this resource for 1 day.
IMO you are unlikely to benefit from copying locally and caching any of these "resources". It is more work and could even make performance worse for your users; not better. GTmetrix (and other "tools") are meant as a guide only. Real-world user performance is what really matters.
analytics.jsfrom Google Analytics mess things up?
analytics.jsas an issue. But Google's recommendation is to keep it as it is. support.google.com/analytics/answer/1032389?hl=en
Cache-Control: max-age) header - it's just that they aren't "far-future" - which would seem to be intentional. (Note that Google uses content negotiation and sends a pre-gzip'd response if accepted - are you doing this?) Hosting the file locally does (slightly) increase load on your server and will not necessarily improve download performance due to the browsers number-of-connections-per-host limitation (as well as your server's).