That's because your browser (Chrome or any other) stores some files in its cache and does not ask them again to the server (Ubooquity) until a certain period expires.

Among them are the CSS files, which determine the layout of the text and images (and chich are changed on Ubooquity side when you configure a different cover size).

A forced page refresh just tells your browser to ask all the files again.That's the expected behaviour.

What happens if you force refresh the page in your browser ? (Ctrl + F5)

Do you have the same problem with the default theme ?

Sorry I missed your first message.

I found the bug, it will be fixed in the next release.

I'm using JUnrar, which is the only Java RAR librtary I know about. And as far as I know it doesn't handle comments.

1- since you go through the first pages of the comic quite quickly, I'm not sure loading 4 pages ahead instead of 2 would change anything (sinc you read them faster than Ubooquity can load them anyway).

2- already planned, but it takes time to implement

Ubooquity 2.1.1 released with CBI support for CBZ (not CBR, as I couldn't access the comment for this type of archive).

Deactivating the server-side bookmarks was a way to give me information on your problem. I would of course prefer to understand and fix it.

Now I know the slowness is caused by the bookmark saving to the server. I need to find why.

If you go back to your initial configuration (uncheck "Store bookmarks in cookies instead of the server"), does the slowness happens for files other than PDF shared in the "books" section ? (as opposed to PDF shared in the "comics" section, CBZ, CBR and Epubs) ?

Also, can you check if you have errors in your logs when the slowness happens ?

For now I prefer to focus on other features than working on a closed, undocumented format.

As a workaround you can quite easily convert your mobi files to epubs using Calibre for instance.