Third option - take the original image, create a second container field that creates a much smaller thumbnail and then use that for display in the lightbox. Encode the thumbnail and things are much faster.
Here is an additional thought:
In addition to using the thumbnail approach, I wonder this might also benefit from a hybrid approach where, as you dynamically build the HTML, you use the VerifyContainer function to determine whether or not you still have a correct file path to the externally stored image?
If VerifiyContainer( thumbnail_container_field ) returns True, you could set the image src to the appropriate calculated/stored file path.
If VerifiyContainer( thumbnail_container_field ) returns False, you could fall back to the stored base64 data of the encoded thumbnail.
I really could not say whether the extra complexity that this would add would be worth any savings in overhead -- I wouldn't be surprised if, by using the thumbnail approach, you already have the problem solved.
It just occurred to me that using VerifyContainer may very well have more overhead than would be desireable, since it might be doing something like performing a hash on the externally stored data.
Assuming that this idea has any practical use, it might be better to use a simple container attribute that returns a valid value if and only if the external data is still at its path.
Perhaps filesize or filename?
Apologies for not thinking it this far through earlier,
It's possible that you might be able to automate getting a smaller thumbnail graphic to store with a little creative scripting. Then you don't necessarilly need to store the base64 but could be generated on the fly with calculations, but might be faster with stored text.
I imagine the generated html with arbitrarily large images as base64 could well be inefficient and actually increase the size of the page to be displayed, so I think your plan of storing thumbnails is probably a good one.
Forgive me if I'm on the wrong track here, but with the new ways FM handles containers in FM12/13, isn't use of a web viewer unnecessary? And also storing a thumbnail as well as a larger version of the same image? FM will generate whatever thumbnail is required for a given layout each time it is called for. If you haven't looked into this I suggest you do so.
Having seen what he is using it for WebViewer is the best way to go. DZ is actually displaying multiple photos in a sort of collage, that is dynamic. It's actually very cool.
Of course I am very late to this party, and have the advantage of the latest and greatest version of Filemaker. But in case anyone is like me and is just now trying to do something similar to the OP:
I found that, perhaps somewhat surprisingly, you can put GetThumbnail( ) inside FM's native Base64( sourceField ).. mine looks like this: Base64Encode ( GetThumbnail ( TableName::ContainerField ; 100 ; 100 ) ).. pretty sweet!