我必须根据他/她的连接速度动态决定要发送给客户端的内容权重。
即：如果客户使用具有 3G（或更慢）连接的移动设备，我会向他/她发送轻量级内容。如果他/她使用 WiFi 或更快的连接，我会向他/她发送完整的内容。
我试图测量重新加载之间的时间，向客户端发送一个标头Location: myurl.com（带有一些关于客户端的信息来识别它）。这适用于桌面浏览器和一些完整的移动浏览器（如 Obigo），但不适用于迷你（代理）浏览器，如 Opera Mini 或 UCWeb。这些浏览器返回我的服务器和代理服务器之间的连接时间，而不是移动设备。
如果我尝试使用<meta>tag 或 Javascript重新加载页面，也会发生同样的情况document.location。
有什么方法可以发现或测量客户端连接的速度，或者他/她是否使用 3G 或 WiFi 等，这适用于迷你浏览器（即，我可以通过迷你浏览器识别慢速连接）？
这是一个很好的问题。我之前没有遇到过任何从浏览器估计客户端速度的技术。不过，我确实有一个想法；我没有花几分钟的时间思考这个问题，但希望它能给你一些想法。另外，请原谅我的冗长：
首先，在处理客户端-服务器性能时需要考虑两件事：吞吐量和延迟。通常，与桌面客户端相比，移动客户端的带宽较低（因此吞吐量较低）。此外，移动客户端的连接可能更容易出错，因此具有更高的延迟。但是，以我有限的经验，高延迟并不意味着低吞吐量。相反，低延迟并不意味着高吞吐量。
因此，您可能需要区分延迟和吞吐量。假设客户端为每个 HTTP 请求发送一个时间戳（我们称之为“A”），而服务器只是简单地回显它。然后，客户端可以用当前时间减去这个返回的时间戳，以估计请求进行往返所需的时间。这个时间几乎包括一切，包括网络延迟，以及服务器完全接收您的请求所花费的时间。
现在，假设服务器在发送整个响应正文之前首先在响应标头中发回时间戳“A”。还假设您可以增量读取服务器的响应（例如非阻塞 IO。有多种方法可以做到这一点。）这意味着您可以在读取服务器响应之前获得回显的时间戳。此时，客户端时间“B”减去请求时间戳“A”是您的延迟的近似值。将其与客户端时间“B”一起保存。
完成读取响应后，响应正文中的数据量除以新客户端时间“C”减去先前客户端时间“B”就是您的吞吐量的近似值。例如，假设 C - B = 100ms，并且您已经读取了 100kb 的数据，那么您的吞吐量是 10kb/s。
再一次，移动客户端连接容易出错，并且随着时间的推移强度会发生变化。因此，您可能不想测试一次吞吐量。实际上，您不妨测量每个响应的吞吐量，并保持客户端吞吐量的移动平均值。这将减少一个请求的异常糟糕的吞吐量导致客户端质量下降的可能性，反之亦然。
如果此方法有效，那么您需要做的就是确定用于确定客户端获取什么内容的策略。例如，您可以从“低质量”模式开始，然后如果客户端在一段时间内具有足够好的吞吐量，则将它们升级为高质量内容。然后，如果它们的吞吐量下降，则将它们降级为低质量。
编辑：澄清了一些事情并添加了吞吐量示例。
第一件事：通过 SSL (HTTPS) 运行将避免很多代理废话。它还会停止压缩之类的事情（这可能会使 HTML、CSS 等加载更快，但对已经压缩的数据没有帮助）。
加载页面的时间是延迟+ (带宽×大小)。即使延迟未知，测量小文件和大文件也可以为您提供带宽：
Let L be latency, B be bandwidth, both unknown.
Let t₁ and t₂ be the measured download times.
In this example, the two sizes are 128k and 256k.
t₁ = L + B × 128 // sure would be nice if SO had Τεχ
t₂ = L + B × 256
t₂ - t₁ = (L + B × 256) - (L + B × 128)
= L + B × 256 - L - B × 128
= 256(B) - 128(B)
= 128(B)
因此，您可以看到，如果将时间差除以页面大小的差，您就得到了带宽。由于延迟和带宽不是恒定的，进行单次测量可能会产生奇怪的结果。重复几次（并剔除异常值和荒谬的 [例如，负] 值）将收敛于真正的平均带宽。
您可以在后台使用任何 AJAX 框架在 JavaScript 中轻松地进行这些测量。获取当前时间，发送请求，而不是收到响应时的时钟时间。请求本身的大小应该相同，因此发送请求的开销只是延迟的一部分。不过，您可能希望使用不同的主机来破坏持久连接。或者将您的服务器配置为拒绝持久连接，但仅限于您的测试文件。
我想我实际上有点滥用延迟这个词，它包括所有恒定开销的时间（例如，发送请求）。好吧，它从想要接收有效负载的第一个字节的延迟。
我认为你不应该测量速度或吞吐量。
第一个猜测可能是客户端的浏览器。计算机有许多不同的浏览器，但它们通常与移动设备的浏览器不同。
检查用户使用的浏览器很容易。
您仍然应该提供在轻量级和完整内容之间切换的选项，因为您的猜测可能是错误的。
是的，我知道答案是不要。
我重提这个古老的讨论的原因有两个：
首先，技术发生了变化，9年前不容易的事情现在可能会发生。
其次，我有一个客户的网站可以追溯到 20 多年前几乎没有变化。他拒绝了（非常便宜的）重写的提议，因为它有效而且速度非常快。它只有几页，内容仍然相关（他确实要求我删除传真号码！）他的观点是“如果它没有坏就不要修复它”。在拨号调制解调器连接的时代，它是用纯 HTML 编写的，用于 640 像素宽的屏幕。 有些人仍在使用它们 固定的屏幕宽度意味着它可以在手机/平板电脑上使用，尤其是在横向模式下。它在大屏幕上看起来还不错，因为有平铺背景。
我运行了谷歌页面速度检查器，它的得分只有 99%，所以我调整了 htaccess 文件，现在它得到了 100%。我们大多被快速宽带宠坏了，但一些农村用户的速度非常令人失望。当他们到达数兆字节的页面时，这些人不会高兴。我想也许我可以在另一个网站上尝试一个实验。如果我可以检测到用户正在拨号连接，我可以看到如果我为这些用户提供一个简单的轻量级替代方案会发生什么。
这是您可以在客户端发现的东西吗？如果您需要绕过代理，那么您始终可以在客户端发现连接类型并将其发回。另一种方法是通过某种脚本机制在客户端下载文件，记录每秒字节数，并将该信息返回到服务器端。
比较来自同一客户端的两个请求的服务器端时间。
请求内容 URL 的简单 ajax 查询怎么样？只需记录第一个请求的时间服务器端与客户端的 ip 将其存储在某处（文件或数据库），然后将其与来自客户端 javascript 的请求时间进行比较，并在比较两次后传递 URL任意“快”或“慢”时间限制，并以适当的速度传递内容的 URL。