{
    "version" : "https://jsonfeed.org/version/1",
    "content" : "news",
    "type" : "single",
    "title" : "DigitalGov Search: Cache Me If You Can |Digital.gov",
    "description": "DigitalGov Search: Cache Me If You Can",
    "home_page_url" : "/preview/gsa/digitalgov.gov/snyk-fix-08ac0319715b31f28b1a7897cd249f39/","feed_url" : "/preview/gsa/digitalgov.gov/snyk-fix-08ac0319715b31f28b1a7897cd249f39/2014/03/03/cache-me-if-you-can/index.json","item" : [
    {"title" :"DigitalGov Search: Cache Me If You Can","summary" : "Slowness Hurts Web Pages Have you ever been frustrated when visiting a Web page that doesn’t load quickly? Have you ever left a slow Web page before it finished loading? You’re not alone. Several recent studies have quantified customers’ frustration with slow Web pages. Customers now expect results in the","date" : "2014-03-03T08:47:36-04:00","date_modified" : "2024-07-10T08:44:18-04:00","authors" : {"ammie-farraj-feijoo" : "Ammie Farraj Feijoo"},"topics" : {
        
            "content-strategy" : "Content Strategy",
            "customer-experience" : "Customer experience",
            "search" : "Search",
            "software-engineering" : "Software Engineering"
            },"branch" : "snyk-fix-08ac0319715b31f28b1a7897cd249f39",
      "filename" :"2014-03-03-cache-me-if-you-can.md",
      
      "filepath" :"news/2014/03/2014-03-03-cache-me-if-you-can.md",
      "filepathURL" :"https://github.com/GSA/digitalgov.gov/blob/snyk-fix-08ac0319715b31f28b1a7897cd249f39/content/news/2014/03/2014-03-03-cache-me-if-you-can.md",
      "editpathURL" :"https://github.com/GSA/digitalgov.gov/edit/snyk-fix-08ac0319715b31f28b1a7897cd249f39/content/news/2014/03/2014-03-03-cache-me-if-you-can.md","slug" : "cache-me-if-you-can","url" : "/preview/gsa/digitalgov.gov/snyk-fix-08ac0319715b31f28b1a7897cd249f39/2014/03/03/cache-me-if-you-can/","content" :"\u003ch2 id=\"slowness-hurts-web-pageshahahugoshortcode1899s0hbhbhttpss3amazonawscomdigitalgov_legacy-img201403speed-dialpng\"\u003eSlowness Hurts Web Pages\u003ca href=\"https://s3.amazonaws.com/digitalgov/_legacy-img/2014/03/speed-dial.png\"\u003e\u003cdiv class=\"image\"\u003e\n  \u003cimg\n    src=\"https://s3.amazonaws.com/digitalgov/_legacy-img/2014/03/speed-dial.png\"\n    alt=\"speed dial\"/\u003e\u003c/div\u003e\n\n\u003c/a\u003e\u003c/h2\u003e\n\u003cp\u003eHave you ever been frustrated when visiting a Web page that doesn’t load quickly? Have you ever left a slow Web page before it finished loading? You’re not alone.\u003c/p\u003e\n\u003cp\u003eSeveral recent studies have quantified customers’ frustration with slow Web pages. Customers now \u003ca href=\"http://www.nytimes.com/2012/03/01/technology/impatient-web-users-flee-slow-loading-sites.html?_r=0\"\u003eexpect results in the blink of an eye\u003c/a\u003e. This expectation means that your \u003ca href=\"http://www.aberdeen.com/Aberdeen-Library/5136/RA-performance-web-application.aspx\"\u003ecustomers are won or lost in one second\u003c/a\u003e. A one second delay in loading a Web page equals 11% fewer page views, 16% decrease in customer satisfaction, and 7% loss in conversions.\u003c/p\u003e\n\u003ch2 id=\"slowness-kills-search-results-pages\"\u003eSlowness Kills Search Results Pages\u003c/h2\u003e\n\u003cp\u003eAs little time as websites have to keep users on their pages, search engines have even less time to keep searchers on their results pages. Speed is the primary factor in determining customers’ satisfaction with search results.\u003c/p\u003e\n\u003cp\u003eGoogle, Microsoft, and Yahoo garner \u003ca href=\"http://www.comscore.com/Insights/Press_Releases/2013/11/comScore_Releases_October_2013_US_Search_Engine_Rankings\"\u003e95% of the search market\u003c/a\u003e. Google garners two-thirds of the search market. The company’s \u003ca href=\"https://www.google.com/search?q=Google+Gospel+of+Speed\"\u003eGospel of Speed\u003c/a\u003e motto is one reason why Google garners the majority of the market.\u003c/p\u003e\n\u003cp\u003eThis gospel has also set a high bar for all search engines. Searchers expect results pages to load very, very quickly.\u003c/p\u003e\n\u003ch2 id=\"how-we8217ve-made-our-result-pages-load-faster\"\u003eHow We’ve Made Our Result Pages Load Faster\u003c/h2\u003e\n\u003cp\u003eSo, when we established the service’s open source architecture in 2010, the first thing we tackled was how to deliver our search results in under one second.\u003c/p\u003e\n\u003cp\u003eAt around the same time, \u003ca href=\"https://github.com/\"\u003eGithub\u003c/a\u003e was experiencing exponential growth and the company’s engineers were blogging about what they did to make Github fast. To get up to speed quickly (yes, bad pun intended), we read their posts.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/blog/530-how-we-made-github-fast\"\u003eHow We Made GitHub Fast\u003c/a\u003e, October 20, 2009\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://github.com/blog/1252-how-we-keep-github-fast\"\u003eHow We Keep GitHub Fast\u003c/a\u003e, September 5, 2012\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eLeveraging some of Github’s best practices, we succeeded in delivering our results in under 700 milliseconds, on average. This was a significant accomplishment and improvement from the previous vendor-owned and -operated iterations of our service.\u003c/p\u003e\n\u003cp\u003eOver the past three years, we’ve dug in and improved our response time even more. We now deliver our results in under 380 milliseconds, on average.\u003c/p\u003e\n\u003cdiv class=\"image\"\u003e\n  \u003cimg\n    src=\"https://s3.amazonaws.com/digitalgov/_legacy-img/2014/03/serp%5c_reponse%5c_times_600x195.png\"\n    alt=\"Graph of app response times\"/\u003e\u003c/div\u003e\n\n\n\u003cp\u003eWe already had an architecture optimized for speed. So, how have we sped it up by 320 milliseconds?\u003c/p\u003e\n\u003ch2 id=\"we-cache-when-we-can\"\u003eWe Cache When We Can\u003c/h2\u003e\n\u003cp\u003eWhen a searcher enters a query, we go out to our various indexes, pull the information relevant to the searcher’s request, and put that information together on the results page.\u003c/p\u003e\n\u003cp\u003eMost queries (such as jobs, obama, unclaimed money, forms) aren’t unique and are asked by thousands of searchers each day.\u003c/p\u003e\n\u003cp\u003eWe cache these so-called short head queries and store them on our servers. Caching helps us speed up the above process because searchers don’t have to wait for us to pull the information from its original source.\u003c/p\u003e\n\u003ch2 id=\"we-use-an-asset-pipeline\"\u003eWe Use an Asset Pipeline\u003c/h2\u003e\n\u003cp\u003eWe have many JavaScript and CSS files on our results pages. These “assets” can be large and slow down the loading of our page. So, we use an \u003ca href=\"http://guides.rubyonrails.org/asset_pipeline.html\"\u003easset pipeline\u003c/a\u003e to concatenate and compress our JavaScript and CSS assets thereby reducing the number of requests that a browser has to make to render our results page.\u003c/p\u003e\n\u003cp\u003eWe also use fingerprinting—a technique that makes a file’s name dependent on its content—within our asset pipeline. When the content changes, the name changes. For content that is static or that changes infrequently, this naming helps us tell whether two versions of a file are identical. When a filename is unique, browsers keep their own copy of the content. When the content is updated, the fingerprint changes so browsers request a new copy of the content. This approach allows us to maximize our content delivery network.\u003c/p\u003e\n\u003ch2 id=\"we-use-a-content-delivery-network\"\u003eWe Use a Content Delivery Network\u003c/h2\u003e\n\u003cp\u003eOur static content (such as scripts and stylesheets) gets served through our \u003ca href=\"http://www.webopedia.com/TERM/C/CDN.html\"\u003econtent delivery network\u003c/a\u003e provider, currently Akamai. Akamai serves our static content from its server that is geographically closest to the searcher. The closer, the faster.\u003c/p\u003e\n\u003cp\u003eUsing a content delivery network also allow us to optimize our service’s speed by:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eDirecting non-cached traffic between our two data centers to create a multihomed environment. Multihoming allows us to make full use of all of our servers. By contrast, in 2010, our disaster recovery data center often sat idle.\u003c/li\u003e\n\u003cli\u003eReducing our need to add bandwidth or servers to handle short-term traffic spurts, such as spurts related to natural disasters.\u003c/li\u003e\n\u003cli\u003eProtecting against denial of service attacks by spotting them before they reach our servers.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"what8217s-next\"\u003eWhat’s Next?\u003c/h2\u003e\n\u003cp\u003eWe’ve worked hard over the past three years to speed up the delivery of our results by optimizing each link in the chain.\u003c/p\u003e\n\u003cp\u003eWe use several monitoring tools to measure our system’s performance. The quality of these tools is improving at a rapid pace, which in turn, shows us where and how we can improve our service.\u003c/p\u003e\n\u003cp\u003eWe regularly ask ourselves, “Will this shave some time off and help us deliver our results in under 380 milliseconds?”\u003c/p\u003e\n\u003cp\u003eNot yet a \u003ca href=\"/preview/gsa/digitalgov.gov/snyk-fix-08ac0319715b31f28b1a7897cd249f39/services/search/\"\u003eDigitalGov Search\u003c/a\u003e customer? \u003ca href=\"https://search.usa.gov/signup\"\u003eSign up\u003c/a\u003e and get started!\u003c/p\u003e\n"}
  ]
}