我目前正在組合網站上工作,其中我將不得不在同一頁面上加載大量照片。在圖像密集型網頁上加載速度
這些圖像通過PHP動態加載,目前我選擇預先保存這些圖像的縮略圖版本並加載這些圖像。
然而,我擔心的是,如果網站擁有大量用戶,這可能不是最佳解決方案:我基本上會將每張圖片的重複數乘以用戶上傳的圖片數量。
我的問題是你是否有更好的解決方案來解決這個問題?在不影響太多空間的情況下儘快加載頁面的方法?
謝謝了。
我目前正在組合網站上工作,其中我將不得不在同一頁面上加載大量照片。在圖像密集型網頁上加載速度
這些圖像通過PHP動態加載,目前我選擇預先保存這些圖像的縮略圖版本並加載這些圖像。
然而,我擔心的是,如果網站擁有大量用戶,這可能不是最佳解決方案:我基本上會將每張圖片的重複數乘以用戶上傳的圖片數量。
我的問題是你是否有更好的解決方案來解決這個問題?在不影響太多空間的情況下儘快加載頁面的方法?
謝謝了。
加載充滿大量圖像的網頁會很慢。原因是因爲傳輸這些圖像所需的帶寬。
你有幾個選項
放入標準圖像瓷磚模式。這些圖像將是完整圖像,只是調整大小以適合「縮略圖」視圖。這樣做的好處是您只能保存1張圖片,但該圖片是全尺寸的,需要很長時間才能加載。
按照您所說的加載縮略圖。這樣做的好處是性能,但您需要存儲每個圖像的兩個副本。另外,根據你如何處理縮略圖的創建,你可能會要求用戶上傳圖像的兩個副本,以提供他們自己的縮略圖...這可能會很糟糕。
加載縮略圖,但在上傳時動態生成縮略圖。你基本上保留了磁盤上的圖像的兩個副本,但你是通過一些PHP圖像修改API動態創建它。這將加載速度更快,但仍佔用磁盤空間。它還最大限度地減少了用戶/管理要求以提供縮略圖。
根據請求頁面按需加載縮略圖。這種方法需要一些測試,因爲我從來沒有嘗試過。基本上,你會調用PHP圖像修改API(或更好的源代碼到本地解決方案!)來創建一次性使用(或緩存)的縮略圖來使用。你可能會說「OMG,這會花很長時間!」。我認爲如果您應用適當的緩存機制,這種方法可能實際上可用,因此您不會不斷重新創建相同的縮略圖。它會降低帶寬,因爲這裏的限制因素是網絡連接,所以發送完整圖像可能會更快(因爲創建縮略圖的限制因素現在是CPU /內存/硬盤)。
我認爲#4是一個有趣的概念,可能值得探討。
「on-the-fly」正是錯誤的答案 – KingCrunch 2012-04-26 20:34:56
我的意思是動態生成縮略圖。那是錯的嗎?請解釋。 – 2012-04-26 20:36:20
現在我不清楚,你的意思是「dynamicall」。但是,「即時」意味着您希望爲每個請求創建縮略圖。你絕對不想要這個;) – KingCrunch 2012-04-26 20:41:26
什麼,我認爲是:
A.取緩存(系統緩存,緩存在標頭,HTTP緩存..所有高速緩存)的優勢
B.不要生成Thumb所有的時間
C.使用作業Queing系統如Gearman
或beanstalkd
產生豎起大拇指,這樣你就不必做它立即
D.使用Imagick
更EFF icient
E. PAGINATE
F.實施例,只有當原始文件已被修改
$file = "a.jpg" ;
$thumbFile = "a.thumb.jpg" ;
$createThumb = true;
if(is_file($thumbFile))
{
if((filemtime($file) - 10) < filemtime($thumbFile));
{
$createThumb = false;
}
}
if($createThumb === true)
{
$thumb = new Imagick();
$thumb->readImage($file);
$thumb->thumbnailImage(50, null);
$thumb->writeImage($thumbFile);
$thumb->destroy();
}
考慮使用子畫面或所有圖像的拼貼產生拇指,使得僅一個放大圖像被加載,節省帶寬並減少頁面加載時間。
此外,正如已經建議的那樣,分頁和異步加載可以改善它。
參考文獻:
是,緩存縮略圖是一個好主意,和做過權當將迎刃而解。這種事情是horizontal scaling的好地方。
這是一個磁盤密集和帶寬密集型的東西,圖像傳遞。不像視頻那樣糟糕!
你提到重複的...規範化圖像和用戶之間的關係。計算每個圖像的MD5並使用它來將圖像綁定到用戶。 – HappyTimeGopher 2012-04-26 20:33:08