Please help: Very slow "Start Render" time

As you can see in the test result, my “Start Render” time is very bad. More than five seconds. I spent more than 500 US-Dollar on Speed optimiation services but none of the “experts” could solve or at least tell me what the issue is. Why is the start render time so slow? Any help or hint would be very appreciated!

I don’t think it is the theme since that has good results:

Here’s a few things that can reduce the start render by a small amount: You are using a lot of different CSS and JS files. Try to merge them into a single file. This will avoid network round trips. The resulting file will compress better as well.

If you want to get into more complex optimization, consider if you really need all the JS files CSS resources or if they can be loaded using async or if they can be defered until after the page onload. eg: If you run your site home page through the Google PageSpeed, it says that there are a lot of render blocking JS and CSS objects. If you can make them async or defer, you should see improvements.

To test this theory, I tried to load the site with Javascript disabled. You have done a very good job where almost the whole site loads with no JS support. The only objects missing were a few menu items. If this is the case, then I’d recommend that you try adding the “async” attribute to all your JS calls. It is definitely worth a shot.

Of course, please try on a test domain and check so that you don’t impact any site functionality.

Hope this helps.
I forgot to add: Your DOM processing takes a lot of time as well. After the low hanging changes are done, you could consider if there is something to simply in your page structure. Here’s a DOM complexity report that appears to indicate the same:

Thank you for your very helpful insights. This is the stuff I expected the speed optimization guys to do it. Why they did not I don’t know. :frowning:

Anyway, since I’m not a programmer basically I have no idea how to try these things you mentioned. Is it possible to solve it via plugins? How much working hours would that be?

I’m glad it was useful!

Regarding the availability of tools / plugins, here’s what I know:

  1. Merging CSS and JS files: There are lot of plugins out there. This site has a huge list of tools available for perf optimization: Do note that you may need to merge them in right order - especially for JS files. It would be good if you can take help from developers so that dependencies are handled correctly. This can even be integrated to your build process.

As a one time job, this would be quicker. A very rough ball-park is around 20 hours of effort.

  1. Re-ordering resources: This is a bit more involved and will need your team to make the change, test it for functionality. After that, you can check for performance benefits. Ideally, you should pick the page that are most critical like home page and then work through the rest of site.

Estimating effort for this would be very hard. Please do note that this will be ongoing effort and could need constant monitoring.

Thank you. I’m working with wp-rocket right now which is already minifying and merging JS I think. But this can’t be the only reason for slow render can it? There got to be another one…

Also I just noticed that there are a lot of facebook calls albeit I’m not using facebook. Analytics seems to be slow too. Is there a way to block these facebook requests?


Comparing your old waterfall to a newer one:
it seems that you have done a better job of combining js and css files.

Just glancing at the current waterfall, if you find the spot where the start to render is and what file is around that point it’s this js file.

The page won’t start to render if that js file is at the bottom of your html. Try moving it to the top or lazy load it in some way. If you can do that my guess is that your start to render time would be about 1.5 seconds.


Thanks a lot!! That is from the mail poet newsletter plugin. Do you have any idea how I can move it?

Made another test with the plugin disabled, so the JS should be gone. But the start render time is just as slow as before. So that probably wasn’t the culprit?

Maybe it’s the icons.woff? Any way to test that? But that is in the original theme as well and that renders much faster…


I have not used wp-rocket. So I can’t comment on the kind of optimization it produces.

In the meantime, I looked at the HTML code for the home page and I had some queries. You already have a bunch of stylesheets. Yet, there is a lot of style information towards the end of your HTML document. Within this, you have definition of the ‘body’ and many other tags. Is this by design? Can this style be moved to before the tag? This must be causing delays as well since the browser can’t render until this part is parsed.

Is this because I’m using a child theme setup? Are you talking about the child theme css which is loading instead of the standard themes css? I wouldn’t know how to use it, I just implented it in wordpress like it is standard.

For articles, the start render time is even worse, more than six seconds. And I have no idea why:

Getting rid of most of the images reduces the render time but it is really just not great:

It also varies a lot - between 1-2 seconds. The demo theme setup has even more images and renders way faster. According to the author, he just as caching active on a normal shared hoster.

Hm. I’m note sure what to make of the WBP results anymore. I just tested the verge from the frankfurt server (I’m sitting in frankfurt btw) and the speed result is pretty bad.

Now, if I’m actually surfing the page, it’s super fast. So what gives? Weird.

Ok that is funny. Testing the page with Firefox instead of Chrome halves the start to render time. That seems like a pretty fast site now. What’s going on!?

I tried a run from US and can see the issue you seem to have hit. When testing from US, the pages appear to load pretty quickly.



Do you have Real User Monitoring (RUM) enabled on your site? If you do, that should give you and idea on the real user’s performance.

No, I haven’t. But with that much difference in the testing results, what is there what you can learn from these tests? I spent hundreds of dollar to get better results, still, all I had to do is switching the testing server… :frowning:

I spoke to a few people about the Wordpress and the response I have got so far is that you need to be very careful with using plugins on wordpress. Altough they exist, not every plugin is well tuned. Moreover, if you use more than one plugin, it will be hard to know the impact of how the different plugins interact. Finally, the plugins run at the time of generating response for the user. So, it should add to the overall page response time.

I know you are hard pressed to explain the situation and slowness. One of the ways to take this further is to do the following:

  1. Start with pure wordpress and no plugins. Run WPT test and note it as your benchmark metric.
  2. Start to turn on the plugins one by one and see the impact. If adding a plugin improves the performance keep it. Else disable it.

It is a trial and error situation - but, I think it will at least help you narrow down on the plugin that is causing performance issues.

It is enough to switch server region and chrome to firefox. Suddenly my render time is twice as fast. It seems like the WPT-Test isn’t just that reliable, I guess.

We ran some tests on another consulting work and found that the “start render” time on WPT is actually a reporting nuance that you need to consider.

The TTFB, as per the standard is just the time from the time request was sent to the time the first byte was received. For example, in this WPT test, the home page TTFB is 40 ms

However, the reported “First Byte” is a sum of the following:
DNS lookup + TCP connection + SSL handshake + TTFB. In the first request, this amounts to
32 + 30 + 128 + 40 = 230 ms. The reported “start render” time is 231ms.

So there are a lot of factors that could throw off your the reported value of the first byte time. However, I am not sure on why there is a variation by browser to that large extent.

I’d say that all that’s left now is for you to implement either SPDY or HTTP2 to improve the parallel downloading of files, and lose the wasted latency time on every file.

Alternatively you could look at combining css / js and using image sprites to reduce the number of files to be downloaded.

That is a server thing isn’t it?