1

So basically I have a section within an internal application which allows users to modify/edit HTML through Summernote.JS.

The issue I'm facing is a ridiculous load time which I only seem to experience within Chrome.

The HTML content that's being edited has a length of 150252 as there are base64 inline images. The load times are as follows..

Chrome (Version 51.0.2704.106 m):               39.53 seconds
Firefox (Version 43.0.1):                       2.08 seconds (onload: 2.74s) - 629.8KB
Internet Explorer (Version 11.0.9600.17843):   ~2.8 seconds

Below is an image of the Chrome load times on a complete refresh.

Chrome Load


The funny thing is, when I remove the echo of the above content, the page load's instantaneously

<textarea id="content" name="content" placeholder="Simply enter the section content below.."><?php echo $this->section->section; ?></textarea>

Now I've found this old bug on PHP.net (after some serious searching lol) which says that PHP's echo handles the data buffering to the browser via TCP/IP VERY poorly due to the Nagle Algorithm.

Short of saving the content to a temporary file and using readfile() to fetch the content (which does return the original performance), what else could I do to fix this issue within chrome? Chunk the output data? Without over complicating the process of it.

Darren
  • 13,050
  • 4
  • 41
  • 79
  • It is chrome's spell checker that you may blame. Disable it (in settings -> languages -> language and input settings -> checkbox in the bottom) and tell if there is any difference in performance? – zerkms Jul 05 '16 at 03:36
  • @zerkms only marginal performance increase - tests vary from `22 seconds` - `34 seconds` – Darren Jul 05 '16 at 03:43
  • 1
    @zerkms Turns out - it's a Chrome bug when a span/string is longer than `2^16`, causing it to translate poorly to view – Darren Jul 06 '16 at 03:26

1 Answers1

1

I seem to have found the root cause of this. After some digging and content manipulation, it's apparent that it was due to a Base64 image. Once removed, the page load time was brought back to normal.

Now to elaborate on the issue, after researching it. It turns out that Chrome has had this bug within Chromium (Reference (Issue #69227)) for some time now. Since a base64 image is in a single line, the chromium single line span limit is 2^16, which my base64 image exceeded.

Chopping up the image into new lines here and there after certain character limits managed to drop the load times from ~34 seconds down to ~17 seconds. I've created a function similar to this, which splits the string appropriately:

function __chunk($string, $chunkSize = 40) {
    $splitString = str_split($string, $chunkSize);

    foreach($splitString as $chunk) {
        echo $chunk . "\n";
    }
}

Will obviously have to figure out an appropriate $chunkSize.

The trick is to just figure out how to fetch the base64 data as the rest of the HTML content does what it needs to.

Another alternative solution would be to convert said base64 to a blob (Reference SO Question).

You can gain a better understanding on this error by checking out this bug found in Atom which relates to this exact issue.

Community
  • 1
  • 1
Darren
  • 13,050
  • 4
  • 41
  • 79