Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It sounds strange to me that iPhone caches the pages locally and that you have to clean up the cache to get fresh content.</p> <p>In fact there must be some HTTP cache headers which tell iPhone browser to do that. It should not matter if the browser is Safari on iOS, or opera on Android, or Firefox on a windows, because all modern browser "should" conform to the <a href="http://www.w3.org/Protocols/rfc2616/rfc2616.html" rel="nofollow">HTTP 1.1 RFC</a>, even the mobile ones. Surely they might have some differences to save bandwidth, phone battery and phone cpu cycles, but definitely they should allow users to get fresh content from a website. So I agree with you, cleaning the visited pages is not the right way of doing things. I definitely think that there is a problem somewhere. Try to call the API via a computer browser and inspect the requests via firebug, or the native debugging tool of chrome, to check the server response headers, and to see if the behavior is the same.</p> <p>Normally I use a mix of max-age and if-modified-since cache validators. I set the max-age of some of the images to an high value (in my case 365 days, most probably not suitable for you), for some others to a week, and a day of css and javascript. Additionally I use the if-modified-since so I have a good balance between freshness of the content, server load and bandwidth usage. The ETAG is basically the same thing as if-modified-since, with the difference you can set it to a weak cache validator, and it is really useful if the clock of the server is not reliable. (see below on the extended answer for more info and references to docs)</p> <p>To enable the cache, IIS7 makes it really easy for you with the output caching IIS module. <a href="http://learn.iis.net/page.aspx/710/configure-iis-7-output-caching/" rel="nofollow">Here is</a> a good doc about it, on how to enable it, and the difference between kernel and user mode cache.</p> <p>Unless you will need to do really particular stuff, I think you will not need to create code for it, and IIS will take care of everything. If that's not the case, then here is <a href="http://learn.iis.net/page.aspx/154/walkthrough-iis-output-caching" rel="nofollow">another good guide</a> which will help you out.</p> <p>If you really want a fast website then I would recommend you to enable compression, and to add a cache layer between the application and the database. So you will not execute queries to the DB on every requests.</p> <p>Here are <a href="http://developer.yahoo.com/performance/rules.html" rel="nofollow">some more good performance guidelines</a> for any web developer.</p> <p><strong>Extended Answer (maybe even too extended :) )</strong></p> <p>There are different ways of caching the content on the client side via HTTP 1.1. The most commons, or at least the ones I used the most are:</p> <ol> <li>max-age</li> <li>last-modified</li> <li>etag</li> </ol> <p>1) The max-age header is sent from the server, on the HTTP response headers, and basically tells the client's browser to store the content on its cache, for a period of time specified in seconds.</p> <p>For instance, let's assume a server gives back a max-age=60 in response to a GET client http request of logo.jpg. The client's browser then stores the logo.jpg and for the next 60 seconds it will serve the image from its own cache. In other words there will be no HTTP requests for this specific image for the next 60 seconds. So with the max age the content is cached on the client side, and will not be requested or revalidated with the server for the amount of seconds specified in the max-age header. There is however normally the possibility to force this revalidation/refresh by pressing CTRL-F5 on windows browser and CMD-R on mac browsers. On the mobile devices, normally the functionality is on the browser menu, and it is called refresh. This is the <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4" rel="nofollow">appropriate section</a> of the RFC.</p> <p><strong>PROS</strong></p> <ul> <li>there are no TCP connections, and HTTP requests to the server, therefore less workload on the server side (really useful if your app has a lot of users)</li> <li>the content is loaded locally, directly from the browser cache, therefore no latency on content loading</li> <li>no bandwidth usage (useful if the data center charges you for inbound and outbound bandwidth)</li> </ul> <p><strong>CONS</strong></p> <ul> <li>if you have fresh content on the server, then the client will not be aware of 'till the cache on the client side expires, or the user force a browser refresh.</li> </ul> <hr> <p>2) The last-modified server side http response header together with the client side http request header if-modified-since, is another good mechanism for speeding up the sites and to save some money. It basically works in this way. </p> <p>A browser requests content for the first time to a server via a GET request. The server responds with a 200 and gives back the content together with a last-modified header. The last-modified header's value is nothing else than the actual date and time when the content has been modified last time. (date time must be in UTC because of the timezones) At this point all the following HTTP requests for the same content coming from the client will have an additional header called: if-modified-since with the date and time received from the server as value. The server when receives the following requests will check the if-modified-since header value and it will compare it with the last-modified date of the content. If the data is the same, and therefore the content has not changed, the server will respond with a 304 and basically with no content. (most important part !) The browser then knows it has to keep still the content on the cache and load it from it because it has not changed on the server side. The process will continue till the content on the server changed and therefore the server will provide a new last-modified date and fresh content. This as you can see, can save a lot of bandwidth, especially in the case of images, or JS or css, without giving up content freshness. <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.25" rel="nofollow">Section 14.25 of the spec</a> explains things much better than I did. :)</p> <p><strong>PROS</strong></p> <ul> <li>Less bandwidth involved in the whole process, cause if the content has not changed then the server responds just with a 304.</li> <li>Revalidation of the content from the client side, so the client will always have the last fresh data</li> </ul> <p><strong>CONS</strong></p> <ul> <li>the server has to handle the TCP connections and the HTTP requests, and check the last modified date and time of the file/content the client request.</li> </ul> <hr> <p>3) The ETAG is a similar process like the if-modified-since, with a difference that the value of the header is normally an hash of the server side content, and the client on the http requests sends an header called: if-none-match.</p> <p>The pros and cons are the same as the point 2.</p> <p>You might now wonder than what is the main difference between point 2 and point 3. The problem with point 2 is actually the server clock. In fact there could be problems serving back the last-modified date from the server if it has clock problems</p> <hr> <p>The subject is quite deeper, cause the best practice is to send a weak and a strong validator. See <a href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.4" rel="nofollow">section 13.3.4</a> for more information.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload