漫长的等待（TTFB）时间在Azure网站的脚本/风格 [英] Long waiting (TTFB) time for scripts / styles on Azure Website

问题描述

我对Azure的网站这样一个有趣的问题。我的网站使用4个脚本文件和3个样式文件，每个精缩。他们没有那么大，bigest有近200知识库系统。网站已经开始了。天青总是在选项是打开的。当我打电话的WebAPI数据返回上述＆lt; 50ms的

I have this intriguing problem on Azure Website. My website uses 4 script files and 3 style files, each minified. They are not so big, bigest has near 200 KBs. Website had already started. Azure's Always On option is turned on. When I call to WebApi for data it returns in <50ms.

当应用程序重新加载它需要250毫秒只是为了获得最小的从剧本第一个字节，和其他人需要更多。最初的HTML是加载60毫秒。脚本/样式缓存，使他们不被下载，但TTFB时间查杀性能。这种重复每一个重装。应用程序是不包含任何复杂的配置，它应该运行比它快得多。

And when app is reloaded it needs 250 ms just to get first byte from tiniest script, and others needs much more. Initial Html is loaded in 60 ms. Scripts/styles are cached so they are not downloaded, but the TTFB time is killing the performance. This repeats every single reload. App is not containing any sophisticated configuration so it should run much faster than it.

什么会导致这样的问题？

What can cause such problems?

推荐答案

虽然静态文件缓存，浏览器仍然发出请求，如果 - 修改 - 自标头（这会导致304）。

Although your static files are cached, the browser still issues requests with if-modifies-since header (which results in a 304).

虽然它并不需要下载的实际内容，但仍然需要等待RTT +服务器思考时间继续。

While it doesn't need to download the actual content, it still needs to wait the RTT + server think time to continue.

我建议两件事：

1. 添加Cache-Control和过期头 - 将有助于避免在某些情况下，304（pretty太多，除非你按F5）


2. 是一个合适的CDN - 比如Incapsula或其他人，这将最大限度地减少RTT +思考时间。它也可以用来容易地控制高速缓存设置为各种资源。

1. Adding Cache-Control and Expire headers - will help avoid 304 in some cases (pretty much unless you hit F5)
2. Using a proper CDN - such as Incapsula or others, that will minimize the RTT + think time. It can also be used to easily control cache settings for various resources.

更多的好东西在这里。

祝您好运！

这篇关于漫长的等待（TTFB）时间在Azure网站的脚本/风格的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！