We’ve a requirement to display a few images on a Visualforce page.

In the current setup, we’ve each of these images stored in individual static resources. The image names are stored in a custom object to facilitate dynamic rendering of images on the Visualforce page. The controller pulls the relevant image name for the logged in user from the custom object, and uses the below markup to display the image on the page.

<apex:image url=“/resource/{!imageName}” />

We want to move to the recommended approach of using $Resource.imageName as a merge field, but have challenges there as the image name has to come from the controller. So we’re thinking of combining all the images into one zip file. This way we’ve two birds in one shot, fewer static resources to manage and can proudly say we follow the "recommended approach” in coding. 😃

But before doing that, we’ve a couple of questions that we cannot seem to find an answer for:

1. Why $Resource?

What are the advantages of using the merge field against the URL, other than being the recommended approach? It seems like when we’re using the URL approach, Salesforce is intelligent enough to serve the correct resource even after an update changed the timestamp on the resource.

2. URL Approach - with or without timestamp?

As mentioned earlier, the current implementation works fine now. But as per documentation, it should be <apex:image url=“/resource/<timestamp>/{!imageName}” /> instead. What is the relevance of the timestamp component of the URL? What are the impacts of excluding this timestamp?

Wondering what the experts here thinks about these.

1 Answer 1


Why $Resource?

Sure you are free to use relative path and it will work but it will not work if you are packaging the static resource as a part of managed package because then you need namespace in the path .

Instead using $Resource takes care of handling namespace for you .

URL Approach - with or without timestamp?

The timestamp is essentially a version. Each new upload revision the timestamp. Without it, browsers cache the resource and each subsequent page load will pull from cache. Even if you upload a new version, any user who has already hit your page will have the cached version and the only way for them to get the new version is to dump their cache.

  • Thank you for your time on this. Agreed that the URL with timestamp may deliver an old resource from the cache. The behavior seems to be the same when we use the URL without the timestamp as well. So the timestamp part in the URL seems kind of irrelevant. What I’m trying to understand is, whether there are any scenarios that absolutely requires a developer to use the timestamp in the URL. Any insights on this?
    – BuddWhite
    Nov 7, 2016 at 1:25
  • So you can go without timestamp but lets say a new version of the static resource is uploaded ,its highly possible that your users will still see older versions due to browser caching .While adding a time stamp prevents this and only latest is rendered .Hope that helps you Nov 7, 2016 at 1:28
  • So that means every time we update the static resource, we also need to update the URL in the VF page with the new timestamp to ensure the latest version is rendered. Otherwise it might still pull up the image from the cache. Hmm, looks like one more reason to go with the $Resource approach.
    – BuddWhite
    Nov 7, 2016 at 1:55
  • That's correct ! Yes another reason to use $resource Nov 7, 2016 at 2:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .