Menu toggle expanding to a normal menu briefly

Hi @maybenot,

Thanks for trying out PhastPress.

1. Menu toggle (desktop/iPad) displays a normal menu for a few seconds before loading. Looks unprofessional/broken. Anything I can do to stop this from happening?

This is because PhastPress delays the scripts on your page from running until after the page has rendered. You need to change your CSS so that the menu is rendered correctly before JavaScript is executed. For example, by using a media query to hide the desktop menu on mobile.

2. Performance wise, the scores go up. But load time, page size and requests are higher.

Load time as measured by GTmetrix can be higher. See the relevant question in the FAQ (“Why does PhastPress not impact the “Fully Loaded Time” measured by GTmetrix?”).

However, page size and request count should definitely be lower. Are you seeing any errors in the developer console?

3. Under PageSpeed Insights / opportunities, I have several: Defer offscreen images, Serve images in next-gen formats, Remove unused CSS, Minify CSS and Reduce server response times (TTFB).

Some of these might be caused by the same issue that is causing the page size and request count not to be lower. Let’s see if we can fix that first before moving on to these.

4. Just to double check changing the code. Google Analytics from <script async src=”https:….> to <script async data-phast-no-defer src=”https:….>, right? And for ads, I do this for each ad code?

That is correct. This will stop PhastPress from delaying the load of your ads until after the page is rendered. It should make a small difference in how quickly ads are loaded, but it might not be noticable.

So, please check if you are seeing any errors in the developer console. That might help us fix the page size/request count issue.

–Albert

Hi Albert,

Thanks for your quick response!

Ah, so the menu thing is sorted – thank you.

I read everything on the FAQ and all the questions and answers here before posting mine. I just wasn’t sure whether the high scores should be the deciding factor above all?

Here’s the most recent comparison before and after (in case it helps you help me).

PageSpeed – 59/98 -> 82/97
GTmetrix – 97%/83% 3.7s 1.18MB 38 -> 93%/96% 3.75s 1.25MB 54
Pingdom – 74 744ms 1.38MB 43 -> 79 1.24s 1.4MB 60
WebPageTest – B A A A C -> A A A A B
Test My Site – 2.6s slow -> 2.2s Average

About the errors in the developer console, these things go over my head. But I think you’re looking at error lines in red? I have none.

Does that mean nothing left there to do to improve page size and requests?

Any suggestion on PageSpeed ‘opportunities'(Mobile): Defer offscreen images (1.4s), Serve images in next-gen formats (1.05s), Remove unused CSS (0.3s), Minify CSS (0.15s) and Reduce server response times (TTFB)(0.05s)?

Thanks for confirming about Google Analytics and ads code.

Hi @maybenot,

GTmetrix – 97%/83% 3.7s 1.18MB 38 -> 93%/96% 3.75s 1.25MB 54

There is a problem here. If the page size and request count increased after activating PhastPress, something isn’t working. This needs to be debugged.

Without having a look at your site and seeing what’s actually happening, I’m not able to help you further.

If you are not willing to share publicly the URL of your site, but would allow me to have a look privately, you can contact me using the email address at the bottom of the plugin description.

–Albert

email sent, Albert – thank you very much!

For other users interested in this bug:

The main issue was due to a missing Content-Encoding header on optimized CSS/JS responses from PhastPress. This was fixed in PhastPress 1.53 by disabling compression for requests via Cloudflare, because Cloudflare does its own compression.