PWA Manifest MIME Type – web-app-manifest

  • Resolved woodb01

    (@woodb01)


    4 years, 4 months ago

    I am seeing HUGE load times and delays on my shared host with ONLY the manifest file. That is the only file that is really badly affected. The file size is ridiculously small, and it compresses well so there are no issues there.

    The only problem I can find is related to the MIME Type and the fact that there is no extension associated with it in the current PWA solution.

    Here is what W3C says:

    NOTE: manifest.webmanifest or manifest.json?
    The official file extension for the manifest is .webmanifest. Some web servers recognize this extension and transfer the file using the standardized application manifest MIME type (application/manifest+json). Developers can also choose a different extension (e.g. .json) or none at all (e.g. /api/GetManifest), but are strongly encouraged to transfer the manifest using the application/manifest+json MIME type.

    ===

    How hard would it be to change the file generation to use the .webmanifest extension? This would then allow the application/manifest+json direct association and provide greater processing control through htaccess or at the file server level.

    Does that make sense or is that a wrong assumption?
    If it is worth trying, do you have a suggestion on how I can make a simple change to try this with the .webmanifest extension?

    Thoughts?

Viewing 11 replies - 1 through 11 (of 11 total)
  • Plugin Author Weston Ruter

    (@westonruter)

    The filename itself should not matter. The manifest is being generated as part of the WordPress REST API (/wp-json/wp/v2/web-app-manifest/) since it needs to be dynamic. Do other REST API endpoints respond slowly for you as well, for example /wp-json/wp/v2/posts/?

    Nevertheless, I can see we aren’t doing something recommended: using the application/manifest+json content type. It’s currently using application/json. I’ve filed an issue for that: https://github.com/GoogleChromeLabs/pwa-wp/issues/306

    Nevertheless, this doesn’t explain why the endpoint is responding slowly. Also, the Lighthouse PWA audit does not flag the incorrect content-type as being an issues. Browsers are just fine with application/json.

    Thread Starter woodb01

    (@woodb01)

    Thanks Weston, as you note, W3C accepts the file without an extension. I am just wondering if the lack of an extension causes slow processing by driving through the entire MIME library on a server? Not sure how a server would recognize the file type MIME association for processing?

    It is possible it is conflicting with one of my htaccess optimizations. I have been tweaking the htaccess for performance for the last 5 or 6 years (small tweak here, update there, etc. over several years).

    Later tonight I may use a stripped down htaccess to see if that has any impact on load time for the manifest file. At least then it will confirm or eliminate whether it is in the htaccess file.

    Here is a link to a JPEG image of the manifest load time compared to the rest of the site (waterfall).

    JPG image of manifest load time

    Plugin Author Weston Ruter

    (@westonruter)

    Not sure how a server would recognize the file type MIME association for processing?

    The Content-Type (MIME) is output by PHP itself.

    Make sure you also check other REST API endpoints to see if the respond slowly as well, for example /wp-json/wp/v2/posts/.

    Thread Starter woodb01

    (@woodb01)

    Okay, here is another screen shot. This shows that only the files without an extension are affected by this on the mobile load.

    It is impacting just the manifest file and the error templates which do not have any extension. Maybe it is a file server mis-configuration? Don’t know but it seems to have that extension issue in common (iPhone 8 simulation).

    manifest file load and error templates

    Plugin Author Weston Ruter

    (@westonruter)

    What about requesting /wp-json/wp/v2/posts/?

    Thread Starter woodb01

    (@woodb01)

    Long wait times. On this one however it looks like there is a long wait time for the fav icon which does have a file extension.

    Here is the waterfall from the posts

    json post

    Thread Starter woodb01

    (@woodb01)

    Okay, after more research I’m not sure how much you can do about it. Apparently there is a known performance issue in the WP core related to REST API processing.

    There are a couple of interesting articles on the subject and possible solutions. Even though it looks like it would only work on an individual plugin, maybe adapting something along these lines for PWA might help? Don’t know. I know enough PHP to be dangerous and am not a coder.

    Great overview article:
    REST API performance

    Or this, the second highest vote option looks like it *might* provide a potential solution. Looks like the REST API calls all of WordPress for each call. Unless I am not understanding it, this solution looks like it calls a minimum WordPress instance, processes the API, and then loads the rest of WordPress? Interesting idea.

    SLOW WordPress REST API

    Finally, I saw this article addressing this issue. It is similar to the ones above but has a little different perspective.

    WP REST API too slow

    Thoughts? Could any of this be applied to the PWA plugin to improve REST performance?

    • This reply was modified 4 years, 4 months ago by woodb01.
    Thread Starter woodb01

    (@woodb01)

    By the way Weston, I really appreciate your dedication and commitment to this plugin and to WordPress generally. I’m more than happy to work as a test guinea pig on a possible resolution.

    Plugin Author Weston Ruter

    (@westonruter)

    Thank you. However, since this appears to be a general issue with the REST API on your site and not specifically related to the PWA plugin, finding a resolution here in the PWA plugin support forum isn’t going to work. You’re better off inquiring of general WordPress support.

    Thread Starter woodb01

    (@woodb01)

    Is there a way to cache just the manifest file, with an expiration so that the REST API is not triggered unless a new manifest is needed (date / time only).

    I saw your code on the caching in another post but that does not seem to do much of anything. I’ve set it up and it doesn’t seem to make a difference either way.

    Last, would the AMP plugin with PWA help at all with performance? My theme is already mobile responsive and the layout is good so I don’t need layout adjustments. Only looking for performance improvement.

    Plugin Author Weston Ruter

    (@westonruter)

    Is there a way to cache just the manifest file, with an expiration so that the REST API is not triggered unless a new manifest is needed (date / time only).

    Yes, but that would be in the realm of caching plugins and out of scope for this plugin forum.

    Last, would the AMP plugin with PWA help at all with performance? My theme is already mobile responsive and the layout is good so I don’t need layout adjustments. Only looking for performance improvement.

    The AMP plugin enforces frontend runtime performance, ensuring there is no layout shifting, that hardware-accelerated animations are used, CSS is inlined (and tree-shaken), and that JS is all asynchronous among many other things. You can certainly do all of these things yourself, but without AMP it is difficult to enforce and maintain over time. The AMP plugin includes a validator that detects invalid AMP markup from being output to the page and it tells you where it came from.

    AMP improves performance for first-time loading experience visitors as well as runtime performance while on a page. PWA is all about improving the experience for repeat visitors, especially those whose internet connections are unstable. The AMP plugin integrates with the PWA plugin to ensure that the AMP component scripts are stored in the browser cache.

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘PWA Manifest MIME Type – web-app-manifest’ is closed to new replies.