回声导致大字符串

Question

所以基本上我在内部应用程序中有一个部分允许用户通过Summernote.JS修改/编辑HTML。

我面临的问题是一个荒谬的加载时间，我似乎只在Chrome中体验过。

正在编辑的HTML内容的长度为150252，因为有base64内嵌图像。加载时间如下..

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

以下是完整刷新后Chrome加载时间的图片。

有趣的是，当我删除上述内容的回声时，页面加载即时

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

现在我发现了这个old bug on PHP.net（经过一些认真的搜索lol 之后），它说PHP的echo通过TCP / IP处理浏览器的数据缓存非常糟糕，因为{ {3}}

如果没有将内容保存到临时文件并使用Nagle Algorithm来获取内容（确实会返回原始性能），我还能做些什么来解决Chrome中的这个问题？块输出数据？没有过度复杂化它的过程。

Answer 1

我似乎找到了这个的根本原因。经过一些挖掘和内容操作后，很明显它是由Base64图像引起的。删除后，页面加载时间恢复正常。

现在在研究之后详细阐述这个问题。事实证明Chrome已经在Chromium（ ^{Reference (Issue #69227)} ）中出现了这个错误一段时间了。由于base64图像在一行中，因此单线跨度限制为2^16，这超出了我的base64图像。

在某些字符限制后，将图像切换到新行，并将加载时间从~34 seconds降低到~17 seconds。我创建了一个类似于此的函数，它适当地拆分字符串：

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

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

^{显然必须找出合适的$chunkSize。}

诀窍是弄清楚如何获取base64数据，因为HTML内容的其余部分可以满足需要。

另一种替代解决方案是将所述base64转换为blob（ ^{Reference SO Question} ）。

通过查看Atom中与此确切问题相关的this bug，您可以更好地了解此错误。