而Tiles API将树作为Tiles提供，便不需要动态运算或是请求处理，因此也就不需要API伺服器，而且因为Tiles是静态的，所以能够被有效地快取，另外，叶子Tiles还可以压缩储存，能够节省更多的储存空间。
将日志以一系列静态Tiles公开，使得Let’s Encrypt可以用更便宜方式水平扩展日志服务，像是直接在S3等云端物件储存中切分Tiles，或是使用CDN、Web伺服器、档案系统等。由于物件和档案储存更易取得且可简单扩展，比云端资料库服务的成本更低。
另外，过去凭证透明度日志采用了一种称为合并延迟（Merge Delay）设计，来限制提交日志的延迟。意思是向日志提交凭证时，日志可以立刻回传签署凭证的时间戳记，并承诺在日志最大合并延迟，通常是24小时内，在日志中包含凭证。
也就是说，合并延迟是一个凭证被提交到日志之后，与实际被合并进日志的时间延迟，这种延迟让日志营运者有时间进行不要的处理和验证，但这也代表有一段时间，凭证存在却没有公开纪录。这样的情况可能导致一些问题，像是日志服务出现问题，导致无法在最大合并延迟内将凭证合并到日志中，如此日志就无法履行对提交凭证的承诺，而影响凭证的有效性，而且没有即时合并凭证，攻击者也可能趁著空窗时间进行恶意行为。
因此Sunlight采用批次处理的方法，将凭证以批次的方式整合到日志中，而这会导致提交凭证过程增加一些延迟，但官方表示，这轻微的延迟可以避免常见凭证透明度日志失败的情况。
Let’s Encrypt目前已经发布了Sunlight软体与规范，并开始运行Sunlight凭证透明度日志服务，官方建议凭证颁发机构开始测试提交凭证资料到新的Sunlight日志中，也建议让凭证透明度程式考虑信任该新架构日志。