而Tiles API將樹作為Tiles提供，便不需要動態運算或是請求處理，因此也就不需要API伺服器，而且因為Tiles是靜態的，所以能夠被有效地快取，另外，葉子Tiles還可以壓縮儲存，能夠節省更多的儲存空間。

將日誌以一系列靜態Tiles公開，使得Let's Encrypt可以用更便宜方式水平擴展日誌服務，像是直接在S3等雲端物件儲存中切分Tiles，或是使用CDN、Web伺服器、檔案系統等。由於物件和檔案儲存更易取得且可簡單擴展，比雲端資料庫服務的成本更低。

另外，過去憑證透明度日誌採用了一種稱為合併延遲（Merge Delay）設計，來限制提交日誌的延遲。意思是向日誌提交憑證時，日誌可以立刻回傳簽署憑證的時間戳記，並承諾在日誌最大合併延遲，通常是24小時內，在日誌中包含憑證。

也就是說，合併延遲是一個憑證被提交到日誌之後，與實際被合併進日誌的時間延遲，這種延遲讓日誌營運者有時間進行不要的處理和驗證，但這也代表有一段時間，憑證存在卻沒有公開紀錄。這樣的情況可能導致一些問題，像是日誌服務出現問題，導致無法在最大合併延遲內將憑證合併到日誌中，如此日誌就無法履行對提交憑證的承諾，而影響憑證的有效性，而且沒有即時合併憑證，攻擊者也可能趁著空窗時間進行惡意行為。

因此Sunlight採用批次處理的方法，將憑證以批次的方式整合到日誌中，而這會導致提交憑證過程增加一些延遲，但官方表示，這輕微的延遲可以避免常見憑證透明度日誌失敗的情況。

Let's Encrypt目前已經發布了Sunlight軟體與規範，並開始運行Sunlight憑證透明度日誌服務，官方建議憑證頒發機構開始測試提交憑證資料到新的Sunlight日誌中，也建議讓憑證透明度程式考慮信任該新架構日誌。