一個濫用程式碼的案例

吉姆的一個客戶的WordPress網站遇到了嚴重的效能問題，甚至比一隻安靜的蝸牛還要慢，比一群海龜通過糖蜜工廠時橫衝直撞還要慢。更糟糕的是，該網站在瀏覽器裡的實際渲染速度要比一些讓人比較信服的基準測試的速度慢的多得多。甚至有大量載入的基準測試都會有一個更短的渲染時間。而客戶的瀏覽器並沒有大量的東西要載入。

在研究了多種方案後，吉姆決定將網站遷移到新的、更快的基礎設施上。老舊的機器總是要更新換代的。新的裝置會執行在執行更精準的Ubuntu作業系統上，而老的系統是Lucid。那麼，作為獎勵，客戶獲得了一次免費升級！就像免費的啤酒。

在新的裝置上使用wget來安裝快取系統，吉姆遇到一個segfault錯誤。啊？從wget來的segfault錯誤？為什麼一個真的真的很老，並且穩定的CLI裝置在讀取一個網站的時候會丟擲一個段錯誤？要查詢是什麼問題，日誌似乎是一個符合常規邏輯的正確的查詢的地方。果然，發現了一個奇怪的日誌條目。

非常奇怪！因為，就吉姆目前所知，程式碼裡應該沒有這樣的引用。因此，他開始查詢原始碼，但是並沒有發現這樣的對Google API的引用。接下來，他轉儲資料庫並查詢上下文。但是仍然找不到這個Google API的連結。但是他確實注意到在各種外掛,主題和模板片段裡有對7個不同版本的jQuery的引用。所以搜尋改為專門查詢特定的包含jQuery1.5版本的引用。

結果是這裡只有一個引用，在標頭檔案裡。而且它看起來很正常。

作為除錯技巧，盯著一行程式碼看可不是傳統的教學裡教過的。然而，在這種情形下，它是有效的。仔細觀察我們會發現，script標籤的src屬性是被雙引號引住。

並且，作為被“聰明的”引號引的結果是，所有的現代瀏覽器（幸運的是，包括wget），會嘗試從以下 網址來獲取程式碼：

現在看來，在大多數情況下，這真的是很惱人的。但是吉姆的客戶的網站，使用了傳統的重定向來解析遇到的連結。結果是，它並不是一個快的，簡單地HTTP404結果被返回回來。他是一個完整的，完全沒有被快取的頁面渲染，最終才導致404.因為請求繞過了代理層，頁面以及物件的快取，因此對每一個單獨的請求都增加了800–4000ms的時長。是的，對每一個，單獨的，請求。

也許你能夠想到極大的提高整個網站的速度的解決方案。

當我們很多人去尋找我們最近正在努力解決的問題的解決方案之時，我們最首要的，最終的並且是唯一的資源通常的是網際網路。當我們發現這個難以捉摸的例子，我們真正能夠去做的卻是，剪下、貼上與盲目的放棄。重點在“盲目”上。是的，時代的集體智慧在網上是能獲取到的，也很容易被我們掌握。但是們沒有理解就去使用這些智慧是很危險的。即使是’理解’，也包含更多特定的涵義。

打賞支援我翻譯更多好文章，謝謝！

打賞譯者