Browser caching for JSON-LD-Code (schema) in htaccess

What is a proper caching period for JSON-LD? “access plus 0 seconds”?

[deeper]

Hi,
Google recommends JSON-LD for structured data. As comprehensive schema code worsens page speed I want to both compress and cache it in my htaccess.

Searching the web for browser caching via htaccess I always find the following line for JSON-LD:

ExpiresByType application/ld+json     “access plus 0 seconds” 

This actually disables browser caching at all!? This may make sense for continously changing data, but JSON-LD-code for structured data? Why not choosing “access plus 1 month” for example?

Usually you create your structured data for a certain page, insert it and it won't be changed unless the page itsself changes remarkably.
So why do "all" webmasters disable browser caching for structured data with JSON-LD completely?

deeper

[phranque]

ExpiresByType application/ld+json  “access plus 0 seconds” 

This actually disables browser caching at all!? This may make sense for continously changing data, but JSON-LD-code for structured data? Why not choosing “access plus 1 month” for example?

Usually you create your structured data for a certain page, insert it and it won't be changed unless the page itsself changes remarkably.

if the JSON-LD snippet is inserted in your page, it will be compressed and cached if and as the containing document is compressed/cached, so this ExpiresByType directive would be irrelevant.

on the other hand, if your JSON-LD exists in an external script, you should compress and cache it as you would any other relatively static javascript resource.
30 days is a reasonable number for cacheing static resources, so you should specify that rather than no cache at all.

note that this will only work if "ExpiresActive On" has been specified and if the resource is actually served with a mime type of application/ld+json specified.

[deeper]

Thanks for your fast answer.

if the JSON-LD snippet is inserted in your page, it will be compressed and cached if and as the containing document is compressed/cached, so this ExpiresByType directive would be irrelevant.

The JSON-LD snippets exists directly in my page code (body, not head), like any img-tag or <p></p> with text. The JSON-LD is wrapped in script-tags, like usual for this kind of stuff (structured data):

<script type="application/ld+json">
 {
 "@context": "http://schema.org",
 "@type": "Person",
 .......
 </script>

What do you mean with "containing document"? The Wordpress-page? But isn't it normal to have the cached stuff within the page, like jpgs?

Right now, my htaccess looks like this:

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/x-icon "access plus 1 year"
ExpiresByType image/jpg "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType video/mp4 "access plus 1 month"
ExpiresByType audio/mpeg "access plus 1 month"
ExpiresByType audio/mp4 "access plus 1 month"
ExpiresByType text/css "access plus 1 week"
ExpiresByType text/rtf "access plus 1 week"
ExpiresByType text/javascript "access plus 1 week"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType application/zip "access plus 1 month"
ExpiresByType application/msword "access plus 1 month"
ExpiresByType application/javascript "access plus 1 week"
ExpiresByType application/x-javascript "access plus 1 week"
</IfModule>

I intend to add a line
ExpiresByType application/ld+json "access plus 1 month"

[phranque]

The JSON-LD snippets exists directly in my page code

and therefore the snippet will get cached with the page in which it is inserted.

What do you mean with "containing document"? The Wordpress-page?

yes

But isn't it normal to have the cached stuff within the page, like jpgs?

images are externally referred urls (via the src attribute) so they are cached independently of the document which refers to them.

I intend to add a line
ExpiresByType application/ld+json "access plus 1 month"

this won't hurt but again it is unnecessary until you are actually serving resources with that mime type.

[deeper]

O.K.... so usually all ExpiresByType-commands refer to external stuff, i.e., the content itsself resides external, like images, which actually are in the uploads-folder of WP, not in my WP-page.

And the containing document, the WP-page, is usually cached automatically by browsers, so I don't need to initiate its cacheing explicitly via htaccess? I guess I could do so if I want to assure a certain caching time or if I want to disable it (access plus 0 seconds).

deeper

[phranque]

And the containing document, the WP-page, is usually cached automatically by browsers, so I don't need to initiate its cacheing explicitly via htaccess?

what cacheing-related HTTP Response headers are you getting for your html pages?
i don't see a setting for text/html in your .htaccess snippet but these headers are likely being generated by a wordpress plugin rather than mod_expires.

[deeper]

Ups, it seems I forgot the most important ExpiresByType-piece.

There is definitely no plugin doing the job. May be my theme doing it? Otherwise I forgot it or there was any other reason why not enabling it. Hm, I created the htaccess years ago.... but why should I drop the html caching there?

How can I check if and what things actually are cached, for example html page?

[phranque]

this describes the intricacies of how caching works:
HTTP Caching [developers.google.com]

you can request your html page using your favorite response header checker tool or browser web developer tool to see what headers are being returned and analyze accordingly.

[deeper]

Using [giftofspeed.com...]
it says:

Non Cached Files:

[domain.de...]
[vg05.met.vgwort.de...] Redirection
[vg05.met.vgwort.de...]

"VGWort" is a tracking pixel.
But what does the mentioning of the requested URL mean? Wordpress html page is not cached?



Using the server header checker at [giftofspeed.com...]
it says:

HTTP/1.1 200 OK
Server: nginx
Date: Fri, 09 Aug 2019 13:36:06 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Link: ; rel="https://api.w.org/"
Link: ; rel=shortlink
Vary: Accept-Encoding

Firefox developer tool says about html document:

Antwortkopfzeilen (433 B)
Kopfzeilen (unformatiert)
Cache-Control: no-cache, must-revalidate, max-age=0 --> WP page is not cached!?
Connection: keep-alive
Content-Encoding. gzip
Content-Type: text/html; charset=UTF-8
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Vary: Accept-Encoding

Anfragekopfzeilen (671 B)
Kopfzeilen (unformatiert)
Accept: text/html,application/xhtml+xm…plication/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate

Seems as if the WP page is not cached at the moment and therefore it's the same with JSON-LD?