wordpress网站上的高TTFB

我在wordpress网站上遇到了一个问题，我的TTFB大约是8秒

我的服务器是debian 7，带有apache、3go RAM，托管在gandi cloud IAAS上

如果我安装了一个像SuperCache这样的缓存模块，当页面在缓存中时，一切正常，页面加载速度非常快

但是对于一个新页面，或者在缓存模块被禁用的情况下，加载需要8..9秒

我的apache2.conf的配置如下：

 <IfModule mpm_prefork_module>
     StartServers          1
     MinSpareServers       1
     MaxSpareServers       3
     MaxClients            10
     MaxRequestsPerChild   3000
 </IfModule>

<IfModule mpm_worker_module>
    StartServers          1
    MinSpareThreads       5
    MaxSpareThreads      15
    ThreadLimit          25
    ThreadsPerChild       5
    MaxClients           25
    MaxRequestsPerChild 200
</IfModule>

该站点的url为

---

如果有人有了主意。。。非常感谢。

这就是WordPress的本质。代码和页面生成通常是可怕的

你的TTFB不是问题所在。对于WordPress来说，这是相当好的

服务器不缓存任何静态内容 未指定字符集 保持活动状态未启用 你的服务器速度很快，18766667字节/秒。使用gzip压缩，有效速度为104249275字节/秒

基页大小：71932字节 传输速度：18766667字节/秒。 压缩：5.6倍 HTML空白：4.0% 传输字节：12949字节 HTML传输速率：104249275字节/秒。 总页面加载时间是问题所在

通常使用WP时，加载CSS和JS文件的顺序会延迟开始渲染。如果您在webpagetest.org上测试页面加载，并查看瀑布图，您将看到加载页面并开始渲染所需的大量时间

基准页第1行加载时间为562毫秒，开始渲染时间为2.789秒

请注意，第22行是一个.woff2字体文件，其起始偏移量为2.511秒

然后，开始渲染开始。这件事花了你2秒多的时间

每次浏览器运行到可以改变页面布局的资源（例如CSS和字体）时，浏览器都会重新启动渲染。同时，在浏览器解析JS时，在最后一个CSS之前加载的每个JS文件都会停止渲染

如果超级缓存为您工作，那么您必须具有静态网页。对于静态页面，您不必让WP动态生成页面

如果您需要WP来设计页面，那么复制WP呈现的页面，并将其用作静态页面

这可能需要您将链接从一个页面更改为另一个页面

然后，您还可以更正中资源的顺序，将所有CSS和字体移到任何JS之上，并将适当的JS移到页面底部

运行Google PageSpeed Insights

并按照链接消除折叠内容上方的渲染阻塞JavaScript和CSS

您需要修复服务器配置。最好将其添加到httpd.conf中，但快速修复方法是创建一个.htaccess文件，该文件将包括以下内容：

AddCharset utf-8 .html .css .php .txt .js .svg
Header unset ETag
FileETag None
ExpiresActive On
ExpiresByType image/* A31536000
ExpiresByType text/* A2592030
ExpiresByType application/* A2592030
<FilesMatch "\.(js|xml|gz)$">
Header set Cache-Control "max-age=2592030, public"
Header append Vary: Accept-Encoding
</FilesMatch>
<ifModule mod_headers.c>
Header set Connection keep-Alive
</ifModule>
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|svg|swf)(\.gz)?$">
Header set Cache-Control "max-age=31536000, public"
</FilesMatch>
<FilesMatch "\.(html|js|css|xml|gz)$">
Header set Cache-Control "max-age=86401, public"
Header append Vary: Accept-Encoding
</FilesMatch>

---

当用户看到某个内容并看到完整的页面时，您的站点有很长的时间开始呈现

1您正在加载大量CSS，这会延迟渲染。大部分都是193KB的压缩！看起来像是支持swipebox的引导和库。你真的需要这些吗？例如：

您是否可以使用更少或更少的Sass将引导降到您真正需要的子集？ 您在哪里使用swipebox？我没有在头版看到它。如果你正在使用一个WordPress插件来添加它，那么许多插件只需将CSS和JS添加到每个页面，不管它们是否在该页面上使用。这意味着每个人都会受到性能惩罚，即使大多数人永远不会看到灯箱。有一些方法可以在不使用插件的页面上禁用插件。 2您正在加载很多Javascript文件，可能来自插件。这些也会延迟渲染。如果可以将它们限制在所需的页面或使其异步，则它们不会延迟渲染，但仍会降低页面速度

3使用SSL/TLS会给您带来很大的延迟。你真的每一页都需要这个吗？两项建议：

仅在用户要输入敏感信息的真正需要SSL/TLS的页面上使用SSL/TLS。 如果确实需要使用SSL/TLS，请将所有静态内容CSS、JS和图像移动到CDN。这样，静态文件就不会受到SSL/TLS惩罚。

---

你用了很多小图片。考虑使用雪碧代替。这样一来，只需下载少量图像，在使用SSL/TLS时节省了大量HTTP连接和额外的惩罚。

为什么要取消ETag？@FaisalAshfaq生成Etag哈希的计算量大、过时且不必要，最大年限是最有效的，然后是ExpiresBy。同意，但Etag用于比较，当匹配时，资产从缓存中提供，状态代码为304 not modified。忽略这一点将导致从服务器而不是缓存中获取资产。

AddCharset utf-8 .html .css .php .txt .js .svg
Header unset ETag
FileETag None
ExpiresActive On
ExpiresByType image/* A31536000
ExpiresByType text/* A2592030
ExpiresByType application/* A2592030
<FilesMatch "\.(js|xml|gz)$">
Header set Cache-Control "max-age=2592030, public"
Header append Vary: Accept-Encoding
</FilesMatch>
<ifModule mod_headers.c>
Header set Connection keep-Alive
</ifModule>
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|svg|swf)(\.gz)?$">
Header set Cache-Control "max-age=31536000, public"
</FilesMatch>
<FilesMatch "\.(html|js|css|xml|gz)$">
Header set Cache-Control "max-age=86401, public"
Header append Vary: Accept-Encoding
</FilesMatch>