My thinking was that there is always a possibility that the image was only temporarily unavailable due to network traffic or whatever. If this is being used along with users uploading images, then perhaps the upload hadn't finished.
Most reasonable folks won't try too many times with a bad image, and it takes minimal server side resources anyway (depending upon what URL is entered, the server may not even need to get involved, and a 404 or other error is generally very low overhead), it is the user's browser that attempts to load the image.
I felt that there was no harm in allowing repeated validation of good images (they should now be cached on the user end anyway, so not affect the server much), but depending upon what this is used for, that could/should be changed.
For first time and previously good images, it currently only checks to see if the image is being checked, so as not to continually try to load it if it is already in the process of being loaded.
Once submitted by the user, the submit button is disabled until some result is determined.
Regardless of these various considerations, reloading the page can erase all stored information. A cookie could be used to maintain it, but with a lot of images, this could overflow the browser's cookie buffer, and the user may always clear or turn off cookies. If you want something more robust in that regard, you will need to use a server side language.
And, of course, with javascript disabled, the form will always submit, so if this is somehow crucial - again a server side language must be used.

