PC端，触屏版：
前端JS方案——利用img标签加载一张base64的WebP图片，在img标签的onload事件中判断该图片是否具有宽高的属性，若有表示支持webP，若没有表示不支持webP。后台判断方案——判断浏览器请求头Accept是否支持WebP，返回是否支持的标示给前台。
以上两种方案中，前端方案为佳，当JS被禁止的时候，可以使用后台判断方式执行判断。附上JS代码截图
iOS独立版：
用户直接拉取WebP格式的图片（如果CDN有存储），下载完成后在前端实时转码（前端开发的WebP sdk），将WebP图片转换为jpg或png图片。展示给用户的是普通图片。
这样做的好处在于下载WebP的时候节省了带宽，虽然在转码的时候会耗时，但是由于下载时间缩短中和了转码的时间，所以用户基本感觉不出来差别。我们在不延长用户等待时间的同时缩小图片体积，节省了带宽。
安卓独立版：
后台判断用户机器系统，当系统版本大于4.0的时候返回支持WebP标示（因为其原生支持），前端拉取图片时后台会根据这个标示决定使用原格式图片还是WebP格式的图片。
兼容方案
对于不支持WebP的浏览器，可根据是否支持WebP的判断来拉取jpg或者png图片，也可以使用flash作为载体来加载WebP图片（空间相册兼容低端浏览器方案） 。
关于用户下载图片
PC和webview方案中，用户若想将图片另存为本地（可能本地不支持WebP预览展示），可在用户右击“另存为”的时候，绑定右击事件，加载当前WebP图片对应的jpg图片，然后直接下载jpg图片（空间相册方案） 。
虽然这样的做法会导致多加载一张图片，但是由于只在右击时候触发加载，而且用户右击“另存为”的行为较少，消耗可不计。