DOCSLIB.ORG

Link Prefetching in Mozilla: a Server-Driven Approach ∗

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Link Prefetching in Mozilla: a Server-Driven Approach ∗ Link Prefetching in Mozilla: A Server-Driven Approach ∗ Darin Fisher Gagan Saksena [email protected] [email protected] Abstract siderably between products. For example, some of these products analyze the contents of pages or the This paper provides a synopsis of a server-driven user's browsing history to predict what the user link prefetching mechanism that we have designed might visit next. Indeed, a large body of research and implemented for the Mozilla web browser, a covering a variety of approaches to prefetching exist popular Open Source web browser. The mecha- on this topic [10, 11, 12, 13, 15, 16]. Other appli- nism depends on the origin server or an interme- cations rely on some cooperation between browser diate proxy server determining the best set of doc- and server. uments for the browser to prefetch. The browser follows prefetch directives provided by the server, In addition, content authors have devised ad-hoc either embedded in an HTML document using the JavaScript-based techniques to prefetch content. <LINK> tag or specified via Link HTTP response These generally involve loading content into hid- headers. The browser determines when best to pre- den <IMG> or <IFRAME> HTML elements so as to fetch the specified URLs based on its own heuristics. pre-populate the browser's document cache. While In this paper, we describe the mechanism and dis- these JavaScript-based approaches have the bene- cuss some of the practical issues that impacted its fit of working with most browsers, they often re- design and implementation. sult in complex JavaScript code that is difficult to maintain. With such techniques, the browser is not 1 Introduction able to prioritize normal requests above prefetch re- quests. As a result prefetch requests may end up Web caching is a common optimization used by web competing with normal requests for network band- browsers to reduce latency for the user when they width. Additionally, JavaScript-based approaches re-visit a web page. For narrow-band Internet con- afford the server little opportunity to control traf- nections, the performance gain can be dramatic. It fic and limit server load resulting from prefetch re- is of interest therefore to consider mechanisms that quests. would enable the web browser to pre-populate its cache of documents, such that when the user ini- In this paper we describe a link prefetching mech- tially views a web page, the latency will be nearly anism that involves modifications to both the reduced to that of loading the web page from the browser and the server. It is designed to pro- local cache. This technology is commonly referred vide a solution to prefetching that is \friendlier" to as prefetching and has been shown to be effective to both client and server, specifically addressing in reducing latency in the Web [14]. some of the shortcomings of existing ad-hoc meth- ods. The browser follows special directives from Despite the potential benefit of prefetching, it has the web server (or proxy server) that instruct it to not been widely deployed at this time. In addi- prefetch specific documents. The server can inject tion to the family of Mozilla-based browsers, only these directives into an HTML document or into a few production web browsers (e.g., WebTV and the HTTP response headers. The browser responds iCab) and personal web proxies (e.g., NetSonic Pro, to the prefetch directives after it finishes rendering Naviscope, and Wcol) support some form of link the document (or HTTP response) containing the prefetching. The methods of prefetching vary con- directives. This mechanism allows servers to control precisely what is prefetched by the browser, and it ∗This work was performed at Netscape/AOL during 2002. allows the browser to determine when best to pre- [The \next" link relation type] refers to the fetch documents based on local network inactivity, next document in a linear sequence of doc- browser idle time, etc. uments. User agents may choose to pre-load the \next" document, to reduce the perceived We chose a server-driven approach to link prefetch- load time. ing because we believe that servers (including in- termediate proxy servers) can better predict what We have implemented this mechanism in the users are likely to visit next. Since pages often con- Mozilla browser along with some variations on this tain numerous hyperlinks that the user is unlikely same approach, which are described below. The to follow, it is generally difficult for the browser to WebTV browser also follows this recommendation determine the best subset of hyperlinks to prefetch. [1]. (Our prior approach involved extending all For example, an origin server or content author may linked tags with a prefetch marker attribute [2] know that the user is browsing through a series of and using pathfiles [3] to prefetch dynamic content. large images or documents (e.g., an image slide- That technique had its limitations and has since show or pages in a book) in which case it would be evolved into our current implementation.) advantageous for the browser to prefetch the next image or document in the series. Or, while the user Motivated by the fact that the \next" relation is is confronted with a login prompt, the site might intended to represent the \next" document in a like to have the browser prefetch the portions of the linear sequence of documents, and given that web site that do not require user authentication. In such pages should be able to specify multiple documents cases there is a static relationship between the pre- to be prefetched, we chose to have Mozilla addi- vious and the next document, and static prefetch tionally recognize the link relation type \prefetch" directives can be encoded into the documents to in- to indicate a document that should be prefetched. dicate what should be prefetched next. In addition This link relation type currently is not standard- to static prefetch directives, a server might dynami- ized; however, the XHTML 2.0 draft specification cally inject prefetch directives into outbound HTTP [9] declares the \prefetch" link relation type. responses for the benefit of a link prefetching en- Examples of these two types of link prefetching abled browser. For example, the server may want HTML directives follows: to instruct the browser to prefetch the most popular URLs on a given day. Because this technique works <LINK rel="next" href="next.html"> with HTTP headers, a proxy can very well generate <LINK rel="prefetch" href="big.jpg"> such dynamically determined directives for popular Suppose next.html contains an <IMG> tag, which links. would cause big.jpg to be loaded. These tags What follows is a description of the link prefetching might be found in a document in which next.html mechanism along with a number of practical issues is likely to be the next document visited by the user. that shaped our design and implementation of link As a result of these tags, the browser would silently prefetching for the Mozilla browser, a popular Open prefetch the two documents while the user is per- Source web browser. We added our implementation haps busy reading through the current document. to version 1.2 and 1.0.2 of the Mozilla browser. It Link prefetching directives specified solely in the is also included in Netscape 7.01 and other recent body of a document have limited utility in solving Mozilla-based browsers. problems in which content to be prefetched might be 2 Prefetching Directives dynamically determined by the origin server or an intermediate proxy server. To support such config- The HTML 4.01 specification [7] briefly mentions urations, Mozilla additionally recognizes link pre- an opportunity for browsers to prefetch URLs indi- fetching directives specified via the Link HTTP cated by content authors via the <LINK> tag. The header. The Link HTTP header appears in sec- description of the \next" link relation type (from tion 19.6.2.4 of RFC 2068 [6]; however, the updated section 6.12 of [7]) says the following: version of the HTTP 1.1 standard, RFC 2616 [8] does not define it. Use of this header, for example to enable servers to apply style sheets to a group page, directs the browser to load something else. of documents, is described in section 14.6 of the However, this approach ignores the problem of mul- HTML 4.01 specification [7]. The link prefetching tiple applications on the user's system competing example from above could be equivalently written for network bandwidth. To minimize this problem as follows: the Mozilla browser prefetches documents sequen- Link: <next.html>; rel="next" tially, deferring the next prefetch until after the Link: <big.jpg>; rel="prefetch" former has completed. While this is not an ideal solution, it minimizes the problem by reducing the Note that as with many HTTP response head- prefetching application's demand on the operating ers, the Link header may also appear in a <META> system's networking subsystem. HTML tag via the http-equiv attribute. This is described in section 7.4.4 of the HTML 4.01 speci- Given that web pages are commonly composed fication [7]. of multiple HTML frames, the browser may see link prefetching directives from one or more of the We recommend the HTTP-level Link header mech- frames. Therefore, the Mozilla browser does not anism above the other mechanisms since it allows begin prefetching until all frames, and any in-line proxy servers to more easily intercept prefetch di- content they contain, have finished loading. This rectives and, for example, process them on behalf approximately corresponds to the time at which the of a browser that does not support link prefetch- DOM's onLoad event handler for the HTML <BODY> ing.
Load more

Recommended publications
  • GS1 Digital Link Standard (DRAFT) Enabling Consistent Representation of GS1 Identification Keys Within Web Addresses to Link to Online Information and Services
    GS1 Digital Link Standard (DRAFT) enabling consistent representation of GS1 identification keys within web addresses to link to online information and services Release [ToBe]1.1, Draft, 10 June 2019 IMPORTANT Disclaimer applicable to this Community Review public draft This document is a DRAFT, a work in progress and NOT the final GS1 standard. This document is for review only and it is provided "as is". GS1 does not make any representation or warranty, express or implied, including, but not limited to, warranties of merchantability, fitness for a particular purpose or use, non-infringement, or title; that the contents of the document are suitable for specific purposes; nor that the implementation of such contents will not infringe any third party patents, copyrights, trademarks or other rights. Furthermore, GS1 assumes no liability whatsoever for any inadvertent errors or omissions that may appear in the document. In no event shall GS1 be liable for any direct, indirect, special or consequential damages arising out of any use of the document or the performance or implementation of the contents thereof. Although the standard development process is in progress and governed by the GS1 Intellectual Property Policy, intellectual property right issues could occur any time. The document itself cannot infringe patent rights, but the implementation thereof could. Therefore, if you implement the draft standard contained in the document, you do so entirely at your own risk. Implementers and distributors of software products are encouraged to provide feedback, but should consult with their own attorneys, and form their own conclusions concerning the implementability and possible infringement of third-party rights.
    [Show full text]
  • Re-Architecting Web and Mobile Information Access for Emerging Regions
    Re-architecting Web and Mobile Information Access for Emerging Regions by Jay Chen A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy Department of Mathematics Courant Institute of Mathematical Sciences New York University September 2011 Professor Lakshminarayanan Subramanian c Jay Chen All Rights Reserved, 2011 Acknowledgments I would like to start by expressing my deepest gratitude to my advisor, Lakshminarayanan Sub- ramanian (or just “Lakshmi”). It was Lakshmi who set me on the path toward my eventual area of research. Lakshmi has always been generous with his time, and never short on ideas or en- thusiasm. Without Lakshmi’s courage to pursue the research that inspires him, I would not have found my own passion: to build systems that benefit people - as many people as much as possible by inventing ways to bring technology to people living outside of the privileged regions of the world. Contributors to this dissertation - This thesis is based on research that I performed over the past five years with many colleagues contributing directly to the work in this dissertation. Many people helped me along the way whose help I could not have done without. The RuralCafe user study would not have been possible without the help of Saleema Amershi and Aditya Dhananjay (Chapter 6.6). Our low bandwidth transport modeling and analysis (Chapter 3.1) was an effort largely attributable to Janardhan Iyengar and long discussions with Bryan Ford. Russell Power implemented the feature reduction algorithm for CIPs (Chapter 7.2.2) in his “spare time”. Our ELF deployments (Chapters 2.2 and 5.3) were only possible with help from David Hutchful.
    [Show full text]
  • Swarovsky: Optimizing Resource Loading for Mobile Web Browsing
    IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. XX, NO. XX, XXXX 201X 1 SWAROVsky: Optimizing Resource Loading for Mobile Web Browsing Xuanzhe Liu, Member, IEEE, Yun Ma, Xinyang Wang, Yunxin Liu Senior Member, IEEE, Tao Xie Senior Member, IEEE, and Gang Huang Senior Member, IEEE Abstract—Imperfect Web resource loading prevents mobile Web browsing from providing satisfactory user experience. In this article, we design and implement the SWAROVsky system to address three main issues of current inefficient Web resource loading: (1) on-demand and thus slow loading of sub-resources of webpages; (2) duplicated loading of resources with different URLs but the same content; and (3) redundant loading of the same resource due to improper cache configurations. SWAROVsky employs a dual-proxy architecture that comprises a remote cloud-side proxy and a local proxy on mobile devices. The remote proxy proactively loads webpages from their original Web servers and maintains a resource loading graph for every single webpage. Based on the graph, the remote proxy is capable of deciding which resources are “really” needed for the webpage and their loading orders, and thus can synchronize these needed resources with the local proxy of a client efficiently and timely. The local proxy also runs an intelligent and light-weight algorithm to identify resources with different URLs but the same content, and thus can avoid duplicated downloading of the same content via network. Our system can be used with existing Web browsers and Web servers, and does not break the normal semantics of a webpage. Evaluations with 50 websites show that on average our system can reduce the page load time by 43.1% and the network data transmission by 57.6%, while imposing marginal system overhead.
    [Show full text]
  • Scott Guthrie Keynote Speaker at NDC 2011 See Agenda at P.42-43
    For software developers and leaders NDC motivates Unit 4, Agresso see why at p.28 Scott Guthrie Keynote Speaker at NDC 2011 see Agenda at p.42-43 The Big Wall: Who needs How to Bring a Huge a service bus, Product Backlog anyway? Down to Size by Udi Dahan by Mitch Lacey ALSO FEATURING: IAN ROBINSON ANDERS NORÅS ROD PADDOCK GASPAR NAGY JONAS BANDI JEFF WILCOX GREG SHACKLES DOMINICK BAIER JON SKEET GILL CLEEREN GARY SHORT BILLY HOLLIS MARK SEEMANN SCOTT bellware NORWEGIAN DEVELOPERS CONFERENCE 2011 Oslo Spektrum, Oslo June 8 -10th Navn: Hege Lidenskap: Spreke løsningskonsepter Jobb: Senior Business Consultant Navn: Terje Lidenskap: SharePoint Jobb: Senior Software Engineer FOTO: BO MATHISEN Bli en del av vårt sterke fagmiljø innen samhandling og SharePoint Steria er blitt kåret til en av Norges beste arbeidsplasser fire år på rad. Det er ikke uten grunn. Mye skyldes de gode utviklingsmulighetene. Mye skyldes de utfordrende prosjektene. Mye skyldes det sterke og gode fagmiljøet. Velkommen til et av Europas største Vårt fagmiljø innen samhandling og informasjons- Spennende utfordringer it-konsulentselskaper håndtering er trolig et av Nord-Europas sterkeste. Vi er Steria er en kunnskapsbedrift. Vi lever av å gi gode Det har skjedd mye siden vi etablerte oss i 1969 i EMC Documentum partner og den eneste leverandøren råd om ledelse og it. Basert på våre sterke fagmiljøer Paris. Vi er nå et av Europas 10 største it-konsulent- som har godkjent Noark 5 kjerne for Documentum med bistår vi en rekke av Norges største virksomheter innen selskaper med 20 000 medarbeidere i 16 land og sakarkiv.
    [Show full text]
  • Html-Zh-Cn.Pdf
    HTML #html 1 1: HTML 2 2 2 Examples 2 2 2 2 3 3 2: Div 5 5 5 Examples 5 5 5 3: HTML 5 7 7 Examples 7 Html 5 7 4: HTML 8 Examples 8 HTML 8 8 5: SVG 9 9 9 Examples 9 HTMLSVG 9 9 object 9 SVG 9 CSSSVG 10 6: TABINDEX 11 11 11 Examples 11 Tab 11 Tab 11 Tab 11 7: HTMLCSS 12 12 12 Examples 12 12 12 13 13 8: 14 14 14 14 Examples 14 14 14 14 15 application-name 15 author 15 description 15 generator 15 keywords 15 16 16 16 Facebook / Open Graph 16 Facebook / 17 17 Google+ / Schema.org 17 17 18 9: 19 19 19 Examples 19 19 10: 21 21 21 21 Examples 21 21 21 21 21 22 11: 23 23 Examples 23 23 23 24 25 25 25 25 26 26 26 27 12: 28 28 28 Examples 28 =“” 28 = “alertdialog” 29 =“” 29 =“” 29 =“” 29 =“” 30 =“” 30 =“” 30 = “columnHeader” 30 =“” 31 =“” 31 = “contentinfo” 31 =“” 31 =“” 31 =“” 32 =“” 32 =“” 32 =“” 32 =“” 33 =“” 33 =“” 33 = “IMG” 33 =“” 34 =“” 34 =“” 34 =“” 34 =“” 34 =“” 35 =“” 35 =“” 35 =“” 35 =“” 35 =“” 36 = “menuitemcheckbox” 36 = “menuitemradio” 36 =“” 36 =“” 36 =“” 36 =“” 37 =“” 37 =“” 37 =“” 37 = “RadioGroup” 37 =“” 38 = “rowgroup” 38 = “rowHeader” 38 =“” 38 =“” 39 =“” 39 =“” 39 =“” 39 =“” 40 =“” 40 =“” 40 =“” 40 =“” 40 =“” 41 = “tabpanel” 41 =“” 41 =“” 41 =“” 41 =“” 42 =“” 42 = “TreeGrid” 42 = “treeitem” 42 13: 44 44 44 44 Examples 44 44 44 44 14: 46 46 46 Examples 46 46 46 47 47 srcset 48 srcset 48 srcset 48 48 15: HTMLJavaScript 50 50 50 50 Examples 50 JavaScript 50 JavaScript 50 JavaScript 50 Javascript 50 16: 52 52 52 52 Examples 53 ` `` `/ 53 53 53 53 17: 55 Examples 55 55 HTML5 55 18: 56 56 Examples 56 56 MIME 56 19: 57 57 57 Examples
    [Show full text]
  • GS1 Digital Link: Resolution
    GS1 Digital Link: Resolution Resolving GS1 Digital Link URIs to one or more sources of related informationenabling consistent representation of GS1 identification keys within web addresses to link to online information and services To Be 1.2, Draft 0.6, 22 October 2020 GS1 Digital Link Standard Document Summary Document Item Current Value Document Name GS1 Digital Link: resolution Document Date 22 October 2020 Document Version To be 1.2 Document Issue Document Status Draft Document Description enabling consistent representation of GS1 identification keys within web addresses to link to online information and services Contributors (to be updated by Greg) Log of Changes Release Date of Change Changed By Summary of Change 0.1 2020-04-20 Phil Archer, Mark Harrison Preparation for work on version 1.2 (by editing version 1.1). Known specific issues are highlighted where relevant in the text. 0.2 2020-05-14 Phil Archer, Ralph Tröger Additional issues from RT: https for canonical URIs, identification of split in GRAIs; place holders for expected work on binary EPC/RFID 0.3 2020-08-07 Phil Archer Split from original all in one standard. Signifiant changes to matching of link attributes to requests 0.4 2020-10-02 Dom Guinard, Phil Archer Responding to Dom’s comments and MSWG meeting 2020-10-01 0.5 2020-10-14 Phil Archer Further responses to comments received from Dom and Frits van den Bos, tidying up of refs and glossary, introductory material added with links to other DL standards. 0.6 2020-10-22 Phil Archer Removed schema.org as a namespace that SHOULD be supported Disclaimer GS1®, under its IP Policy, seeks to avoid uncertainty regarding intellectual property claims by requiring the participants in the Work Group that developed this GS1 Digital Link: Resolution standard version 1.2 to agree to grant to GS1 members a royalty-free licence or a RAND licence to Necessary Claims, as that term is defined in the GS1 IP Policy.
    [Show full text]
  • Wiley.Smashing.HTML5.Feb.2011.Pdf
    01_977279-ffirs.indd i 10/28/10 9:54 PM SMASHING HTML5 01_977279-ffirs.indd i 10/28/10 9:54 PM PUBLISHER’S ACKNOWLEDGMENTS Some of the people who helped bring this book to market include the following: Editorial and Production VP Consumer and Technology Publishing Director: Michelle Leete Associate Director–Book Content Management: Martin Tribe Associate Publisher: Chris Webb Publishing Assistant: Ellie Scott Development Editor: Elizabeth Kuball Copy Editor: Elizabeth Kuball Technical Editor: Harvey Chute Editorial Manager: Jodi Jensen Senior Project Editor: Sara Shlaer Editorial Assistant: Leslie Saxman Marketing Senior Marketing Manager: Louise Breinholt Marketing Executive: Kate Parrett Composition Services Compositor: Wiley Composition Services Proofreader: Susan Hobbs Indexer: Potomac Indexing, LLC 01_977279-ffirs.indd ii 10/28/10 9:54 PM SMASHING HTML5 Bill Sanders wnload from Wow! eBook <www.wowebook.com> o D A John Wiley and Sons, Ltd, Publication 01_977279-ffirs.indd iii 10/28/10 9:54 PM Th is edition fi rst published 2011 © 2011 William B. Sanders. Registered offi ce John Wiley & Sons Ltd, Th e Atrium, Southern Gate, Chichester, West Sussex, PO19 8SQ, United Kingdom For details of our global editorial offi ces, for customer services and for information about how to apply for permission to reuse the copyright material in this book please see our website at www.wiley.com. Th e right of the author to be identifi ed as the author of this work has been asserted in accordance with the Copyright, Designs and Patents Act 1988. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopy- ing, recording or otherwise, except as permitted by the UK Copyright, Designs and Patents Act 1988, without the prior permission of the publisher.
    [Show full text]
  • Achieving Linked Enterprise Data with Restful Services and Link Relations W3C Workshop on Linked Enterprise Data
    Achieving Linked Enterprise Data with RESTful Services and Link Relations W3C Workshop on Linked Enterprise Data Cornelia Davis EMC [email protected] 25 October 2011 While the proponents of the Linked Data movement prescribe the use of RDF, RDF Schema, OWL and SPARQL, with the “5-star model”, even the staunchest supporters acknowledge that there are other ways to achieve at least some level of data linking. In the general sense, Linked Data means that data entities are connected to one another in a manner that can be “understood” by programmatic clients. While the body of Linked Open Data has grown respectably, adoption of this paradigm in the enterprise has been slow. The transition of web services interfaces from an RPC/SOAP-based style to a RESTful style, a phenomenon that is happening in most enterprises today, is an excellent opportunity to begin making enterprise data available as linked data, even without requiring corporate buy-in on the full “Semantic Web.” RESTful Services The uptake of RESTful services out on the web1 and the popularization of cloud computing has helped drive enterprises to develop RESTful interfaces to their products. In general, however, true understanding of the principles of REST remains weak and poses a risk to the potential for linked data that RESTful interfaces offer. All four of the primary REST principles are critical to the cause: • Identification and addressability of resources: All interesting bits of information are identified with URIs and those URIs are generally URLs. • Uniform interface: Interaction with resources is through a standardized set of operations, with well understood semantics (usually HTTP).
    [Show full text]
  • XEP-0240: Auto-Discovery of Jabberids
    XEP-0240: Auto-Discovery of JabberIDs Peter Saint-Andre Ralph Meijer mailto:xsf@stpeter:im mailto:ralphm@ik:nu xmpp:peter@jabber:org xmpp:ralphm@ik:nu http://stpeter:im/ 2008-04-30 Version 0.1 Status Type Short Name Deferred Standards Track NOT_YET_ASSIGNED This specification defines a recommended best practice for linking to JabberIDs from documents hosted on the World Wide Web. Legal Copyright This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the ”Specification”), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specifi- cation, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or sub- stantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or pub- lisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. Warranty ## NOTE WELL: This Specification is provided on an ”AS IS” BASIS, WITHOUT WARRANTIES OR CONDI- TIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
    [Show full text]
  • Master Thesis
    ABSTRACT Speeding Up Mobile Browsers without Infrastructure Support by Zhen Wang Mobile browsers are known to be slow. We characterize the performance of mobile browsers and find out that resource loading is the bottleneck. Leveraging an unprecedent- ed set of web usage data collected from 24 iPhone users continuously over one year, we examine the three fundamental, orthogonal approaches to improve resource loading with- out infrastructure support: caching, prefetching, and speculative loading, which is first proposed and studied in this work. Speculative loading predicts and speculatively loads the subresources needed to open a webpage once its URL is given. We show that while caching and prefetching are highly limited for mobile browsing, speculative loading can be significantly more effective. Empirically, we show that client-only solutions can im- prove the browser speed by 1.4 seconds on average. We also report the design, realiza- tion, and evaluation of speculative loading in a WebKit-based browser called Tempo. On average, Tempo can reduce browser delay by 1 second (~20%). Acknowledgements I would like to thank my advisor, Professor Lin Zhong, for his guidance and encour- agement during my study and research at Rice University. He has not only given me in- sightful suggestions, but also helped me to develop the right way to do research. I am also grateful to work with Mansoor Chishtie from Texas Instruments, who sup- ports my research and gives me inspiring advice. I would like to thank Professor Dan Wallach and Professor T. S. Eugene Ng for serv- ing as my thesis committee. Their comments and feedback to this work are of great value.
    [Show full text]
  • Visual Quickstart Guide: CSS3
    ptg999 From the Library of Sue Brandreth VISUAL QUICKSTART GUIDE CSS3 SIXTH EDITION JASON CRANFORD TEAGUE ptg999 Peachpit Press From the Library of Sue Brandreth Visual QuickStart Guide CSS3 Sixth Edition Jason Cranford Teague Peachpit Press www.peachpit.com Find us on the Web at www.peachpit.com To report errors, please send a note to [email protected] Peachpit Press is a division of Pearson Education Copyright © 2013 by Jason Cranford Teague Project Editor: Nancy Peterson Development Editor: Bob Lindstrom Copyeditors: Liz Merfeld and Darren Meiss Production Editor: Katerina Malone Compositor: David Van Ness Indexer: Jack Lewis Cover Design: RHDG / Riezebos Holzbaur Design Group, Peachpit Press Interior Design: Peachpit Press Logo Design: MINE™ www.minesf.com Notice of Rights All rights reserved. No part of this book may be reproduced or transmitted in any form by any means—electronic, ptg999 mechanical, photocopying, recording, or otherwise—without the prior written permission of the publisher. For information on obtaining permission for reprints and excerpts, contact [email protected]. Notice of Liability The information in this book is distributed on an “As Is” basis, without warranty. While every precaution has been taken in preparation of this book, neither the author nor Peachpit shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the computer software and hardware products described in it. Trademarks Visual QuickStart Guide is a registered trademark of Peachpit Press, a division of Pearson Education. Other trademarks are the property of their respective owners.
    [Show full text]
  • Critical CSS Rules Decreasing Time to first Render by Inlining CSS Rules for Over-The-Fold Elements
    Critical CSS Rules Decreasing time to first render by inlining CSS rules for over-the-fold elements Gorjan Jovanovski [email protected] July, 2016, 41 pages Supervisor: Dr. Vadim Zaytsev Host organisation: The Next Web, http://thenextweb.com Universiteit van Amsterdam Faculteit der Natuurwetenschappen, Wiskunde en Informatica Master Software Engineering http://www.software-engineering-amsterdam.nl Contents Abstract 3 1 Introduction 4 1.1 Problem statement...................................... 4 1.2 Research questions...................................... 5 1.3 Use cases ........................................... 5 1.3.1 Caching........................................ 6 1.3.2 Content Delivery Networks ............................. 6 1.3.3 Resolution mismatch................................. 6 1.4 Solution outline........................................ 6 2 Background 8 2.1 Cascading Style Sheets.................................... 8 2.1.1 Media queries..................................... 8 2.2 Web page rendering ..................................... 9 2.2.1 Time to first render ................................. 9 2.3 Critical path CSS....................................... 10 3 Related work 12 3.1 Academical Research..................................... 12 3.2 CSS prefetch and preload .................................. 12 3.2.1 Prefetch........................................ 12 3.2.2 Preload ........................................ 12 3.3 Content first ......................................... 13 3.4 Manual extraction .....................................
    [Show full text]