Make image browsing (the film viewer) faster by preloading the following page's image
Currently, if you're looking for an ancestor in an unindexed collection, you might load page 1, look for your ancestor, click "next page", wait a few seconds for page 2 to load, look for your ancestor again, etc.
However, what if you didn't have to wait a few seconds between each page load?
HTML has a few options for preloading assets. See preconnect, prefetch, preload, and prerender on https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types, all of which have varying browser support and different nuances.
With preloading enabled, while I'm looking for my ancestor on page 1, my browser can be downloading the image of page 2 in the background. When I switch to page 2, I immediately see the image because it was already downloaded. In the meantime, page 3 is now being downloaded in the background, etc.
If a user already knows what image they want to see, e.g. an image linked from the Sources tab of a person's profile, then this doubles the image bandwidth both for the user and FamilySearch.
However, if the user doesn't know what image they want to see, e.g. they're browsing N pages in a collection to find their ancestor, the bandwidth required is N+1, i.e., one more page is loaded than is needed.
There are some tradeoffs to consider for sure, but I think this could really speed up image browsing and ancestor finding on unindexed records.
Comments
-
Except half the time, I'm working my way backwards -- for example, if I'm looking for a marriage based on the birthdate of the first known child. Or I may be jumping around: if I'm looking for an event in 1881, and the film covers 1876 to 1890 in 920 images, I may jump to image 300 to start; if that turns out to be 1880, I may try image 400 next, and so on.
I regularly browse through several hundred images in an evening. I'm not sure how much of that my browser hangs on to and for how long; in particular, I don't know if your n+1 figure is accurate.
1 -
Hi Julia, good point about browsing back. If it's worth preloading the subsequent image, it's probably also worth preloading the prior image, since browsing can happen forward and backward.
I can expand on those figures a bit.
If you browse e.g. 300 images linearly, the N+1 figure should be approximately accurate, i.e. you will have loaded 301 images, or possibly 302 if including the prior image.
If you browse directly to 300 images (e.g. in sources) then the figure would be N*2 (or N*3 if preloading the prior page), so you will have loaded 600 or 900 images even though you only looked at 300, since the pages weren't adjacent.
If you're doing a search in a collection, like checking image 300, then jumping to image 400, then jumping back to 350, the figure would be somewhere between N+1 and N*2 (or N+2 and N*3 if preloading prior images).
For users on mobile devices or with pay-as-you-go ISPs, this might be unwanted. For people with uncapped bandwidth, or e.g. in FamilySearch libraries, the speed up might be very desirable.
0 -
But remember that this idea would require FamilySearch's servers to do more work. If their existing servers cannot handle this, they would have to spend thousands if not millions of dollars on new equipment. With all due respect, I think most FS users would rather that FS spend that money on record acquisition, indexing and digitization rather than making images load a fraction of a second faster.
0 -
While I'm assuming this would not require millions of dollars in additional bandwidth or server costs, only the FamilySearch team will know that for sure and can decide what they want to do. I simply want to bring up the idea for consideration.
One helpful thing is that bandwidth and server costs get cheaper every year, while volunteer labor may or may not grow over time. So it could be that the incremental server costs multiply the efforts of the finite volunteer labor and are worth the cost.
One other consideration is that speed improvements aren't just a convenience but make a real difference to user engagement with a site. This study shows that a 100ms improvement in site speed can increase revenue for commercial sites and increase engagement with information sites:
I imagine the parallel for FamilySearch image viewing is that an increase in page speed could be the difference on the margins between some users choosing and not choosing to browse through images at all.
For users with uncapped bandwidth, but who are distant from FamilySearch servers and therefore experience high latency -- I'm imagining an Australian user with high-speed Internet, assuming there aren't FamilySearch servers in Australia, but maybe there are -- the user experience improvement could be profound.
0 -
This link didn't work before:
0