# Forum > Technical > Board/Site Issues >  seeing new comic on the index requires both loading the page and then reloading it

## arimareiji

Reported a while ago, still true: At least on Firefox, navigating _de novo_ to https://www.giantitp.com/comics/oots.html doesn't display a new comic until after you click reload. The page used to work normally, but no longer does.

For example, if you wanted to check if 1271 has dropped and click on a bookmark to go from some other website to the index... even if 1271 is now up, the index would still only display through 1270 until you click reload. (Once you've done so, it displays normally thereafter.)

----------


## Algeh

I am having a similar issue in that the list of comics on the site's main page ( https://www.giantitp.com/ ) does not currently show 1271, and still shows 1270 as the most recent comic. The list is correct on the forums main page ( https://forums.giantitp.com/ ).

I'm guessing that either the site is telling browsers to cache things for a long enough time that checking on the site for new comics doesn't work without a refresh or waiting at least a day, or Firefox is doing some attempt at the same on the browser side.

----------


## arimareiji

> I am having a similar issue in that the list of comics on the site's main page ( https://www.giantitp.com/ ) does not currently show 1271, and still shows 1270 as the most recent comic. The list is correct on the forums main page ( https://forums.giantitp.com/ ).
> 
> I'm guessing that either the site is telling browsers to cache things for a long enough time that checking on the site for new comics doesn't work without a refresh or waiting at least a day, or Firefox is doing some attempt at the same on the browser side.


Thank you. (^_^)b

I noticed that the sidebar on the left (I'm guessing that's what you're referring to on the main page) does the same thing on the index page, but didn't think to mention it as a distinct phenomenon.

----------


## Algeh

> Thank you. (^_^)b
> 
> I noticed that the sidebar on the left (I'm guessing that's what you're referring to on the main page) does the same thing on the index page, but didn't think to mention it as a distinct phenomenon.


You're welcome. It's nice to know that other people are experiencing the same issues I am, so it isn't likely to be a result of something I specifically broke on my end. (Although we are both running Firefox, so it's possible that this is somehow browser weirdness.)

You are correct, I was referring to the site navigation sidebar. It takes either about a day or an intentional refresh for a new comic to appear in the sidebar on the main site page, and based on your experience with the index page for actual comics, I suspect this to be true of all parts of the main site (as distinct from the forum).

This smells strongly like something to do with caching. 

As someone who is not involved in maintaining this particular site, I suppose my end-user takeaway is to load the forum each morning and look at the sidebar to check for new comics instead of loading the main site even if I don't have time for a bunch of forum posting. That's not really a great pattern for everyone to switch to from both a site load perspective and a centering people's experience with the GiTP "brand" around the comic and/or other things under Ric's direct authorship and control perspective (assuming that is a goal held by the site currently - completely not a thing where my opinion is the important one), but it's the solution that makes sense on an individual level right now.

----------


## arimareiji

> You're welcome. It's nice to know that other people are experiencing the same issues I am, so it isn't likely to be a result of something I specifically broke on my end. (Although we are both running Firefox, so it's possible that this is somehow browser weirdness.)*Spoiler: collapse for space*
> Show
> 
> 
> 
> You are correct, I was referring to the site navigation sidebar. It takes either about a day or an intentional refresh for a new comic to appear in the sidebar on the main site page, and based on your experience with the index page for actual comics, I suspect this to be true of all parts of the main site (as distinct from the forum).
> 
> This smells strongly like something to do with caching. 
> 
> As someone who is not involved in maintaining this particular site, I suppose my end-user takeaway is to load the forum each morning and look at the sidebar to check for new comics instead of loading the main site even if I don't have time for a bunch of forum posting. That's not really a great pattern for everyone to switch to from both a site load perspective and a centering people's experience with the GiTP "brand" around the comic and/or other things under Ric's direct authorship and control perspective (assuming that is a goal held by the site currently - completely not a thing where my opinion is the important one), but it's the solution that makes sense on an individual level right now.


It's not a perfect answer, but the first link below from another thread appears to be a workaround. (Although to my mind, it begs the question of "Most webcomics' splash page is the latest comic, so why is there not only no splash page - but also the logo hotlinks to the index in various places around the site, instead of to .../ootslatest.html?")



> Use: https://www.giantitp.com/comics/ootslatest.html
> Or subscribe to the RSS: https://www.giantitp.com/comics/oots.rss
> Or follow the twitter: https://twitter.com/RichBurlew

----------


## Chronos

/ootslatest.html also doesn't always update right away, though I haven't figured out the pattern in when it does and doesn't update.

----------


## KillianHawkeye

I don't understand the complaint. If you want to check for new content, refreshing a page is totally normal. What's the problem? Pages don't refresh themselves!  :Small Confused:

----------


## Grey_Wolf_c

> I don't understand the complaint. If you want to check for new content, refreshing a page is totally normal. What's the problem? Pages don't refresh themselves!


The complaint is that I get a notification that there is a new comic (say, in my case, from Patreon), and yet when I use my bookmark for /oootlatest I get the previous comic. And I look on the sidebar, and the listing stops equally at the latest comic. I have to refresh the page I just loaded a second time (which sometimes works, but sometimes - such as for 1272 - it's not enough & I have to shift-refresh a third time) to get the new entry & link to pop up so I can read the comic.

Yes, I'll grant you it is hardly an existential crisis to have to refresh a few times to get a comic, but it is also not how webpages are supposed to work - you expect the latest version of the page to be served when you request it, not the version from the night before.

GW

----------


## Rawhide

> ootslatest


https://www.giantitp.com/comics/ootslatest.html uses the following code:



```
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />
```


If you're not getting the latest comic when you visit that page, then your browser is doing something it shouldn't.

----------


## arimareiji

> You're welcome. It's nice to know that other people are experiencing the same issues I am, so it isn't likely to be a result of something I specifically broke on my end. (Although we are both running Firefox, so it's possible that this is somehow browser weirdness.)
> 
> You are correct, I was referring to the site navigation sidebar. It takes either about a day or an intentional refresh for a new comic to appear in the sidebar on the main site page, and based on your experience with the index page for actual comics, I suspect this to be true of all parts of the main site (as distinct from the forum).
> 
> This smells strongly like something to do with caching. 
> 
> As someone who is not involved in maintaining this particular site, I suppose my end-user takeaway is to load the forum each morning and look at the sidebar to check for new comics instead of loading the main site even if I don't have time for a bunch of forum posting. That's not really a great pattern for everyone to switch to from both a site load perspective and a centering people's experience with the GiTP "brand" around the comic and/or other things under Ric's direct authorship and control perspective (assuming that is a goal held by the site currently - completely not a thing where my opinion is the important one), but it's the solution that makes sense on an individual level right now.


Possibly interesting, if you're as easily entertained as me: When Rawhide responded to Grey_Wolf_c, it got me curious enough to start peeking around in the source code. At least to my ill-informed eye, it looks like the OOTS index page and main forum index have no Cache-Control parameters, the way ootslatest.html does.
(Not that that's necessarily probative, given that people are reporting comparable issues with the Latest page as well. Maybe I'll find out with the next new comic that it happens on Latest as well, if it's within a certain time frame of the comic going up.) 


```
view-source:https://www.giantitp.com/comics/ootslatest.html

view-source:https://forums.giantitp.com/

view-source:https://www.giantitp.com/comics/oots.html

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
```




> no-cache
> 
> The no-cache response directive indicates that the response can be stored in caches, but the response must be validated with the origin server before each reuse, even when the cache is disconnected from the origin server.
> 
> Cache-Control: no-cache
> 
> If you want caches to always check for content updates while reusing stored content, no-cache is the directive to use. It does this by requiring caches to revalidate each request with the origin server.
> 
> Note that no-cache does not mean "don't cache". no-cache allows caches to store a response but requires them to revalidate it before reuse. If the sense of "don't cache" that you want is actually "don't store", then no-store is the directive to use.

----------

