Verry long First Byte Time (18 seconds)

ThemeBurn SupportForumsOpenCart ThemesPavilion OpenCart ThemeVerry long First Byte Time (18 seconds)

This topic has been marked as not resolved.

Hello ThemeBurn,

I am realy in love with the BurnEngine theme, but for some reason I have a very long First Byte Time. I have posted a toppic on WebpageTest and got one very extensive post.

You can read this on: http://www.webpagetest.org/forums/showthread.php?tid=14218

Do you think this make sense, and should I give it a try or do you think other reasons are causing this?

My personal thougt is that the plugin: megafilterpro is causing the verry long first byte time.

I am realy intested in your opinion.

Thanks and best regards, Ultimatia

February 22, 2016 at 1:03 pm #45047

18 seconds is ridiculous, can’t imagine it’s caused by BurnEngine. Does the load time improve after you disable the megafilter pro plugin ?
Can you please share FTP credentials so we can see your php generation time ?

February 22, 2016 at 2:14 pm #45049

No, personally I also dont think BurnEngine is causing this.

18 seconds is very high and happens occasionally. Mostly the FBT is around 2 seconds (still to heigh). When I disable mega filter pro it takes around 1-1.5 second.

You can check on:

Thanks alot.

February 22, 2016 at 2:28 pm #45050

Hi, do you already know something more?

I did some test and this code lines are a part from the FBT problem I think:

<file path="catalog/view/theme/*/template/common/" name="header.tpl">
    <operation>
      <search position="before"><![CDATA[</head>]]></search>
      <add><![CDATA[
        <script type="text/javascript" src="catalog/view/javascript/mf/iscroll.js"></script>
        <script type="text/javascript" src="catalog/view/javascript/mf/mega_filter.js"></script>
        <script type="text/javascript" src="catalog/view/javascript/validate/jquery.validate.min.js"></script>
        <script type="text/javascript" src="catalog/view/javascript/validate/jquery-form.js"></script>
      ]]></add>
    </operation>
  </file>

What is the best place to add additional javascript files in BurnEngine without causing loading issues? I tried <script async > but that makes no difference.

Thanks and best regards, Ultimatia

February 23, 2016 at 2:57 pm #45076

These scripts are automatically parsed, minified and loaded asynchronously by BurnEngine. As you can see there are only two javascript files loaded – inline_xxx.js and main_xxx.js. This is the optimal non-blocking solution for script loading. If a script itself is suboptimal, an optimized loading mechanism would not make it faster. It will make it come to your browser faster in order to slow it down :)

Anyway, I don’t think that this is related to FBT, assuming that we are using this definition:

TTFB measures the duration from the user or client making an HTTP request to the first byte of the page being received by the client’s browser.

There are three components of the ‘time to first byte’ metric:

1. The time it takes for your request to propagate through the network to the web server
2. The time it takes for the web server to process the request and generate the response
3. The time it takes for the response to propagate back through the network to your browser.

I think we could ignore 1) and 3) as they are taking less than a second in most cases. This leaves us with the server generation time, which is the combination of the server speed (CPU) and the script speed (optimal coding).

We placed a ‘Page generation time’ summary in the footer of zadenkeus.nl (a manual modification of index.php file was needed). The first byte timecannot be lower than this value. It is usually about 200-300-400 milliseconds higher. Your site varies between 0.7000 (less than a second) and 3 seconds. I think with more increased load it can increase further.

What type of hosting are you using ?

February 23, 2016 at 4:21 pm #45077

Hi thanks again for all your time, effort and clarification.

I am using shared hosting, so maybe this explains the fluctuating generation times.

The guy on Webpagetest was telling this:
“You are correct, the server is NOT the problem. Your server is excellent, one of the fastest I have seen @12,550,376 Bps.”

But if you think I can try reseller hosting and see it shorts the FBT.

PS: I think that when you disable the vqmod-file: mega_filter_fix.xml the pagespeed is mutch better so I guess there are some problems with this script also.

  • This reply was modified 2975 days ago by  ultimatia.
  • This reply was modified 2975 days ago by  ultimatia.
  • This reply was modified 2975 days ago by  ultimatia.
  • This reply was modified 2975 days ago by  ultimatia.
February 23, 2016 at 4:42 pm #45078

The web server speed cannot be measured without an on-server benchmark. The Webpagetes guy most probably means the server’s network throughput, which can be fast as hell while your shop loads for 18 seconds.

When someone requests your page, your server uses its resources (CPU, RAM etc.) in order to process the OpenCart source code (this is OpenCart + theme + extensions). This is page generation time. When the page is generated, it is sent to the browser over the network and when the user receives the very first character (i.e. byte), it is called the first byte. The process of sending the generated page is the same as the process of sending a simple image or text document, when opened from your server.

After the browser receives the generated page, it forgets about the server evaluates it. This involves executing of all javascripts. They block the browser, and unblock it when finish. This is called page onload time.

So, an extension can slow down your site in two ways – when slowing down page generation time, or when blocking the browser and increasing the onload time.

So, the onload time is page generation time + the time the page needs to travel over the network + the time needed from the browser to evaluate it. This is what is measured by webpagespeedtest (+ severeal other factors, that are irrelevant to our conversation).

I think your problem is page generation time, which may be increased from megafilter pro in some degree, but I’m not sure how much, so I don’t want to blame it.

Your site is relatively big, so shared hosting may be improper. You may consider increasing the server resources – migrating to a more powerful plan or server. The CPU is the main resource that is responsible for your slow times.

February 23, 2016 at 5:04 pm #45083
Viewing 7 posts - 1 through 7 (of 7 total)
  • You must be logged in to reply to this topic.