Problem with bookface 1.6 on iPad Pro


Hi , @Pygoscelis Papua
I want to report a problem with #Bookface V1.6 , on my iPad Pro 11 inch, (tested with Safari and Brave browser) Page loading is extremely slow , I had to change the default templates #frio, I don't know what caused it . With the default template I have no problem . If you want I can do some tests
in reply to Anomaly

@Anomaly sorry for the late reply, this is the first time in a couple days I've been able to get into the Friendica instance I'm on.

I have some questions:
1. Was there no problem with v1.5 only since v1.6?
2. Does it matter if it is the "Auto Color," "Light" or "Dark" version of Bookface?
3. Is it possible it was a server issue? Is it still happening?

On iOS devices it shouldn't matter what browser you use, they all have to use the Safari web engine. If I recall the browser cache on iOS has a limit of 5MB per site, with a total of about 50MB for all sites (including PWAs) because that's the limit per app in the CachStorage API. Running up against that limit can slow things down.

The Bookface stylesheets aren't minified yet but even so the "Auto Color" one, which is 2x the size of the others, still only clocks in at 180KB. The thing that slows stuff down is the browser needing to parse the stylesheet, since it effectively overrides just about everything in Frio. Arguably Bookface should be it's own theme rather than a Frio scheme, but I just haven't had time to work on turning it into a stand-alone theme.

in reply to Pygoscelis Papua

Hi @Pygoscelis Papua
No problem , thanks for the reply

Was there no problem with v1.5 only since v1.6?


Yes with version 1.6 it gives me problems on iPad , I've currently solved the problem by installing version 1.5, it works fine, I think I'll keep this one

Is it possible it was a server issue? Is it still happening?


In the friendica log file I have no errors

Does it matter if it is the "Auto Color," "Light" or "Dark" version of Bookface?


any template I set gave me problems


The problem is that it takes about 7/8 seconds to load the menu bar

With version 1.5 loading is instant

in reply to Anomaly

@Anomaly Yes, very strange. I can't figure out what could be causing this. There isn't that much difference between v1.5 and v1.6 and really nothing specific to the second toolbar.

In my testing I'm not seeing the several seconds delay you are, only a couple of seconds. But that is still a noticeable difference from v1.5.

I ran a comparison on the two versions and one-by-one deleted/changed each diff in 1.6 and nothing I did ever got rid of the delay. I'll keep trying to figure out what's causing it, but right now I'm stumped.

in reply to Anomaly

@Anomaly Ok, so I think I finally tracked down what was causing the problem. Safari seems to choke on parsing this particular complex CSS rule that is in v1.6 but no v1.5:

body.mod-profile aside:not(:has(*)) + #content {
	margin-top: 0;
}

And I'm pretty sure it's a stylesheet parsing issue because this is inside of an @supports{} inside of a @media{} query that it never actually uses in landscape orientation on an iPad and it doesn't appear to matter whether you're on a profile page either. But Safari apparently scratches its head trying to figure that out every time it needs to parse the main stylesheet and it happens to happen when the secondary toolbar is trying to load, primarily on the "Network" page.

As I said I was seeing a delay in Safari on macOS as well, but only for 2-3 seconds not the several seconds you were seeing. It was several seconds on my iPad Mini. Desktop Firefox and Chrome and Chrome Mobile on my Android phone were loading the toolbar normally. So this appears to be a Safari (or at least WebKit) specific issue.

My only solution right now is to try and prevent Safari from parsing that rule. The only method that seems to prevent that is to put it inside a @supports{} query that excludes Safari but lets the other browsers still run that rule:

@supports not (background: -webkit-named-image(i)) {
	body.mod-profile aside:not(:has(*)) + #content {
		margin-top: 0;
	}
}

Seems to do the trick. On multiple cache-less reloads at most I saw a 1 second delay in the toolbar appearing.

You can either edit your 1.6 to wrap that rule or download the Bookface "main" repository from my GitLab which incorporates this potential fix.

This entry was edited (Saturday, May 3, 2025, 8:19 PM)
in reply to Pygoscelis Papua

@Pygoscelis Papua

You can either edit your 1.6 to wrap that rule or download the Bookface "main" repository from my GitLab which incorporates this potential fix.


I just installed it from "main" repository , tested it for a few minutes and it's fine, I don't have any more lag , I will continue to do more tests , thanks again

2-3 seconds not the several seconds you were seeing


on my iPad it was 5/6 seconds

on my Android phone were loading the toolbar normally.


On my Android device with GrapheneOS I never had any problems, the same on my laptop with Fedora Workstation. i hate apple 😅