顺便吐槽一下 Twitter 的网页预览, 非要做得这么独特, 不显示描述了, 之前莫名其妙的文字转换图片就是 njump 设计之初考虑到 Twitter 才这么做的. 现在看来最好的办法是给 TwitterBot 单独组装 meta 标签, 太弱智了, 反正我也不用 Twitter 发帖, 再说了, 又不是不能用. :bili_fantastic:
https://media.naeu.net/71e5cc47223428e2df8ece9d073d8ef5708a95733ad9f0a76e5ce6e592209958.webp
njump 本身是对 TwitterBot 做了单独的 case 适配的, 但可惜用得是 UserAgent 关键词匹配, TelegramBot 的 UA 又偏偏带个 "like TwitterBot", 于是乎 TelegramBot 的请求进来不管怎么样都会被匹配到 Twitter 的元数据条件. 除非给 TwitterBot 的 UA 进行全字匹配, 不知道可不可行.
这次的预览改造还是比较成功的, 迟早也要提交给上游, 还是要做好适配.
给 TwitterBot 单独生成元数据标签之后发现 Cloudflare 的「按设备类型缓存」并非是按照设想中的会分隔 Bot 的缓存.
https://developers.cloudflare.com/automatic-platform-optimization/reference/cache-device-type/
CF 公开的正则里面只有把 GoogleBot 划分在了移动设备里, 而其他的 Bot 被排除, 统统读到桌面端设备的缓存, 如果有桌面设备或者其他 Bot 先行一步让 CF 缓存了页面, 后续 TwitterBot 进来也就没办法读到单独为它准备的元数据标签.
怎么办呢? 不放弃缓存的情况下, 看起来只能给 TwitterBot 开绿灯让它绕过缓存直接回源了.
还有种办法是用服务端规则把 Twitter 的流量重定向到一个额外带有特殊查询字串符的 URL, 这样服务端由于查询字串符就会重新回源, 给 TwitterBot 生成元数据标签, 然后还能继续缓存起来.
今天观察了一下 GitHub 在 Twitter 上的预览表现. 最后发现它的 twitter:title 和 og:title 其实其实就是包含了项目的描述(description)的. 虽然它也做了把元数据打印在 og:image 和 twitter:image 上的事情, 但即使没有卡片也可以靠一个标题就描述完整个网页.
之前一直不喜欢 GitHub 这个冗长的网页标题, 为什么要把项目描述写进去呢? 导致我填文档引用的时候还要手动去删掉这些描述. 现在我算是懂了, 但是也无法排除 GitHub 根本不是为了 Twitter 才这样做的.
现在的静态生成器为了元数据在 Twitter 上表现良好, 只能用依赖于外部的 OG 图片渲染, 特别是边缘函数. 在我看来这就是种过分迁就, summary_large_image 可以说是好的 OG 扩展属性, 但现在开始为了这个 summary_large_image 直接隐藏 描述了.
以后建议专门针对 twitter:card 的 summary_large_image 模式的预览模式, 如果不想依赖外部的 OG 图像渲染, 那就直接把描述写进 twitter:title, 因为这个模式下的 twitter:description 已经失去作用了.
现在回看 Telegram 的网页元数据机器人的 UA, 也是更加理解如今的浏览器 UA 为什么会变成这样了. 喜欢 Telegrambot (like Twitterbot) 吗? 以后新的平台只需要写成 MyPreviewBot/1.0 (like Telegrambot, like Twitterbot) 就好了, 直接对着 Open Graph 适配还能请求网页支持 Twitter 风格的元数据扩展. 但现在我更想去掉这个 like Twitterbot.