Advice on Speed, Linked Images

I am working on a book that is based on a blog. It has 17,000 words and about 400 images. As you can guess, things can be slow at times.

I’m considered replacing most or all of the images with links. This would take a lot of work-- do you think it would be worth it?

I would keep the images in the scrivener folder. Are there any issues/dangers in working with linked rather than embedded images.

By the way “Edit/Insert/Image Linked to File…” is wrong. That would mean that you want to find an image that is linked to a file and insert it. Better might be: “Edit/Insert/Image (as Link)…” or “Edit/Insert/Image Link…”

I’ll defer to others on your question as to risks of using links.

Possible alternative… split the items containing multiple images into smaller items containing fewer images. The smaller items will be more responsive when dealt with individually. You will still be able to view several/all items concatenated together (referred to as a ‘scrivening’ view) and to publish them together. Viewing more than one or a few of the items at a time may still prove slow.

As already suggested, loading fewer image files at a time will help with speed issues. Reducing the file size of images will also help significantly, and this is where the linked images would be useful, as you can initially use lower quality placeholder graphics in the project and then swap them out for the full quality images when you compile.

From your note, it sounds like you may be unclear on how the linked images work. This isn’t going to appear as a text link in your document while you’re working; you’ll still see the graphic in the editor, but rather than being embedded the image will be called from another file location. As explained in the manual’s section on linked inline images,

So for instance you can create the link pointing to a thumbnail version of the image at …\Documents\BookImages\example.png, speeding up load times when you work in the project, then when you’re ready to compile, swap the “BookImages” folder of thumbnails for another one containing the high resolution versions. When the compile process follows the link to grab the file, it will then incorporate the better quality picture.

I’m not sure if this is what you mean, but don’t store the images in the Scrivener project folder itself. Create a separate folder as a sibling to the project .scriv folder. You can keep both of those in another folder if you want, so all your related material is together, but you don’t want to put external files into the project folder or otherwise muck about in there, as it risks corrupting the project.

Thanks for the help.

The project is already split up into about 40 text documents, and there are no speed issues when actually editing.

Here are two examples of the speed issues I’m talking about:

  1. If I click on the main “Manuscript” folder, there is a delay of 15 seconds.

  2. Backup takes 27 seconds.

I figure that those two delays should go down to almost zero if I link to the images, yes? Also, saving should be faster.

Thanks for the tip on where to have the image folder. That’s actually how I’ve done it, I just described it incorrectly.

Backup will go faster, since the images will not be included inside the project folder and therefore zipping it will not take as long. Loading the complete manuscript in Scrivenings will still need to access and load the images, so this won’t automatically be significantly faster, but by using the lower quality, smaller-file-size images when working you’ll be able to speed this up since the images themselves will then be faster to load.

You could also deliberately break the links, i.e. link to all the high quality files, then move the folder holding those files. Scrivener will then display an unknown image icon in place of the proper file, but this should be quicker to load since it would be the same file repeatedly and not a very big one. Then when you compile, just set the name of the image file back to what it should be so all the images are found and inserted.

Great ideas, thanks.