翻譯執行緒 URL 的連結

[tavenger5]

因為它是標誌連結不要連結到的實際翻譯執行緒的 URL。這創建大量的額外的重定向，真的不是很好的整體 SEO。請保持 備用標記 記住，。

我不知道到底如何這樣做上飛，但我希望能夠以某種方式不加大對每個頁面的查詢緩存執行緒 Url。

[vBET]

您好！我們都知道關於此。不幸的是加入這個功能，性能將有很大的影響。這不僅是因為額外的查詢翻譯的鏈接，但主要是因為翻譯的請求。如果鏈接還沒有翻譯，然後每個鏈接會導致單獨的翻譯要求翻譯服務提供商。這是因為API允許多個只有一個請求相同的語言對的翻譯。

其他的解決辦法是 - 當它被翻譯，然後把它翻譯，如果沒有的話離開它，因為它是現在。通過這種方式，第二個問題會消失。
有關附加查詢-如果您打開了來賓緩存然後它不會產生任何影響客人請求 （在緩存靜態檔）。此外貝特支援其他"記憶體中"緩存引擎。
因此，如果我們去了，因為它是在這裡，沒有任何優化的情況下，查詢（因為已經包括額外的緩存支持）。

請告訴我們您如何看待這樣的解決方案。

[tavenger5]

因此，如果URL的已經翻譯，他們能夠被存儲在客戶高速緩存中，正確的？

[vBET]

是。仍然來賓緩存工作每頁。所以新的一頁將資料庫中的所有 Url，再次之前會將其存儲在緩存中來賓。並再次每個來賓緩存刷新。但這真的是小成本。因為在預設情況下來賓緩存的工作原理為 24 小時。所以，每天一次。此外我們可以使它用於登錄的使用者，它將被重定向 （登錄的使用者真的做不切換回語言和轉發），和為客人無需-所以谷歌將會看到它的最佳可能的方式。
這將為 2 中 1：
-為記錄器使用者無需額外成本在頁生成期間。
-為低成本發電和甚至為 0 時，您的客人有來賓緩存中的頁 （和谷歌和其他的機器人將在重定向時看到相應的連結，沒有額外的性能影響）

因此，我認為，使它通過這種方式，我們其實可以通過做額外的事情，但只有當來賓緩存打開的因為我們將避免重定向增加性能。此解決方案將不添加額外的參數 — — 它將簡單地附加到來賓緩存。

我相信這種想法。只是為了澄清-你有一些額外的回饋呢？

[tavenger5]

這聽起來對我好。

[Marcin Kalak]

謝謝你的確認。我們將對此功能進行工作。