1

The static html pages of my project has javascript dynamically modified content and that causes FOUC (Flicker of Unstyled Content). So I made the content invisible by default and toggle display to visible after DOM ready.

The static html pages rendered very fast on my local drive, so the time gap between invisible and visible states is not obvious.

However, after the project has been integrated with WordPress and put onto remote server, the page rendering becomes a bit slower, so the time gap becomes a bit more obvious.

When I click on a hyperlink to request viewing a page, I would like WordPress to complete the redering of the page on server side and then show me the page. Waiting 1 or 2 seconds is okay. Can WP do that?

Ian Y.
  • 2,293
  • 6
  • 39
  • 55

2 Answers2

1

I would guess that the issue is your CSS not loading instantly over the network, so that there's a moment where your HTML is rendered, but your CSS hasn't loaded.

(It could also be dynamic Javascript content -- I can't speak to that without knowing more about your Wordpress installation and configuration)

Preloading your CSS isn't something Wordpress can do itself, although you should notice that after the first page load, the browser is caching your CSS and it's quicker.

If you're really concerned about it, look up some optimization techniques, such as using a fast CDN for the static stuff such as your CSS. The Yahoo! performance tips are pretty good for all website performance questions, for instance.

necaris
  • 247
  • 2
  • 11
  • Thanks @necaris. My issue is dynamically javascript added className, etc causes the FOUC. That script can be executed only after DOM ready. – Ian Y. Jun 29 '12 at 09:31
  • 1
    @ian that sounds like a conceptual problem that will always cause *some* amount of fouc. Is there no way for you to hard-code the class? – Pekka Jun 29 '12 at 09:37
  • @Pekka, but on my local drive, static html pages are rendered very fast and FOUC is not obvious. – Ian Y. Jun 29 '12 at 09:39
  • 1
    @ian yeah, but that's local... On the net, you have to anticipate occasional hiccups and latency – Pekka Jun 29 '12 at 09:40
  • @Pekka, I just uploaded all static html pages (files which haven't been made into WP) to the remote server for testing. And their rendering speeds are as fast as they are in local. So the problem is still within WP. – Ian Y. Jun 29 '12 at 10:27
  • @IanY. If it's all dynamic content that's causing it, perhaps you can hide the content by default and toggle display to visible after DOM ready, after it's been styled? – necaris Jun 30 '12 at 09:54
  • Thanks @necaris. That actually is exactly the approach I use currently. The problem is that the time gap between the invisible and visible states of the element is a bit obvious. When they were static html pages, I could barely notice the gap. – Ian Y. Jun 30 '12 at 10:15
  • @IanY. The only suggestions I have now are Wordpress caching plugins (WP-Cache, etc) or doing a fade-in on the invisible -> visible element(s). – necaris Jun 30 '12 at 10:19
  • @IanY. Could you update the question to make it a bit clearer that it's dynamic content that's causing your issues, and describe your approach? – necaris Jun 30 '12 at 10:20
1

DOM Ready fires after the entire HTML has been parsed by the browser. That is a lot more than just the base HTML file though, it needs to load, parse and execute all of the css and javascript it encounters as it goes through the HTML before it will fire the event (and in the case of WP that is usually quite a bit).

WP will tend to also be very slow to generate the HTML itself if it isn't on fast hosting (putting it on a shared hosting account is basically just begging for it to be slow). A page caching plugin like W3TC or supercache will help with the generating of the HTML but my bet is you have a lot more front-end activity gumming things up as well.

Grab a copy of "High Performance Websites" and then do some testing of the page on something like WebPagetest which will let you see the external resources (and capture video of the page loading). The book is pretty critical for any front-end engineer to understand and goes into detail on front-end performance issues.

pmeenan
  • 486
  • 3
  • 6