web前端畢業論文題目范文第1篇
關鍵詞：Web性能優化,響應時間,頁面請求原理,Web前臺
0 引言
徐州地區設施葡萄害蟲診斷與防治專家系統是通過Internet向廣大用戶提供專家的分析診斷服務。該系統運行后不久, 用戶反映系統的打開速度很慢, 這里首先排除網絡帶寬和服務器硬件性能方面的因素, 到底是什么原因造成的呢?為縮短頁面的響應時間, 改進用戶體驗, 筆者首先使用工具查看了系統頁面加載時間情況, 如圖1所示。
對圖1進行分析, 可以看到, 加載HTML文檔只占了總響應時間的5%, 其它95%響應時間用來下載JavaScript、CSS和圖片等組件。所以本專家系統Web前端方面有很大的優化空間, 因此, 筆者將從Web的前端優化方面給出Web的性能優化方案。
1 頁面請求原理和過程分析
從輸入URL到頁面呈現需要如下5個步驟:①輸入URL地址或者點擊URL的一個鏈接;②瀏覽器根據URL地址, 結合DNS解析出URL對應的IP地址;③發送HTTP請求;④開始連接請求的服務器并且請求相關的內容;⑤瀏覽器解析從服務器端返回的內容, 并且把頁面顯現出來。
上述基本上就是一個頁面從請求到實現的基本過程, 下面來剖析這個過程。
當輸入URL之后, 瀏覽器就要知道這個URL對應的IP是什么, 只有知道了IP地址, 瀏覽器才能準確把請求發送到指定的服務器的具體IP和端口號上面。瀏覽器的DNS解析器負責把URL解析為正確的IP地址。這個解析的工作是要花時間的, 而且在這個解析的時間段內, 瀏覽器不能從服務器那里下載到任何東西。瀏覽器和操縱系統提供了DNS解析緩存支持。
當獲得了IP地址之后, 瀏覽器就向服務器發送HTTP的請求, 過程如下:①瀏覽器通過發送一個TCP的包, 要求服務器打開連接;②服務器也通過發送一個包來應答客戶端的瀏覽器, 告訴瀏覽器連接打開了;③瀏覽器發送一個HTTP的GET請求, 這個請求包含了很多的東西, 例如我們常見的Cookie和其它的head頭信息。這樣, 一個請求就算是發過去了。
請求發送去之后, 服務器端的程序把最后的結果發送到客戶端。
其實首先到達瀏覽器的就是HTML文檔, 是純粹的HTML代碼, 不包含圖片、腳本、CSS等, 也就是頁面的HTML結構, 因為此時返回的只是頁面的HTML結構。這個HTML文檔發送到瀏覽器的時間極短, 一般只占整個響應時間的10%左右。
之后, 頁面的基本框架就在瀏覽器中, 下一步為瀏覽器解析頁面的過程, 一步步從上到下解析HTML的框架。
如果此時在HTML文檔中, 遇到了img標簽, 那么瀏覽器就會發送HTTP請求到這個img響應的URL地址去獲取圖片, 然后呈現出來。如果在HTML文檔中有很多的圖片、flash, 那么瀏覽器就會一個個地請求, 然后呈現, 如果每個圖片都要請求, 那么就要進行之前所說的那些步驟:解析URL、打開TCP連接等。打開連接也需要消耗資源, 就像在進行數據庫訪問一樣, 也需盡可能少開數據庫連接, 多用連接池中的連接。道理一樣, TCP連接也是可以重用的。HTTP 1.1提出了持久連接 (Persistent Connection) 的概念, 也就是說同一條HTTP連接可以同時處理多個請求, 減少TCP連接。
當頁面的HTML框架載入之后, 瀏覽器就開始解析頁面中的標簽, 從上到下開始解析。
首先是head標簽的解析, 如果發現在head中有要引用的JavaScript腳本, 那么瀏覽器此時就開始請求腳本, 此時整個頁面的解析過程即停止下來, 一直到JavaScript請求完畢。之后頁面接著向下解析, 如解析body標簽, 如果在body中有img標簽, 那么瀏覽器就會請求img的src對應的資源, 如果有多個img標簽, 那么瀏覽器就一個個解析, 解析不會像JavaScript那樣等待, 會并發下載。
2 Web前臺優化規則
2.1 盡量減少 HTTP 請求
有幾種常見的方法能切實減少 HTTP 請求:①合并腳本和樣式文件, 如可以把多個 CSS 文件合成一個, 把多個JavaScript文件合成一個;②CSS Sprites 利用 CSS background 相關元素進行背景圖絕對定位, 把多個圖片合成一個圖片。
2.2 使用瀏覽器緩存
在用戶瀏覽網站的不同頁面時, 很多內容是重復的, 比如相同的JavaScript、CSS、圖片等。如果能夠建議甚至強制瀏覽器在本地緩存這些文件, 將大大降低頁面產生的流量, 從而降低頁面載入時間。
根據服務器端的響應header, 一個文件對瀏覽器而言, 有幾級不同的緩存狀態:①服務器端告訴瀏覽器不要緩存此文件, 每次都到服務器上更新文件;②服務器端沒有給瀏覽器任何指示;③在上次傳輸中, 服務器給瀏覽器發送了Last-Modified或Etag數據, 再次瀏覽時瀏覽器將提交這些數據到服務器, 驗證本地版本是否最新, 如果為最新則服務器返回304代碼, 告訴瀏覽器直接使用本地版本, 否則下載新版本。一般來說, 有且只有靜態文件, 服務器端才會給出這些數據;④強制要求瀏覽器緩存文件, 并設置了過期時間。在緩存未到期之前, 瀏覽器將直接使用本地緩存文件, 不會與服務器端產生任何通信。我們要做的是盡量強制瀏覽器到第4種狀態, 特別是對于JavaScript、CSS、圖片等變動較少的文件。
2.3 使用壓縮組件
IE和Firefox瀏覽器都支持客戶端GZIP。傳輸之前, 先使用GZIP壓縮再傳輸給客戶端, 客戶端接收之后由瀏覽器解壓, 這樣雖然稍微占用了一些服務器和客戶端的CPU, 但是換來的是更高的帶寬利用率。對于純文本來講, 壓縮率是相當可觀的。如果每個用戶節約50%的帶寬, 就可以服務多一倍的客戶, 并且縮短了數據的傳輸時間。
2.4 圖片、JavaScript的預載入
預載入圖像最簡單的方法是在 JavaScript 中實例化一個新 Image () 對象, 然后將需要載入的圖像的 URL 作為參數傳入。同時可以在登錄頁面預載入JavaScript和圖片 (見圖2) 。
2.5 將腳本放在底部
腳本放在頂部會帶來如下問題:①使用腳本時, 對于位于腳本以下的內容, 逐步呈現將被阻塞;②在下載腳本時會阻塞并行下載。
放在底部可能會出現JavaScript錯誤問題, 當腳本沒加載進來, 用戶就觸發腳本事件。所以要綜合考慮各種可能情況。
2.6 將樣式文件放在頁面頂部
如果樣式表任意加載, 構建呈現樹就是一種浪費, 樣式文件放在頁面底部可能會出現兩種情況:①白屏;②樣式內容的閃爍。
2.7 使用外部的JavaScript和CSS
將內聯的JavaScript和CSS做成外部的JavaScript、CSS。減少重復下載內聯的JavaScript和CSS。
2.8 精簡JavaScript
可以做到兩個級別:①精簡:從代碼中移除不必要的字符以減少其大小;②混淆:在精簡的同時, 還會改寫代碼, 函數、變量名被轉換成更短的字符串?？梢允褂肧hrinkSafe來精簡JavaScript。
2.9 精簡CSS
從代碼中移除不必要的字符以減少其大小, 可以使用CSS Compressor。
2.10 精簡圖片、flash
對大圖片、flash, 要在效果和大小之間做出平衡。
3 結語
本文總結的Web前端優化技術適用于絕大多數Web應用, 本專家系統在進行相應的前臺優化后, 頁面打開速度顯著提高。Web技術是一項綜合性技術, 包括前臺、后臺 (服務器) 、數據庫、硬件和網絡等多方面, 因此Web性能優化包括的內容也必然變得復雜。后臺程序的優化和數據庫的優化這里暫不討論, 筆者在《淺談.Net Framework下的高性能Web開發》一文中進行了分析, 感興趣的讀者可以查看。
參考文獻
[1]曹劉陽.編寫高質量代碼:Web前端開發修煉之道[M].北京:機械工業出版社, 2010.
[2][美]克魯爾.網站性能監測與優化[M].袁菲, 譯.北京:人民郵電出版社, 2010.
web前端畢業論文題目范文第2篇
加載時間很大程度上影響著用戶體驗和網站的競爭力。據美國網上媒體報道, Google檢索到的網頁的加載速度平均為2.45秒[1], 而購物網站的平均網頁加載速度為7.25秒[2]。美國研究生項目資訊網站的調查結果[3]表明, 網頁加載時間超過4秒, 約有四分之一的人會放棄打開該網頁。調查機構Kiss Mitrics研究發現:網頁加載速度影響用戶消費, 如果電子商務每天收入為10萬美元, 那么1秒的延遲就會讓該網站每年損失250萬美元[4]。
截止至2013年4月, 互聯網站總數近10億, 每秒新增7.9個新網民。如此高速發展的Web, 卻普遍存在前端性能低下的問題[5]。例如:2011年百度年會推出的百度新首頁, 后端的平均時間為60 ms, 而前端的平均時間卻為1.3秒[6]。與此同時, 國內的網速普遍比發達國家慢很多, 中國大陸網速排在世界第71名, 平均網速為1.774 Mbps, 遠低于世界平均水平[7]。在網速低下的環境下, 對Web進行前端性能優化顯得尤為重要。
如今, Web的高速發展, 以往的以文檔為核心的HTML和XHTML標準已經無法滿足Web發展的需要。新一代的HTML5應用旨在改變這一切, 其擁有很多強大的用于交互、多媒體和本地化等各個方面的標簽以及應用編程接口[8]。但這些的實現意味著需要更好前端性能, 特別是在移動端網速普遍較慢的環境下。
早在21世紀初, 雅虎、谷歌等知名互聯網公司已經開始重視前端性能優化, 并提出了很多解決方案以及相關的工具。比如谷歌的Page Speed、Speed Tracer、雅虎的首席性能工程師Steve Souders根據性能優化的經驗編寫了《High Performance Web Sites》[9]以及他與另外8位Web前端專家級特約作者編寫的《Even Faster Web Sites》[10]提供了提升網站性能的最佳實踐和實用建議。國內2010年, 張紫微等人[11]通過對影響Web前端性能的各種因素, 包括HTTP協議、瀏覽器工作方式、緩存機制、頁面大小、頁面結構以及Ajax等前端相關理論的分析, 有針對性地提出了前端優化的多種技術開展方法, 設計并實現了一個基于等待時間提升優先級的優先級請求隊列, 使所有的異步請求都放入優先級隊列, 由該隊列管理請求和發送請求, 解決了Ajax瀏覽器的2連接請求問題。高潔璇[12]采用Ajax技術建立了Ajax化頁面模型, 從傳統的緩存思想出發, 針對熱點頁面建立了頁面緩存模型, 使請求冗余進一步減少, 降低了服務器負載, 利用并行思想, 設計了適用于信息復雜、可模塊化的頁面并行加載模型, 降低請求響應過程中的冗余, 提高了服務器響應速度, 并縮短用戶等待時間, 獲得了更好的用戶體驗。
在性能診斷與優化處理工具方面, 周鵬等[13]提出了基于Spirent的Web應用性能評測。聶應高[14]以湖北省高校數字圖書館門戶為例, 進行了基于Page Speed的網站前端性能優化分析和實踐。連志剛[13]認為Web性能測試難度大、周期長、要求高是一直困擾測試人員的主要問題, 研究了基于RBI的馬爾科夫Web系統性能測試過程模型。趙佳佳[16]運用性能測試工具LoadRunner等建立場景并從全面分析研究, 盡可能真實地模擬大量用戶的并發操作等行為, 并對測試結果進行完善, 利用單因素隔離與對比等方法分析影響Web性能的瓶頸。但這些方案往往比較寬泛零散, 缺乏系統性, 實踐對比不足, 與項目掛鉤太緊密, 缺乏通用性性能測試, 沒形成一個完整的解決方案。
據此, 通過分析歸納Web中從后端到前端的B/S架構原理、瀏覽器緩存、瀏覽器的加載方式、服務器關于HTTP相關的配置等過程中一些影響前端性能優化的因素, 系統地提出了一個旨在提高網頁加載速度、呈現速度和用戶體驗, 整體性、通用性強的完整Web前端性能優化解決方案, 包括服務器端優化、HTML優化、Java Script優化、CSS優化、圖片優化, 過程盡量避免項目的特殊性, 強調實踐的可行性以及通用性。針對一個基于HTML5技術的Web移動應用“指尖點餐系統”選用適當的性能檢測工具搭建測試環境, 尋找該系統前端性能優化上的瓶頸, 并結合該項目特點, 根據所提出的Web前端性能優化解決方案對其進行優化實踐, 對比優化前后的性能。
1 Web性能優化方案
1.1 Web性能優化相關理論
(1) B/S架構
從瀏覽器對服務器進行頁面請求的過程[16]如下所示:
(1) 首先用戶在瀏覽器輸入網址或者通過其它應用程序請求url。
(2) DNS解析域名, 返回該域名所指向的網站ip地址。
(3) 瀏覽器對對應的服務器發送HTTP請求。
(4) 服務器接收到瀏覽器的發送的HTTP請求。
(5) 服務器解悉瀏覽器請求的URL, 根據URL確定請求的目標資源文件。這個資源文件通常是一個動態頁面 (如ASP, PHP, JSP等文件) 的網絡地址 (MVC結構的程序例外) 。Web服務器根據動態頁面文件的內容和URL中的參數, 調用相應的資源 (通過數據庫或文件) 組織數據, 生成HTML頁面。 (注意這里生成的是一個HTML文檔, 里面可能包含Java Script代碼等, 這里在服務器端不管HTML文檔里的具體內容)
(6) 生成HTML文檔以后, 服務器響應瀏覽器的HTTP請求, 將生成的HTML文檔發送給瀏覽器。
(7) 瀏覽器接收請求得來的HTML文檔。
(8) 瀏覽器對HTML文檔進行解悉, 并請求HTML中鏈接的資源文件 (如Java Script, CSS, 多媒體資源, 內嵌網頁) 等。
(9) 服務器接到瀏覽器對資源文件的HTTP請求以后, 將相應的資源文件發送給瀏覽器。
(10) 瀏覽器接收到請求來的資源文件, 整理并呈現到頁面中 (瀏覽器將進行重排、重繪) 。在進行頁面呈現的時候, 瀏覽器會從上到下執行HTML文檔, 當遇到相應的頁面腳本的時候, 會對腳本進行分析, 并解釋執行相應的腳本代碼。當執行腳本時, 將阻塞之后的鏈接文件的加載。
在此過程中, Java Script的加載會影響其他資源的加載。CSS的加載雖然不會影響其他資源的加載, 但是由于其與瀏覽器的渲染有關, 因此加載會影響瀏覽器呈現和用戶體驗。資源加載方面, 瀏覽器還會限制資源加載的并行連接數和最大連接數。
(2) HTTP協議客戶機與服務器信息交互
瀏覽器與服務器之間的HTTP通信協議對瀏覽器緩存機制進行了一系列規定, 使得非首次訪問不用重復加載加載過的資源, 提高了資源的利用率, 避免了重復加載的浪費。在HTTP/1.0中提供了一種簡單的緩存機制, 通過客戶端根據獲取文件中的日期和時間與在硬盤上緩存的文件進行對比。如果要獲取的文件存在客戶端緩存中, 則客戶端發送帶有If-Modifined-Since字段的頭部信息的HTTP請求。服務器程序若發現該文檔沒有發生改變, 則返回304響應, 不發生請求文件, 此時客戶端接收304響應后直接使用緩存中的文件。在這期間, 瀏覽器就向服務器發送HTTP的請求及服務器接收到瀏覽器的發送的HTTP請求無可厚非是一個非常重要的過程。超文本傳輸協議HTTP (Hyper Text Transfer Protocol) 是互聯網上應用最為廣泛的一種網絡協議。設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法。通過HTTP或者HTTPS協議請求的資源由統一資源標識符來標識。HTTP協議有四個版本:HTTP0.9、HT-TP/1.0、HTTP/1.1及HTTPS, 其中HTTP/1.1是當前最經常被使用的版本。它持久連接被默認采用, 并能很好地配合代理服務器工作。還支持以管道方式在同時發送多個請求, 以便降低線路負載, 提高傳輸速度。HTTP/1.1更改使用持續連接, 不必為每個Web對象創建一個新的連接, 一個連接可以傳送多個對象。HTTP/1.1還進行了帶寬優化, 例如HTTP/1.1引入chunkedtransferencoding (分塊傳輸編碼) 來允許stream化傳輸持續連接上發送的內容, 取原先的buffer式傳輸[13]。在HTTP/1.0協議中每個HTTP請求都需要建立一個單獨的連接, 每次連接只傳輸單獨的資源。在客戶端和服務器每次建立和關閉連接中需要一定的時間消耗和延遲, 頻繁的請求影響客戶端和服務器的性能。為了克服這個缺陷, HTTP/1.1采用持久連接 (也稱作長連接) , 在同一個TCP連接上可以傳送多個HTTP請求和響應, 減少了建立和關閉連接的消耗和延遲。HTTP1.1還允許客戶端不用等待上一次請求結果返回, 就可以發出下一次請求, 但服務器端必須按照接收到客戶端請求的先后順序依次回送響應結果, 以保證客戶端能夠區分出每次請求的響應內容, 這樣也顯著地減少了整個下載過程所需要的時間。
基于HTTP1.1協議的客戶機與服務器的信息交換過程如圖1所示。
此外, HTTP也有狀態碼和一些緩存的機制。HTTP緩存可以簡單地理解為:當Web請求抵達緩存時, 如果本地有“已緩存的”副本, 就可以從本地存儲設備而不是從原始服務器中提取這個文檔。這樣一來, 就可以減少冗余的數據傳輸, 減少了服務器的負擔, 大大提高了網站的性能, 從而加快了客戶端加載網頁的速度。在HTTP/1.0中提供了一種簡單的緩存機制, 即客戶端根據獲取文件中的日期和時間與在硬盤上緩存的HTTP文件相對比。如果要獲取的文件存在客戶端緩存中, 則客戶端發送帶有If-Modifined-Since字段的頭部信息的HTTP請求。服務器程序若發現該文檔沒有發生改變, 則返回304響應, 不發生請求文件, 此時客戶端接收304響應后直接使用緩存中的文件[17]。HTTP/1.1對緩存進行了加強, 并使用了復雜的算法以及機制來實現緩存 (過期驗證模型和有效性確認模型) , 對與經常訪問的客戶端的請求響應產生的數據流量大大下降, 降低服務器上擁塞的產生, 同時大大縮短了響應時間, 提高了服務器和Web前端的性能。
在服務器響應請求發送的過程中, 瀏覽器與服務器可以進行gzip等約定的雙方的壓縮協議。
(3) 瀏覽器方面
在B/S結構結構中, Web瀏覽器作為客戶端最主要的應用軟件, 客戶端統一化, 將系統功能實現的核心部分集中到服務器上, 簡化了系統的開發、維護和使用。Web瀏覽器可以對頁面資源進行并行加載, 但是對同一個域名下會有并行連接數的限制, 同時對瀏覽器的總連接數也有所限制。不同的瀏覽器有著不同限制, 圖2是國外的社區驅動型項目Browserscope瀏覽器對比的結果[18]。
因此, 應通過適當增加域名來提高同一頁面的并行連接數、在域名解析、同一域下并行連接數和最大連接數之間適當的平衡。
在瀏覽器對服務器進行頁面請求的過程中, Java Script的加載會影響其他資源的加載。CSS的加載雖然不會影響其他資源的加載, 但是由于其與瀏覽器的渲染有關, 因此加載會影響瀏覽器呈現和用戶體驗。資源加載方面, 瀏覽器還會限制資源加載的并行連接數和最大連接數。
1.2 服務器端優化
(1) 域名優化
瀏覽器限制并行連接數使得在同一個域名下加載的資源數量及其有限。對于頁面請求很多的頁面來說, 頁面加載速度必然受到限制。
采用多域名加載資源, 可以提高同一時間內加載資源的數量, 最大限度地利用有限的帶寬。同時, 采用多域名的另外一個好處在于, 當HTML資源攜帶的Cookie過大時, 將HTML規劃到單獨的域名, 避免其他資源的請求來回傳輸很大的cookie, 從而避免了HTTP請求大小, 提高Web前端性能。
局限性:采用多域名不得不面臨的問題是域名查找DNS的開銷, DNS解析可能需要幾秒的時間, 因此如何在域名解析時間消耗和多域名提高并行連接數折中, 是采用多域名優化加載資源的考慮因素之一。
(2) 設置緩存
瀏覽器使用緩存來減少HTTP請求的大小, 避免重復加載資源, 提高資源的利用率、減少服務器壓力、提高前端性能。在服務器與Web瀏覽器之間可以設置Expires、Cache-Control (MaxAge) 、mod_expires、Etag頭部信息等方式進行緩存。
設置Expires頭部是最常用的方式之一, 通過指定HTTP頭部的Expires字段一個過期時間來驗證是否使用緩存數據。其局限性在于, Expires頭部指定的時間, 需要服務器與瀏覽器進行時間同步。
設置Cache-Control的max-age來進行緩存, 可以避免與服務器進行實踐同步。不過其只支持HTTP1.1。通過同時設置這兩個字段, 可以在HTTP1.1時使用Cache-Control, 在其他使用Expires頭部進行緩存。
此外, ETag用于檢測瀏覽器緩存中的組件是否與服務器上的組件一致。設置或移除ETag頭部信息, 可以有很大的作用, 比如Etag對于Cache CGI頁面很有用。特別是論壇, 論壇有辦法為每個帖子頁面生成唯一的Etag, 在帖子未改變時, 查看話題屬性比較Etag就能避免刷新帖子, 減少CGI操作和網絡傳輸, 減少論壇負擔。適時移除ETag將有利于提升性能, 避免數據存在于緩存時進行不必要的和低效的下載。但它也有一定的局限性:ETag降低了代理緩存的效率, 用戶與代理之間的ETag經常不匹配。而通常Last-Modified與ETag是可以一起使用的, 服務器會優先驗證ETag, 一致的情況下, 才會繼續比對Last-Modified, 最后才決定是否返回304。且在一般情況下, Cache-Control/Expires會配合Last-Modified/ETag一起使用, 因為即使服務器設置緩存時間, 當用戶點擊“刷新”按鈕時, 瀏覽器會忽略緩存繼續向服務器發送請求, 這時Last-Modified/ETag將能夠很好利用304, 從而減少響應開銷。
(3) 使用CDN
靜態內容 (比如圖片、CSS、Java Script、以及其他cookie無關的網頁內容) 都應該放在一個不需要使用cookie的獨立域名之上。因為域名之下如果有cookie, 那么客戶端向該域名發出的每次HTTP請求, 都會附上cookie內容。這里的一個好方法就是使用“內容分發網絡” (Content Delivery Network, CDN) 。
CDN系統能夠實時地根據網絡流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上。CDN正是出于縮短資源服務器與用戶之間的距離而出現的, 提高了資源的加載速度。
(4) 啟動Gzip壓縮
在發送文本內容之前可以對內容進行壓縮, 瀏覽器支持Gzip、Deflate等壓縮技術, 而HTTP協議上的GZIP編碼是一種用來改進Web應用程序性能的技術。大流量的Web站點常常使用GZIP壓縮技術來讓用戶感受更快的速度。Gzip開啟以后會將輸出到用戶瀏覽器的數據進行壓縮處理, 因此通過在服務器壓縮再發送給瀏覽器, 可以減少文本資源的大小, 提高響應速度和加載時間。表1為YSLow對http://join.qq.com測試有無Gzip的結果。
局限性:一般對于HTML、CSS、Java Script等文本內容為主的文件, Gzip算法的效率比較高, 而圖片、pdf等二進制文件使用Gzip的成效就不明顯。而且Gzip壓縮需要消耗服務器的資源, 而解壓縮需要消耗瀏覽器的資源, 對于比較大的二進制文件具有非常大的性能消耗。過小的文件 (通常小于150個字節) 不宜進行Gzip壓縮。
1.3 HTML優化
(1) 減小HTML的大小
HTML中存在著不少的空格字符, 如果能去除這些空格字符, 就可以減小HTML文件大小。HTML文件縮小的工具有HTMLTidy或者自己用動態語言去除多余空格、制表符、換行、注釋, 以達到壓縮HTML文件的減少文件的大小, 直接提高了網頁的加載速度。減少HTML大小, 可以通過代碼級壓縮, 去除空格字符或注釋等無關的字符。精簡代碼, 減少HTML元素的數量, 注重HTML語義化, 避免嵌套多層, 在減少HTML文件大小的同時, 還提高了頁面渲染速度, 提高了網頁性能。
(2) 檢查不存在或鏈接不到的資源
HTTP請求、響應都需要耗費瀏覽器、服務器的性能, 發出不帶任何益處的請求降低了網頁的性能。如果請求一個不存在的Java Script文件, 并且請求的服務器返回一個錯誤頁面而不是Java Script文件, 那么瀏覽器會等待錯誤頁面的內容下載完畢后才繼續對所在頁面進行解析, 這樣的空鏈接使得情況更糟。
(3) 減小Cookie的大小
瀏覽器對同域下的每個HTTP請求都會發送與該域有關的Cookie數據, 因此在Cookie比較大時HTML頁面采用獨立域名有利于提高Web性能。
表2為HTML頁面Cookie對響應時間的影響的實驗結果。從該表中可以看出:在慢網速下, 一個3000 byte的Cookie或者所有Cookie的容量為3000 bytes將會增加近1 s的延遲等待時間。這個結果進一步說明我們應該盡最大的可能減少Cookie的大小, 從而較少其對頁面響應時間的影響。
1.4 Java Script優化
(1) 壓縮Java Script文件大小
與壓縮HTML文件類似, Java Script通過去除所有的注釋以及不必要的空白符達到精簡, 縮小Java Script文件大小的目的。除此之外, Java Script還可以通過混淆, 改寫代碼, 將函數和變量的名字轉換成更短的字符串, 增加了反向工程的難度, 同時大大減小了代碼的大小。精簡和混淆可以使用JSmin工具。
(2) 將Java Script置于底部
Java Script腳本會阻塞瀏覽器的并行下載 (某些高級版本的瀏覽器會有所優化, 不會造成該現象) , 阻塞后續組件的下載和對其后面內容的呈現。將腳本放在底部可以避免阻塞對頁面的呈現和避免阻塞資源加載, 提高網頁響應速度和加載速度, 并且可以讓代碼更加的干凈, 有利于蜘蛛的抓取。
(3) 采用無阻塞Java Script
使用Ajax加載腳本資源, 加載完成后可以eval或者創建一個script的DOM元素, 然后把響應的資源加入script元素內, 然后嵌入head。
通過Java Script動態創建script的DOM元素, 設置其src并附加到HTML DOM樹上。該方法優于上述方法, 該方法可以跨域獲取腳本。
(4) 最小化重排和重繪
最小化重排和重繪可以通過合并dom操作和樣式的修改:
a:通過css Text或class Name一次性修改多個樣式。
b:通過設置CSS屬性display, 隱藏元素, 應用修改, 然后重新顯示
c:使用代碼片段 (document Fragment) 在當前DOM之外構建一個DOM子樹, DOM操作完畢后, 將其帶回文檔中。
d:將元素用于DOM操作的元素拷貝到一個脫離文檔的節點中, DOM操作完畢后, 將其帶回文檔中。
(5) 取消依賴庫和按需加載
在開發項目當中, 有時為了提高開發效率, 引入了很多Java Script類庫, 而項目中只使用了其中非常少的一部分。這造成過大的Java Script下載, 形成不必要的資源浪費?？梢钥紤]使用精小的Java Script庫代替或者使用原生的Java Script代替。
Java Script的加載會阻塞瀏覽器UI線程。如果將還未用到的Java Script封裝起來, 但需要用到的時候再進行調用加載?；蛘哌M行預加載, 有利于提高網頁性能。
1.5 CSS優化
(1) 精簡CSS
解析CSS的過程中會忽略文件中空格、制表符、換行符、格式化、注釋等字符。除此之外, 對部分CSS (比如font、background、margin等) 。同時在項目中經常會遇到寫完CSS后沒用到, 造成不必要的CSS代碼, 這時可以通過Chrome的Collect CSS Selector Profile進行檢查, 并在代碼中去除。
(2) CSS位置
CSS應該避免行內樣式, 采用外部樣式。外部樣式有利于維護、組件重用以及緩存, 同時縮減HTML文件大小, 在不采用樣式的情況下, 加載速度更快。
需將樣式表放在HEAD標簽中。瀏覽器是根據CSS結合DOM Tree進行渲染的。CSS的加載影響網頁渲染, 置于HEAD開頭有利于瀏覽器在解析BODY內容時, 加載CSS以便達到逐漸呈現的效果, 提高用戶體驗。
(3) 避免耗費性能的CSS寫法
在IE中使用CSS表達式, 它可能會被執行成千上萬次, 導致頁面變慢。
在CSS的規范寫法中, 不同的選擇器的解析性能是不一樣的。樣式系統從最右邊的選擇符開始向左邊匹配規則。只要當前選擇符的左邊還有其他選擇符, 樣式系統就會繼續向左移動, 直到找到和規則匹配的元素, 或者因為不匹配而退出。根據這個匹配的規則。應該避免使用通配符、相鄰兄弟選擇符、子選擇符、后代選擇符和屬性選擇符等低效的選擇區, 更多考慮使用ID選擇符、類選擇符, 規則越具體越好。
1.6 圖片優化
(1) 減少小圖片
在導航欄或按鈕中, 常常關聯多個帶有超鏈接的圖片, 這時可以考慮使用Image Map, 而CSSSprites將一個頁面涉及到的所有零星圖片都包含到一張大圖中去, 當訪問該頁面時, 載入的圖片就不會像以前那樣一幅一幅地慢慢顯示出來了。對于當前網絡流行的速度而言, 不高于200 KB的單張圖片的所需載入時間基本是差不多的, 所以無需顧忌這個問題。利用CSSSprites能很好地減少了網頁的HTTP請求, 從而大大的提高了頁面的性能。而且CSSSprites能夠使圖片之間更加緊湊, 減少圖片字節。所以, 對于小圖片, 可以通過Image Map、CSSSprites、使用內聯圖片等方式合并多張小圖片, 來減少HTTP請求, 減少網頁加載時間, 從而提高網頁前端性能。
(2) 避免加載過大的圖片
在HTML中, 如果需要加載的圖片尺寸過大或者過小, 都可以通過前端HTML對其進行縮放。如果圖片過大, 便造成了不必要的圖片下載開銷。其次, 可以選擇提前將圖片進行壓縮到同比例的大小 (可以通過圖片工具或者在服務器端利用后臺代碼) , 從而選用適當比例的圖片, 有利于節省流量、減少下載開銷。另外, 選用適當的圖片格式有利于提高網頁質量和前端性能。
2 Web性能優化實踐
2.1 指尖點餐系統
指尖點餐系統是信息化移動生活中, 將智能平板聯合HT-ML5技術的發展用到點餐流程中, 節約了餐廳的人力, 提高餐廳的工作效率、經營收益和顧客滿意度。該點餐項目基于Web新技術HTML5搭建, 取代本地應用, 縮短開發周期, 更新周期短, 維護成本低, 硬件配置低等優點。
但其面臨性能優化問題, 在網速較慢的情況下, 網頁加載速度很慢, 極大制約了該系統的使用和降低了顧客的滿意度, 這也是普遍HTML5應用相對于本地應用的弱勢之一。
2.2 性能檢測工具及測試環境
1) 網絡層面上性能檢測工具
(1) 采用各個瀏覽器的開發工具 (如firebug) 查看代碼、元素、加載情況以及清除緩存等。
(2) 利用YSLow、pagespeed等工具查看網絡層面上的性能缺陷。
(3) 利用Webkit瀏覽器內置開發工具查看網絡network、Timeline。
(4) 利用Fidder2來限制網速, 以及查看HTTP請求信息、請求匯總報告。
2) 瀏覽器層面上性能檢測工具
(1) 利用Webkit瀏覽器內置開發工具的profiles監測cpu、頁面渲染、Java Script執行、CSS利用率等。
(2) 利用Speed Tracer瀏覽器性能監測工具來監測瀏覽器UI線程、渲染重排、布局板面以及Java Script執行效率代碼進行級別優化等。
(3) 使用Spirent測試工具, 采用平均事務響應時間、待測系統資源利用率和每秒事務數作為主要測試指標, 綜合評測Web應用的軟硬件性能, 并快速定位Web應用系統的性能瓶頸。
3) 測試環境
(1) 清空瀏覽器緩存。
(2) 清空DNS緩存 (ipconfig/flushdns) 。
(3) 慢網速下測試 (使用Fiddler工具設置512 KB帶寬) , 10M網速下測試UI Thread。
(4) 關閉不相關網頁, 開啟監測工具 (Speed Tracer) 。
2.3 性能評測系統設計與實現。
(1) Web應用評測過程
在Web應用評測中, 每進行一輪測試時, 需針對測試目標設計測試場景, 通過Spirent實施一次負載測試, 統計分析各項指標, 生成測試報告, 根據需要分析查找系統性能瓶頸, 對相關瓶頸進行優化, 如圖3所示。根據需要和代價選擇測試、優化的迭代次數, 選擇符合用戶需求的最佳迭代方案。
(2) 測試場景設計和選擇
性能測試應該是一個全面的測試, 測試目標系統各項能力、發現系統的問題、定位系統瓶頸。如何設計測試用例, 實現以最少的測試用例, 最大發現系統的性能瓶頸, 為優化提供指導。因此, 既要從事務中的選取具有業務代表性的事件進行單獨測試, 又要對綜合業務進行測試, 防止因綜合業務間事務或數據的相關性發生讀寫鎖等待, 并且設計測試用例時應盡量減少用例間的重疊, 同時又無遺漏。
在指尖點餐系統中, 最復雜的頁面為點餐頁面, 該頁面使用最頻繁, 結構最復雜, 頁面操作多, UI交互多等特點。因此對該頁面進行優化實踐, 對該系統最具現實意義。圖4為該點餐系統的點餐頁面截圖。
(3) 負載測試流程設計
Spirent負載測試主要流程如圖5所示, 其核心是如何配置參數使測試能完成測試目標和對測試日志的分析, 找出系統的瓶頸;負載由Spirent工具自動生成。
2.4 尋找性能優化瓶頸
采用HTML5點餐應用項目中的點餐頁面進行的測試, 圖6為點餐頁面優化前首次加載的Timeline。
圖6為點餐頁面采用Fiddler和Speed Tracer所檢測到的Timeline和UI Thread拼合的測試數據。從該圖中可以看出的問題如表3所示。
所以針對頁面渲染采取一定的性能優化措施尤為重要。
2.5 性能優化
(1) 服務器端優化
設置緩存后的二次加載后的二次加載如圖7所示。
開啟Gzip壓縮后的首次加載Timeline如圖8所示。
開啟Gzip后加載時間較少了約54%, 總資源大小減少了約42%, HTML/JS/CSS等文件減少了70%左右。
(2) Java Script優化
針對該項目進行的Java Script優化, 主要精簡代碼, 去除j Query依賴。使得Java Script文件大小從82.9 KB變到3.8 KB。加載時間從22 s提高到11 s, 減少了50%的加載時間;腳本的執行時間從296 ms變為132 ms, 減少了54.5%。
同時通過優化DOM操作使頁面渲染Paint減少了34% (19 ms) , DOM事件響應時間減少了71.5% (10 ms) 。相應Parse HTML增加了12 ms, 這是由于采用inner HTML添加元素需要解析成DOM導致的。但是整體來說UI線程減少了20 ms左右。圖9為進行Java Script優化后的測試結果圖。
(3) Java Script、HTML、CSS組件優化
從項目之前的Timeline可以看出CSS的三個文件大小都比較小, 分別為1、1.4、2.6 KB。因此考慮將三個CSS小文件合并, 以減少HTTP請求, 提高加載資源速度。合并后的大小為3.9 KB。文件大小減少了1.1 KB, 同時減少了2個HTTP請求, 頁面加載時間減少了約1秒。
對Java Script、HTML、CSS組件進行代碼級別壓縮, 去除可以去掉的字符以及對Java Script進行混淆。頁面大小減少了1.8 KB左右, 頁面加載時間縮短了約0.5秒, 圖10為操作后的效果圖。
(4) 圖片優化
圖片優化采取無損壓縮, 無損壓縮后總體圖片的大小減少了8.8 KB, 縮減了5%。各個圖片的無損壓縮效果不一, 比如sp.png壓縮縮減了26%, 其余均為3%左右。頁面整體加載速度提升了40 ms左右。相對于不同圖片以及圖片很多時, 進行無損壓縮可能帶來意想不到的效果, 不過對于本網頁來說效果一般。圖11為圖片進行無損壓縮后頁面的Timeline。
調整尺寸后, 圖片總量減少了124.1 KB, 縮減了81%。網頁加載速度提高了接近2 s。如圖12為優化圖片尺寸后的Time Line, 由此可見適當的時機對圖片的尺寸進行優化, 有利于提高網頁性能, 提高加載速度, 避免加載過大資源造成浪費。
(5) 細節調整
從圖12的Timeline中可以看出, 頁面中含有一個錯誤請求。該錯誤請求為favicon。Favicon可以讓瀏覽器的收藏夾中、頁面上方除顯示相應的標題外, 還以圖標的方式區別不同的網站, 很多網站并沒有添加favicon, 因此造成了錯誤請求, 浪費了資源。
2.6 優化前后對比
從表4點餐頁面優化前后的對比數據分析中可以看出, 加載時間的減少、頁面渲染時間的減少極大提高了應用頁面的呈現速度, 頁面腳本執行時間的降低提高了該應用的響應速度和整體性能。
3 結語
本文研究了與Web前端相關的理論, 歸納影響Web前端性能的因素, 并對這些因素進行分析提出整體性、通用性的解決方案, 具體如下:
(1) 首先對于Web前端相關的環境以及技術作為起點, 研究與前端性能相關的機制或環境的原理, 并分析其對Web前端性能的影響有哪些以及如何影響。
(2) 針對分析與Web前端性能有關的因素造成的影響, 提出整體性 (服務器方面、Java Script、HTML、CSS、圖片) 的解決方案。歸納多種解決方案, 并適當分析優劣、使用場合建議。有利于實際項目開展過程中針對不同方面提前進行優化。
(3) Web前端性能不能僅僅局限于理論和測試, 而且與業務密切相關。本文實現一個基于HTML5技術的Web移動應用, 通過具體分析該項目的性能瓶頸, 運用以上分析的理論和解決方案對其進行性能優化。使用性能以及網絡檢測工具檢測通過具體解決方案進行優化前后的對比, 并進行分析, 從而提高了本文前端優化方案的可行性、真實性, 豐富了Web性能解決方案的具體實施。
摘要：針對Web前端性能低下的問題, 通過分析歸納Web中從后端到前端的B/S架構原理、瀏覽器緩存、瀏覽器的加載方式、服務器關于HTTP相關的配置等過程中一些影響前端性能優化的因素, 系統地提出一個旨在提高網頁加載速度、呈現速度和用戶體驗, 整體性、通用性強的完整Web前端性能優化解決方案。該解決方案包括服務器端優化、HTML優化、Java Script優化、CSS優化、圖片優化等內容。并在HTTP代理工具Fiddler搭建的512 KB慢網速下通過Speed Tracer監測UI Thread, 尋找基于HTML5技術的Web移動電子商務項目“指尖點餐系統”的點餐頁面前端性能中的瓶頸, 根據所提出的Web前端性能優化解決方案對其進行優化實踐。優化前后的Timeline以及UI Thread對比分析表明, 優化后加載時間降低了82%, 頁面渲染降低了32%, 腳本執行減少了79%。
web前端畢業論文題目范文第3篇
一、前端MVC框架思想
(一) 傳統MVC模式基本概念。
在MVC模式中, 一個應用被分成3個層次———模型層、視圖層和控制層, 它們在應用系統中分別擔當不同的角色, 完成不同的任務。Model:即數據模型, 用來包裝和應用程序的業務邏輯相關的數據或者對數據進行處理, 模型可以直接訪問數據。view:視圖用來有目的地顯示數據, 在視圖中一般沒有程序上的邏輯, 為了實現視圖上的最新功能, 視圖需要訪問它監視的數據模型。Controller:控制器調控模型和視圖的聯系, 它控制應用程序的流程, 處理事件并作出響應, 事件不僅僅包括用戶的行為還有數據模型上的改變?？刂破魍ㄟ^捕獲用戶事件, 通知模型層作出相應的更新處理, 同時將模型層的更新和改變通知給視圖, 使得視圖作出相應的改變, 因此, 控制器保證了視圖和模型的一致性。MVC模型框圖如圖1所示。
(二) 前端MVC框架。
目前的前端MVC框架有很多, 如Backbone.js, Angular.js, Ember.js, Javascript MVC, Knockout.js等。雖然都是基于MVC, 但是每個框架都有自己處理問題的方法, 下面簡要分析Backbone.js, Ember.js和Angular.js的特點以及適用范圍:Backbone.js可以靈活地解決應用中層次分離問題, 并且支持持久層和REST同步服務、models、views、事件驅動、模板和定位等。它允許model修改后View自動更新。而且很多大型公司都使用它來構建應用, 并且有非常好的社區提供支持。Ember.js適合桌面級別的應用開發, 擁有模塊化、標準的界面, 支持MVC的特性, 不需要自己處理所有的東西, 支持持久化、計算相關屬性并且自動更新模板, 支持正確的狀態管理, 同時它擁有非常詳細的文檔和模板說明。Angular JS是由Google創建的一種JS框架, 它可以擴展應用程序中的HTML詞匯, 從而在Web應用程序中使用HT-ML聲明動態內容。支持快速測試、URL管理和分離的MVC。雖然基于MVC模型的框架之間有很多不同之處, 但是總體來說, Model負責保存view需要的數據以及數據處理邏輯, 例如讀寫, 更新, 刪除, 驗證, 轉換等。View負責接收并顯示Model提供的數據以及接收用戶的輸入, 并且響應事件, Model更新后及時將更新反饋給用戶。Controller處理業務邏輯和事件邏輯。所以一個Web應用的流程通常是這樣的:用戶在View上進行操作———比如在文本框輸入數值或是點擊按鈕。Controller處理這個動作。Controller通過Model對數據進行增刪改查, 將其傳遞到View。View將數據展示給用戶。
二、前端MVC框架的意義
(一) 前端MVC框架與j Query等庫之間的區別。
提到前端框架, 很多人都會想到j Query, 那么MVC框架跟j Query這樣的框架有什么區別呢?很多程序員覺得j Query已經可以滿足前端開發中的需求, 還有必要再引入這種MVC框架嗎?嚴格來說, j Query這些都不能算框架, 而是算庫。庫和框架的區別是:庫, 解決的是代碼或是模塊級別的復用或者對復雜度的封裝問題, 庫是一種工具, 它提供了很多封裝好的方法, 你可以用, 也可以不用, 即使你用了, 也不會影響你自己的代碼結構。而框架, 更多的是對模式級別的復用和對程序組織的規范, 是面向一個領域來提供一套解決方案, 提高開發效率。如果你使用該框架, 就得遵守該框架所規定的規則。二者最主要的區別是:j Query以DOM操作為中心, MVC框架以模型為中心, DOM操作是附加的。所以二者解決的是不同的問題, 前端MVC框架最終將達到的目的是帶來一整套工作流程的變更, 這樣后端工程師也可以編寫前端的模型代碼, 把它跟后端徹底打通, 交互工程師處理UI跟模型的互動關系, U工作人員可以專注、無障礙地處理HTML源碼, 把它們以界面模版的形式提供給交互工程師。這一整套協作機制能夠大大提高開發效率, 生產效率將真正踏進工業化的階段。
(二) 前端MVC框架適用的范圍。
很多人質疑, 將MVC應用到前端開發中有意義嗎?在很多做后端開發的程序員眼中, 前端相對于后端來說是很薄的一層, 更加不能理解還要在前端開發中搞MVC架構, 同時多數做互聯網前端開發的程序員們也感受不到MVC框架的重要性, 這就提出了一個問題———前端MVC框架適用的范圍。出現這種情況是因為在這些項目的體系里, Model的這一塊不夠復雜, 在傳統軟件開發領域中, Model的部分是代碼最多的, View的相對少一些, 然而在互聯網領域里, 大部分時候情況基本是相反的, 正是由于Model部分不夠復雜, 所以此時應用MVC框架就會覺得有些大材小用, 甚至會把簡單的問題復雜化。
因此前端MVC框架的適用范圍是要看產品類型的, 如果是頁面型產品, 應用只是依賴于服務器來生成Web頁面和視圖, 并且只需要使用一些簡單的Java Script或者j Query來使得應用更加具有互動性, 那當然j Query這類庫比較好用了, 使用框架就不是很有必要。但是如果是應用軟件類產品, 這就太需要了, 比如你開發的程序可能需要和API或者服務器通訊, 而且要求大量的視圖操作或者數據操作, 你將發現使用一個成熟的框架非常有幫助。
三、結語
MVC在前端開發中的應用有局限性, 簡單的項目如果使用MVC框架會導致項目變復雜。但隨著Web前端的復雜度不斷增加, 前端MVC框架也在不斷地發展, 開發應用軟件類復雜產品時, 前端可以通過使用合適的MVC框架來提高開發效率。當前端開發進入工業化的時候, 前端開發人員的主要職責有兩種, 如果要開發的產品是普通的, 就使用工業手段批量生產, 使用MVC框架做好架構和組件重用, 做得快但細節不是很講究。如果開發的產品是有特色的, 就要名家設計, 手工打造, 前端開發人員應根據項目和產品重新規劃設計并實現自己的架構和代碼。
參考文獻
[1] .曹劉陽.編寫高質量代碼——Web前端開發修煉之道[M].北京:機械工業出版社, 2010
[2] .蒲筱哥.MVC設計模式在PHP開發中的應用[J].計算機與現代化, 2011
web前端畢業論文題目范文第4篇
1 Web前端技術體系以及工作分析
Web前端技術體系中, HTML、CSS、Java Script成為三個支撐性質的關鍵因素, 三種語言分別承擔不同職能, 并且執行和遵守不同標準, 同時又保持著密切的合作關系。
而想要面向Web前端技術的實現展開良好的優化, 首先需要切實對其工作過程中的每一個細節有所了解, 在此基礎之上, 才能獲取良好效果。
當前的網絡環境中廣泛采用B/S結構, 因此從客戶端的瀏覽器展開相應的分析, 無疑符合當前的網絡環境技術特征。在瀏覽器對服務器展開頁面請求的時候, 首先由用戶在瀏覽器端輸入網址, 來實現對于url的請求, 而后通過DNS服務器對域名進行解析, 獲取到該域名所對應的頁面ip地址, 該地址可以讓計算機直接實現訪問。在此基礎之上, 位于客戶端的瀏覽器會面向對應的服務器發送HTTP請求, 而服務器端在接收到相應的HTTP請求的時候, 依據瀏覽器對應的url請求來確定對應的目標文件。該目標文件通常以一個頁面網絡地址的形式存在, 諸如ASP、PHP或者JSP文件等。而Web服務器則在這個過程中負責依據相應頁面文件的具體內容以及url相關參數, 來通過數據庫或者相關文件實現對于資源的調用, 并且最終實現對于數據的組織和HTML頁面的生成。
在生成了HTML文件之后, 服務器執行來自于客戶端瀏覽器的HTTP請求, 將生成的HTML文件發送給瀏覽器, 而瀏覽器則負責接收來自于服務器的HTML文件。隨后, 瀏覽器會針對HTML文件展開解析, 并且進一步面向服務器請求其中的鏈接資源文件, 諸如Java Script、CSS、多媒體資源、內嵌網頁等。服務器會接到瀏覽器對于資源文件的HTTP請求, 并且將對應的資源文件通過網絡發送給客戶端瀏覽器。瀏覽器在接到這些資源文件之后, 進行整理并且依據規則呈現到頁面環境中, 同時承擔對相應資源的展現方式實現重新排版的職能。在這個過程中, 瀏覽器會自上而下執行HTML文檔, 當遇到相應的頁面腳本的時候, 會對腳本進行分析, 并解釋執行相應的腳本代碼。當執行腳本時, 將阻塞之后的鏈接文件的加載。
2 Web前端技術優化工作重點分析
對于頁面的存在而言, 其核心價值在于傳遞相應的信息并且通過信息的呈現滿足信息消費者的相應需求, 在互聯網的整體環境之下, 如果這個信息獲取和呈現的過程時間過長或者展開形式不佳, 必然會影響到用戶的信息消費過程體驗。從信息提供的角度看, 是沒有實現信息本身的價值, 而從信息獲取的角度看, 這種狀態則有可能影響到信息對稱環境的產生, 嚴重的情況下甚至會影響到正常的社會行為。
基于這樣的考慮, 有必要針對Web前端技術展開對應的優化, 切實提升頁面對于信息呈現的綜合體驗, 實現信息自身價值?？偨Y而言, 有如下幾個主要的優化方面, 可以作為當前的優化工作重點對待。
2.1 HTTP請求優化
針對HTTP請求展開優化, 減少不必要的請求, 是切實提升整個Web前段技術體系的首要職責與工作重點。一個完整的HTTP請求包括多個方面, 諸如DNS尋址、建立瀏覽器與服務器之間的連接、雙方數據的發送、瀏覽器等到服務器展開數據的傳輸等多個環節。而這些環境中的每一個, 都必然會占用一定的時間, 將多個細節時間進行累加, 必然會形成用戶端的時間成本, 同時也會消費掉整個數據通路商的帶寬資源。因此想要從時間上實現優化, 實現用戶體驗的提升, HTTP請求數量的控制必不可少。常規的做法包括將多個CSS文件或Java Script文件合并成一個, 確保其能夠在一次請求下加以實現;在圖片地圖的優化方面, 則應當考慮在一個圖像上劃分不同區域映射不同的鏈接;而對于內聯圖像, 則應當注意保持圖像與文本一同實現下載和顯示。
2.2 優化文件規模
對于這一方面而言, 其工作相對較為瑣碎, 主要工作內容包括針對Java Script和CSS文件以及對應的代碼展開優化。優化工作重點主要有針對不必要的html標簽進行剔除優化, 以及避免內聯式樣式存在, 此外, 對于CSS代碼優化同樣也是這一方面工作的重點內容。
2.3 內容優化
對于這一方面的工作主要可以考慮從兩個角度出發, 即將樣式表放在頂部同時將script放在底部。CSS本身具有覆蓋層疊的特征, 因此瀏覽器通常會考慮在完全加載完成之后再展開渲染工作, 因此如果想要實現Web優化, 則可以考慮從CSS本身的加載著手實現。而對于將script放在底部這一做法, 則主要是防止script腳本的執行阻塞頁面的下載, 從而造成頁面組件下載速度不足, 頁面加載時間過長等問題的發生。
2.4 減少DNS查詢次數
DNS是另一個造成等待的因素, 通常一次DNS解析20-120毫秒時間, 如果頻繁發出DNS解析請求, 必然會導致信息傳輸體驗的降低。更為重要的在于, DNS的查詢本身是瀏覽器進一步工作的基礎, 在完成查詢之前, 瀏覽器不會下載該域名之下的任何相關內容, 因此控制DNS查詢請求的次數, 對于Web前端優化工作而言至關重要。
2.5 避免重定向
這同樣是造成等待時間過長的因素之一, 其形成原因相對復雜, 從根本上看, 每一次重定向都會增加一次Web請求。對于這一方面, 可以考慮在Web站點子目錄的后面添加“/”, 實現有效避免一次重定向的目標。
3 結論
Web前端開發技術的優化水平, 直接關系到用戶體驗, 因此必須予以重視。針對這一問題, 只有在實際工作中不斷深入學習相關領域經驗和技術, 并且多展開對于頁面展開狀態的觀察, 有的放矢展開優化, 才能取得良好效果。
摘要：首先針對Web前端技術體系以及其主要的工作機制展開分析, 對于整個工作流程進行討論, 而后在此基礎之上, 進一步就該技術環境中的主要優化工作方向進行有針對性的說明。
關鍵詞：Web,前端,技術,優化
參考文獻
[1]曹劉陽.編寫高質量代碼:Web前端開發修煉之道[M].北京:機械工業出版社, 2010.
[2]鄧小善, 龍艷軍.高訪問量網站性能監測與優化的設計與實現[J].現代計算機:專業版, 2009 (2) .
web前端畢業論文題目范文第5篇
關鍵詞：Web前端,開發技術,優化方向
1 Web前端技術的體系和其工作性質分析
在Web前端技術相關的體系中有3個具有支柱性質的關鍵性因素, 分別是CSS、Java Script和HTML。這3種語言在Web前端技術構成中所扮演的角色是不同的, 雖然這3種語言解決的問題是不一樣的, 但是它們之間還有著密不可分的聯系。
想要針對Web前端技術進行優化, 并且確保優化后的Web前端技術能夠更好的展開, 首先是需要相關工作者對Web前端的工作過程中涉及到的所有細節都需要詳細了解, 只有在充分的了解的基礎上, 才能夠對Web前端進行優化, 并取得良好的效果。
現階段的網絡環境中, 大多數都是B/S結構, 所以應把任務重心放在對用戶瀏覽器進行有關的分析, 是最為貼近現階段的互聯網網絡環境特征的。用戶獲取信息的過程, 一般情況下是, 在瀏覽器上對服務器進行頁面展開請求, 然后輸入用戶想進入的網址, 通過DNS服務器對輸入的域名進行解析, 最后進入網址, 以便解決用戶對訪問的要求。在這些基本的操作基礎上, 用戶的瀏覽器向服務器進行相關的HTTP的請求, 服務器接收到HTTP的請求時, 會依據請求來確定對應的文件信息。而Web服務器在當前的過程中依據相對應的內容和相關的URL參數, 對數據庫的相關文件實現使用, 并最終滿足用戶的最終需求。
HTML形式的文件在瀏覽器生成之后, 服務器會執行用戶對于瀏覽器的相關請求然后將完成, 有效的HTML形式文件傳送到用戶使用的瀏覽器當中, 同時瀏覽器也會接受服務器中的有效文件。在這一系列的操作中, 不論是用戶對網址的輸入, 還是DNS的每次請求, 都勢必會花費用戶的時間, 而技術人員進行優化的最終目的就是使用戶的體驗滿意度增加, 那么, 在輸入網址到獲得信息中間的各個過程都是技術人員可以考慮進行優化的地方[1]。
2 Web前端技術優化工作重點分析
傳遞消費者所需要的信息, 以此來滿足消費者的需求, 是頁面存在的核心價值, 在當今互聯網的大環境下, 如果消費用戶獲取需求信息和等待信息呈現的用時過多, 或者所需信息的展開效果不夠好, 這就必然會對消費者的體驗產生影響。而從互聯網網絡提供信息這一角度來分析, 這就是沒有將信息本身具有的高效性進行良好的體現, 從客戶對于提取的信息角度來看, 這種獲得信息的狀態會對信息對稱環境造成不良影響, 如果情況相比較嚴重可能還會影響到這些信息在相關社會行為的使用。
根據以上出現的問題, 對于Web前端技術進行相關的優化和互聯網頁面信息展開的體驗進行切實的提升, 從而實現信息的價值?？偠灾? 相關工作人員可以從以下幾個方面對Web前端進行更新, 更新技術人員應將以下幾點當作更新目標, 將Web前段進行更好的優化。
2.1 關于HTTP優化的請求
技術人員針對HTTP的請求進行優化, 主要是針對不必要的、消耗時間的請求應當進行減少, 這是可以提高全部的Web前端技術體系的工作重點和首要的職業。一個完整的HTTP的請求, 其中包括很多方面, 比如, DNS尋址、雙方間數據的傳送、服務器與瀏覽器之間創建連接等等許多環節。而這許多環節中的每一個, 必然都會需要一定的時間來完成, 每一個細節所需要的時間進行相加, 就是消費者在展開信息前所需要的時間, 這些時間會成為用戶端的時間成本, 同時也是對數據通路商的寬帶資源的一個消耗。因此對時間上進行的優化是無需質疑的, 那么技術人員對HTTP請求時的數量就必須進行有效的控制。常用的做法是將多個的CSS文件和Java Script文件集合成一個有效文件, 確保在一次操作下對多個文件進行打開;同時也要在圖片地圖方面進行優化, 技術人員可以考慮, 在圖像上的不同區域注入不同映射的連接;而對于網頁中需要的內聯圖像, 要盡可能的保持圖像能夠與文本一同下載并顯示出來。
2.2 對其文件的規模上進行優化
針對文件的規模這一方面進行優化, 技術人員需要進行的工作是較為瑣碎的, 其中主要的工作內容是CSS文件和Java Script文件他們所涉及的代碼進行展開相應的優化, 其所開展的工作主要是對一些可以不用存在的HTML標簽進行相對應的刪除, 以避免其存在聯式或是樣式這兩方面, 以達到優化的效果, 除此之外, 另外還有一項不能忽略的工作就是對CSS的研究。
2.3 對其內容上進行優化
對于內容的更新, 工作人員主要可以從樣式表和Script開始著手, 可以將樣式表放在頂部, 同時將Script放在底部。因為CSS具有層疊性和覆蓋性的特征, 所以通常的情況下, 瀏覽器會在對所需文件加載完成后, 再來考慮進行工作渲染。所以想要實現對于Web客戶端的更新, 可以從CSS本身加載方面來考慮。另一方面, 將Script放在底部的主要原因, 是為了防止Script腳本在執行期間對當前頁面產生了阻礙導致下載速度的緩慢, 進而使頁面及其相關組件下載速度過慢, 頁面加載的時間過長, 等等問題的產生[2]。
2.4 最大程度的減少DNS的使用次數
DNS是導致消費用戶等待時間過長的另一大原因, 通常解析一次DNS大概需要20ms~120ms的時間, 如果DNS的解析請求過去頻繁, 就會導致消費者等待的時間變長, 降低信息傳輸的質量。更重要的是, DNS查詢本身就是瀏覽器可以進一步完成工作的基礎, 所以, 技術人員針對DNS查詢請求次數要進行有效的控制, 對于Web前端技術來說, 對其的優化的作用也是十分關鍵的。
2.5 對重定向的有效避免
這個也是造成消費用戶等待的時間太長的原因之一, 導致它產生的原因比起其他幾個原因相對復雜一些。每一次的重定向都會導致頁面增加一次對Web請求。針對這一原因, 技術人員可以考慮一下在Web目錄后面添加“/”, 保證對重定向的有效避免[3]。
3 結論
Web前端的技術開發的優化水平, 這是影響消費用戶的自身體驗的關鍵, 所以這需要引起運營商對此的重視和注意。此外還需要對這些已經出現的問題, 進行有針對性改進和優化。只有技術人員不斷的在實踐工作中對相關領域進行學習, 同時根據實際情況積累經驗和技術, 并且對頁面的工作狀態進行觀察, 從多個角度入手, 才可以達到Web前段技術優化能夠取得良好的效果。
參考文獻
[1]陳鯡.Web前端開發技術以及優化方向分析[J].新媒體研究, 2015 (7) :39-40.
[2]曹劉陽.編寫高質量代碼:Web前端開發修煉之道[M].北京:機械工業出版社, 2010.
web前端畢業論文題目范文第6篇
一、Web前端開發技術研究
Web前端開發技術發展主要經歷了三個階段, 分別是HTML技術、css2.0站點構建和維護以及CSS+DIV為核心技術的頁面重構技術。這三者都能夠對Web前端開發技術的優化造成一定影響, 它們都可以所作是網頁的關鍵性語言, 具有各自鮮明的特點和職能, 并且在對應的執行標準內容上也會存在一定差異[1]。每個Web前端開發設計人員都必須正確掌握了解到HTML、JavaScript、CSS之間是存在關聯性的, 它們屬于一種相互促進、相互協調合作的關系。因此, 當Web前端開發設計人員在對該項技術展開優化工作時, 要充分考慮到它們三者的應用重要性。眾所周知, 現代人們的工作生活早已離不開計算機網絡, 隨著時間不斷推移, 網絡系統會變得日益復雜起來, 這樣一來就造成了計算機網頁各種問題的發生。在Web前端開發設計過程中, 相關工作人員更加要關注到如何提高用戶的網站瀏覽體驗水平。一般情況下, 用戶在瀏覽某個網站時首先要輸入準確的對應網站地址鏈接, 并發出訪問請求, 該請求對象就是URL。服務器會根據用戶輸入的域名展開分析工作, 最后會顯示出來一個IP地址, 然后用戶就能夠成功訪問該IP地址上面的相關信息內容。在實際生活中, 用戶常見到的網頁內容基本都是經過瀏覽器排版處理, 如下圖1所示為網站瀏覽器排版具體處理形式。
二、基于網站制作的Web前端開發設計優化
(一) 文件規模的優化設計
Web前端開發設計人員在展開對文件規模優化作業時, 需要從CSS和JavaScript文件入手, 當然這也只是文件規模優化的一小部分內容。文件規模的優化處理水平會直接影響到計算機市場用戶的網站瀏覽體驗過程, 相關技術人員要圍繞HTML標簽展開科學合理剔除工作, 這樣能夠防止內聯式問題的發生, 影響到計算機瀏覽器的正常穩定運行。與此同時, Web前端開發設計人員還必須高度重視對CSS代碼的優化工作內容[2], 工作人員要將CSS代碼優化內容與最想Web前端開發技術有機結合在一起, 以此來做到CSS代碼優化的系統規范性和客觀性, 確保能夠符合市場廣大用戶的網站瀏覽需求和習慣特點。
(二) 網頁內容的優化設計
基于網站制作的Web前端開發設計工作必須注重對網頁內容的優化設計, 其會影響到網頁的實際運行效果。首先, Web前端開發設計人員要將內容優化注意力放在樣式表當中, 如果樣式表處于頂部位置, 那么相對應的處于底部的就是Script。然后, Web前端開發設計人員要著手CSS加載展開優化處理, 科學考慮到CSS的覆蓋疊成特殊性[3], 確保腳本設計不會對網站頁面造成消極性的影響, 并同時防止用戶在組建下載時出現下載速度過慢現象的發生, 亦或者是網站頁面加載時間偏長問題的出現, 這些都會導致網站網頁運行工作效率的降低。因此, 每個Web前端開發設計人員在對網站頁面內容進行優化處理時, 都必須全面考慮到各個細節之處對整體頁面運行的影響和作用。
(三) DNS查詢次數的優化設計
基于網站制作的Web前端開發設計工作要加強對DNS查詢次數的優化設計, 因為DNS是影響網站網頁時間成本增加的一個關鍵因素。一般情況下, DNS解析需要消耗掉20毫秒到120毫秒的時間, 面對此種情況就會引發這樣一個問題, 一旦對DNS解析請求次數過多, 就會導致網站網頁無法第一時間作出反應, 并且還會促使網頁時間成本的持續疊加, 網頁信息內容呈現速度會因此而大打折扣, 影響到市場用戶的瀏覽體驗。針對于此, 相關工作人員在Web前端開發技術優化中, 要加強對DNS查詢請求次數的科學優化設計, 確保能夠最大程度提高綜合水平, 為用戶提供更加良好的體驗服務環境。除此之外, 重定向性質也會影響到網頁時間成本的增加, 工作人員要從其細節方面入手優化。就比如在其中合理添加“/”, 這樣能夠幫助降低網頁時間成本。
三、結束語
綜上所述, 基于網站制作的Web前端開發設計需要從用戶需求角度出發, 為了科學有效制作出能夠滿足市場用戶不同需求特點的網站網頁, 開發設計人員除了要充分掌握好各種先進的Web前端開發技術, 還必須注重網頁設計的細節之處, 要從網頁內容、文化規模以及DNS查詢請求次數入手展開優化設計工作, 有效提升用戶的網站網頁瀏覽體驗水平。
摘要：基于我國科學技術的不斷完善發展, 互聯網產業發展得到了質的飛躍。Web實質就是全球廣域網, 它象征了全球信息時代的到來。Web前端開發設計與網頁制作工作存在著密不可分的聯系, 最開始的網站設計大多數都是以靜態為主, 市場用戶主要是在各大網站上進行信息瀏覽閱讀。在網站制作下, 現代開發技術人員需要通過科學采用交互方式完成對網站制作技能的創新開發。本文將進一步對Web前端開發設計技術和方法展開分析與探討, 旨在為同行業者提供科學參考依據。
關鍵詞：網站制作,Web前端開發,技術
參考文獻
[1] 龔電花.基于網站制作的Web前端開發技術與優化[J].信息通道, 2018 (7) :187-189.
[2] 陳月, 秦福建.Web前端開發技術以及優化方向探究[J].信息與電腦 (理論版) , 2016 (04) :35.