如果您想了解在WordPress上使用https时,TTFB速度较慢,但已多次优化和wordpresstdk的知识,那么本篇文章将是您的不二之选。我们将深入剖析在WordPress上使用https时,
如果您想了解在 WordPress 上使用 https 时,TTFB 速度较慢,但已多次优化和wordpress tdk的知识,那么本篇文章将是您的不二之选。我们将深入剖析在 WordPress 上使用 https 时,TTFB 速度较慢,但已多次优化的各个方面,并为您解答wordpress tdk的疑在这篇文章中,我们将为您介绍在 WordPress 上使用 https 时,TTFB 速度较慢,但已多次优化的相关知识,同时也会详细的解释wordpress tdk的运用方法,并给出实际的案例分析,希望能帮助到您!
本文目录一览:- 在 WordPress 上使用 https 时,TTFB 速度较慢,但已多次优化(wordpress tdk)
- https://github.com/a-jie/angular-infinite-list例子:angular-infinite-list 地址:https://github.com/a-jie/angular-infinite-list例子:ASP.NET Core 高 TTFB(超过 5 秒)首次访问该站点
- asp.net – Azure网站上脚本/样式的长时间等待(TTFB)时间
- Django + Nginx + Gunicorn - 为什么我的 TTFB 这么高?
在 WordPress 上使用 https 时,TTFB 速度较慢,但已多次优化(wordpress tdk)
如何解决在 WordPress 上使用 https 时,TTFB 速度较慢,但已多次优化
我的 wordpress 上的 TTFB 有问题。第一次在浏览器上加载总是很慢,多次重新加载后,TTFB仍然超过600ms。 这是一些信息:
- 我的网站:https://passioshop.com/
- 使用 Contabo.com VPS:6 个 vcpu 内核、16 GB RAM、400 GB SSD
- 使用 Cloudflare:
- 缓存级别:标准
- 缓存 TTL:最大时间
- 激活:自动缩小、brotli、始终在线、HTTP/3(带 QUIC)、0-RTT...
- 不使用火箭装载机
- 优化 wordpress:
- 使用 WP-Optimize:压缩图像、页面缓存,不使用 Minify 和 Combined,因为我想尽可能快地呈现页面。
- 使用资产清理:禁用所有未使用的脚本和 CSS,尤其是 WooCommerce、Elementor。禁用 Emojis、oEmbed、Dashicons、Gutenberg、XML-RPC...
- 优化 WHM:https://www.pakistanwebserver.com/hosting-tutorial/optimize-wordpress-better-performance-cpanel-hosting/
- 更新和优化 MysqL:使用 MariaDB、256MB 查询缓存...
但结果只影响到 TTLB 而不是 TTFB:
- 使用这个命令: curl -o /dev/null -w "Connect: %{time_connect} TTFB: %{time_starttransfer} Total time: %{time_total} \\n" https://passioshop.com 。
我注意到,TTFB:
- 使用 HTTP 时:0.016s
- 首次使用 HTTPS:2.799 秒
- 下一次,使用 HTTPS:0.209 秒
- 在浏览器的检查中:
这是第一次在浏览器上加载:
而下一次,尤其是加载像 https://passioshop.com/test.html 这样的纯文本时,它仍然在 500 毫秒以上:
我在 Google PageSpeed Insights 中几乎得了 100 分:
请有人帮我解决这个问题。 任何提示或如何找到原因都可能对我有很大帮助! 感谢您的帮助。
解决方法
静态文件在大约 500 毫秒内呈现的事实意味着问题根本不在于 WordPress。我建议尝试做以下事情:
- 完全禁用 Cloudflare 保护一段时间,看看是否能改善结果。
- 因为你有 VPS,我可能假设你有 root 访问权限,所以你可以尝试安装 Nginx + Apahce2 设置,这样静态文件的渲染速度肯定会比。
在您的情况下不会影响速度的事情:
- 优化 Wordpress
- 更新和优化 mySQL:使用 MariaDB、256MB 查询缓存...
https://github.com/a-jie/angular-infinite-list例子:https://github.com/a-jie/angular-infinite-list例子:
https://github.com/a-jie/angular-infinite-list例子:angular-infinite-list 地址:https://github.com/a-jie/angular-infinite-list例子:
Using npm:
npm install angular-infinite-list --save
Import angular Infinite list module into your app module
import { InfiniteListModule } from ''angular-infinite-list'';
@NgModule({
imports: [
browserModule,
FormsModule,
InfiniteListModule,
...
Wrap Infinite list tag around list items
<infinitelist
[width]=''"100%"''
[height]=''500''
[data]=''data''
[itemSize]=''50''
(update)=''event = $event''>
<div *ngFor="let item of event?.items; let i=index;" [ngStyle]="event.getStyle(i)">
item{{event.start + i}} : {{item|json}}
</div>
</infinitelist>
or directive usage
<div infinitelist [width]=''"100%"'' ...</div>
angular-infinite-list
地址:<a href="https://github.com/a-jie/angular-infinite-list">https://github.com/a-jie/angular-infinite-list</a>例子:<a href="https://a-jie.github.io/angular-infinite-l 官网
https://github.com/a-jie/angular-infinite-list例子:https://github.com/a-jie/angular-infinite-list

ASP.NET Core 高 TTFB(超过 5 秒)首次访问该站点
这是我的观察。
-
当您在一段时间内不访问站点时,它将成为理想的选择,大多数托管服务提供商(共享托管)卸载该站点和应用程序池。
-
下次有任何请求时,再次加载应用程序需要一些时间。如果您上传应用程序的新版本,也会发生这种情况。
在 IIS 以下配置。 (高级设置)
- 预加载已启用(站点级别)
- 启动模式(应用程序池级别)
- 理想超时(应用程序池级别)
如果您选择 Azure Web App,则在常规设置中会有一个配置,例如始终开启。
现在来到您的应用程序,就像您在来自外部服务器的第一次请求时加载任何数据一样。如果是这样,延迟也会导致此类问题。

asp.net – Azure网站上脚本/样式的长时间等待(TTFB)时间
我在Azure网站上有这个有趣的问题。我的网站使用4个脚本文件和3个风格的文件,每个细分。他们不是那么大,最大的接近200 KB。网站已经开始了。 Azure的Always On选项已打开。当我调用WebApi数据时,它返回<50ms。
当应用程序重新加载时,需要250 ms才能从最小脚本中获取第一个字节,而其他脚本需要更多。初始Html在60 ms内加载。脚本/样式被缓存,因此它们不被下载,但TTFB时间正在杀死性能。这会重复每一次重新加载。应用程序不包含任何复杂的配置,所以它应该运行得比它快得多。
什么可以引起这样的问题?
解决方法
虽然您的静态文件被缓存,但浏览器仍然使用if-modified-since标头发出请求(导致304)。
虽然它不需要下载实际的内容,但仍然需要等待RTT服务器的思考时间来继续。
我会建议两件事情:
>添加缓存控制和过期标题 – 有助于避免304在某些情况下(除非你打F5)
>使用正确的CDN(如Incapsula或其他),将最小化RTT思考时间。它也可以用于轻松控制各种资源的高速缓存设置。
这里更好的东西
祝你好运!

Django + Nginx + Gunicorn - 为什么我的 TTFB 这么高?
如何解决Django + Nginx + Gunicorn - 为什么我的 TTFB 这么高?
这是我第一次使用 Nginx/gunicorn 设置网络服务器,所以如果有任何明显的原因我的 TTFB 如此之高,我会道歉。
根据 gtmetrix.com 我的 TTFB 是 1.4s:

在我自己的测试中,我的 TTFB 大约为 1.3 秒。
我对为什么它如此之高感到困惑,即使我启用了 brotli、缓存(静态和媒体文件)、Http2,我启用了 html minifier,所以我不知道为什么。我的服务器是纽约数字海洋上的 2GB cpu(靠近我所在的地方),所以位置不是问题。我检查了 this 堆栈溢出问题,但删除 django-htmlmin 包仍然有很高的 ttfb。我在此页面上的 Django 视图只是:
@minified_response
def home(request):
context = {
''posts'': Post.objects.all()
}
return render(request,''blog/home.html'',context)
我认为这是一个简单的查询,我不希望 TTFB 仅仅因为这个 get 查询就这么高。我的数据库有问题吗(现在我正在使用 sqlite)?如果您需要我的任何其他文件或东西来帮助我调试,请告诉我。
此外,根据 Cloudflare 的 this 文章,我的 TTFB 很高,因为
在 CloudFlare,我们广泛使用了 Nginx,并且在调查 TTFB 时发现,在使用或不使用压缩时,TTFB 与 Nginx 存在显着差异。网页的 Gzip 压缩大大减少了网页下载所需的时间,但压缩本身是有成本的。即使完整下载速度更快,该成本也会导致 TTFB 更高。
所以我尝试删除brotli,但TTFB仍然相当高,并且在Nginx conf文件中禁用gzip对TTFB没有帮助。
描述: Nginx-Gunicorn 服务器在 Django(sqlite 数据库)上使用 Digitalocean NYC 2GB cpu
编辑:我停止使用 Cloudflare,因为我遇到了一些问题。
解决方法
检查了这个:https://www.digitalocean.com/community/questions/how-can-i-improve-the-ttfb
事实证明,使用 fastcgi 缓存可以大大加快速度。我之前的 ttfb 大约是 1300 毫秒,现在(如果没有来自服务器的更新)ttfb 大约是 10~40 毫秒,但是如果页面是从服务器的数据更新的,那么 ttfb 大约是 1300~2000 毫秒,但我很好。请告诉我使用fastcgi_cache是否有任何问题,但到目前为止没有任何问题。我的 Nginx 文件:
# Other Stuff
fastcgi_cache_path /etc/nginx-cache levels=1:2 keys_zone=djangocache:100m inactive=60m;
fastcgi_cache_key # Your Cache Key (Ex: https://example.com/);
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
# ...
server {
# more stuff
location / {
fastcgi_cache_valid 301 30d;
fastcgi_cache djangocache;
fastcgi_cache_valid 200 30m;
fastcgi_cache_methods GET HEAD;
fastcgi_cache_use_stale updating;
fastcgi_cache_background_update on;
fastcgi_pass # Your server name;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
add_header X-Fastcgi-Cache $upstream_cache_status;
# ...
}
# ...
}
如果您发现我上面的代码有任何问题,请告诉我,我仍在尝试使用 fastcgi 缓存。
我们今天的关于在 WordPress 上使用 https 时,TTFB 速度较慢,但已多次优化和wordpress tdk的分享已经告一段落,感谢您的关注,如果您想了解更多关于angular-infinite-list 地址:https://github.com/a-jie/angular-infinite-list例子:本文标签:

当您在一段时间内不访问站点时,它将成为理想的选择,大多数托管服务提供商(共享托管)卸载该站点和应用程序池。
下次有任何请求时,再次加载应用程序需要一些时间。如果您上传应用程序的新版本,也会发生这种情况。

当应用程序重新加载时,需要250 ms才能从最小脚本中获取第一个字节,而其他脚本需要更多。初始Html在60 ms内加载。脚本/样式被缓存,因此它们不被下载,但TTFB时间正在杀死性能。这会重复每一次重新加载。应用程序不包含任何复杂的配置,所以它应该运行得比它快得多。
什么可以引起这样的问题?
解决方法
虽然它不需要下载实际的内容,但仍然需要等待RTT服务器的思考时间来继续。
我会建议两件事情:
>添加缓存控制和过期标题 – 有助于避免304在某些情况下(除非你打F5)
>使用正确的CDN(如Incapsula或其他),将最小化RTT思考时间。它也可以用于轻松控制各种资源的高速缓存设置。
这里更好的东西
祝你好运!


@minified_response
def home(request):
context = {
''posts'': Post.objects.all()
}
return render(request,''blog/home.html'',context)
检查了这个:https://www.digitalocean.com/community/questions/how-can-i-improve-the-ttfb
事实证明,使用 fastcgi 缓存可以大大加快速度。我之前的 ttfb 大约是 1300 毫秒,现在(如果没有来自服务器的更新)ttfb 大约是 10~40 毫秒,但是如果页面是从服务器的数据更新的,那么 ttfb 大约是 1300~2000 毫秒,但我很好。请告诉我使用fastcgi_cache是否有任何问题,但到目前为止没有任何问题。我的 Nginx 文件:
# Other Stuff
fastcgi_cache_path /etc/nginx-cache levels=1:2 keys_zone=djangocache:100m inactive=60m;
fastcgi_cache_key # Your Cache Key (Ex: https://example.com/);
fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
# ...
server {
# more stuff
location / {
fastcgi_cache_valid 301 30d;
fastcgi_cache djangocache;
fastcgi_cache_valid 200 30m;
fastcgi_cache_methods GET HEAD;
fastcgi_cache_use_stale updating;
fastcgi_cache_background_update on;
fastcgi_pass # Your server name;
fastcgi_param PATH_INFO $fastcgi_script_name;
fastcgi_param REQUEST_METHOD $request_method;
fastcgi_param CONTENT_TYPE $content_type;
fastcgi_param CONTENT_LENGTH $content_length;
add_header X-Fastcgi-Cache $upstream_cache_status;
# ...
}
# ...
}
如果您发现我上面的代码有任何问题,请告诉我,我仍在尝试使用 fastcgi 缓存。
本文标签: