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.
https://www.googletagmanager.com/gtag/js?id=UA-49812165-2
https://www.google-analytics.com/analytics.js
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:
Referencing the JavaScript file from Google's servers ensures that you
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.
https://www.trustedsite.com/rpc/ajax?do=tmjs-visit&host=surf2ship.com&rand=1565102041274
This doesn't appear to be a static resource! (Maybe GTmetrix is fooled by the text/javascript response?) The response varies between requests and sets a (3rd party) cookie for 6 days. Copying this locally and caching would serve no purpose and possibly break functionality. (Or maybe you don't need it at all?)
https://cdn.ywxi.net/meter/surf2ship.com/105.png
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.
Conclusion
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.js
from Google Analytics mess things up?analytics.js
as an issue. But Google's recommendation is to keep it as it is. support.google.com/analytics/answer/1032389?hl=enExpires
(and cruciallyCache-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).