-
juddyhopes
Hi GeneratePress Team,
I am experiencing a minor scroll lag/stutter on my 3 websites (Sites Attached) that occurs exclusively at the very top of the page (0px position) upon the initial user interaction. But other websites haven’t any such issue.
As soon as the user scrolls past the top section (roughly 100px–200px down towards the middle of the page), the scrolling immediately becomes perfectly smooth. This issue is happening globally across my posts.
—
### Technical Details:
– Theme: GeneratePress
– Page Layout: Clean Gutenberg/Block Editor layout.
– Header Setup: Completely static (The header is NOT set to sticky or fixed).—
### Troubleshooting Steps Already Taken:
To rule out external factors, I have already tested and verified that none of the following are causing the bottleneck:1. Ruled out Ads & Media: Completely removed all Google AdSense scripts and removed the top Featured Image entirely. The initialization lag still persisted.
2. Ruled out Block Plugins: Completely deactivated the GenerateBlocks plugin. The issue remained, meaning it is tied to core layout rendering rather than specific block elements.
3. Tested Dynamic CSS Print Methods: Swapped the Dynamic CSS Print Method setting in the Customizer between Inline Embedding and External File (and purged all site caches). Neither setting resolved the delay.
4. Disabled Smooth Scroll Feature: Checked the GeneratePress Customizer under General and turned off the native Smooth Scroll toggle to prevent any JavaScript scroll conflicts.
5. Applied Layout CSS Overrides: Added custom CSS (scroll-behavior: auto !important; and scroll-snap-type: none !important;) to rule out browser scroll-snapping errors, but the top-of-page delay remains.
—
### The Core Issue:
Because the header is static, it feels like a layout engine rendering bottleneck or a passive event listener script conflict running on initialization at the top of the viewport. The browser main thread seems to freeze for a split second before releasing the scroll vector.Could you please help me identify if there is an internal theme script, layout boundary constraint, or typography tracking engine calculation in GeneratePress that is causing this initial scroll friction?
Thank you for your help!
-
George
Hello,
Thanks for sharing that. To investigate, I opened Chrome DevTools on the 3rd URL you have provided, navigated to the Performance tab, clicked Record, scrolled from the very top of the page, and then stopped the recording to analyse the results.
The Performance recording points clearly to third-party scripts as the cause — specifically Google Tag Manager and Google/DoubleClick Ads, both of which are executing on the main thread during initial page load. GeneratePress itself shows 0.2ms of activity, which is negligible.
The scroll hesitation at the top is consistent with GTM firing ad tags before the browser has committed the first scroll interaction. This is a known behaviour with ad/analytics scripts and isn’t something we’re able to address from the theme side.
I’d recommend looking into:
- Loading GTM with a slight delay (e.g. on
requestIdleCallbackor after a user interaction trigger) - Reviewing your GTM container for any synchronous tags firing on page load
- Addressing the “Duplicated JavaScript” insight flagged in the recording, which adds unnecessary overhead
A performance consultant or your ad setup provider would be best placed to help optimise the script loading strategy.
- Loading GTM with a slight delay (e.g. on
-
juddyhopes
I removed GA4 tag complete and then i test the page but still lag.
One thing is important that when i scroll down to reach just after the second paragraph the site scroll smoothly and when i scroll up to reach top then again scroll lag occur.
How can i resolve this? Any recommendations?
Because our other sites other than mentioned have no issue beside these sites have Google Tag Manger and Google DoubleClick etc.
-
I checked all 3 of the sites, but I don’t see any lagging issue.
This is what I see. Let me know if I miss anything:
https://app.screencast.com/OVoIC2DLPBKKd
- You must be logged in to reply to this topic.