webpagetest | Salt States to deploy a private Web Page Test instance | Frontend Framework library

Does it mean that WebPageTest will neglect these responses with max-age=0 in static cache checking?

The documentation states that resources which include a specific indication of non-cacheability will not be subject to the 'Cache Static' check:

Applicable Objects

Any non-html object with a mime type of "text/*", "*javascript*" or "image/*" that does not explicitly have an Expires header of 0 or -1, a cache-control header of "private", "no-store" or "no-cache" or a pragma header of "no-cache"

While max-age=0 isn't included in that list, it should be treated the same as no-cache, and is likely being treated the same here and excluding those objects from this check.

Field data and Origin Summary are real world data.

There is the key difference between these metrics and the synthetic test that Page Speed Insights runs.

For example: CLS is measured until page unload in the real world, as mentioned in this explanation on CLS from Addy Osmani who works on Google Chrome.

For this reason your CLS can be high for pages if they perform poorly at certain screen sizes (as Lighthouse / PSI only tests one mobile screen size by default) or if there are things like lazy loading not performing well in the real world and causing layout shifts when things load too slowly.

It could also be certain browsers, connection speeds etc. etc.

Let's assume you have a page that does well in the Lighthouse synthetic test but it performs poorly in the real world at certain screen sizes. How can you identify it?

For that you need to gather Real User Metrics (RUM) data.

RUM data is data gathered in the real world as real users use your site and stored on your server for later analysis / problem identification.

There is an easy way to do this yourself, using the Web Vitals Library.

This allows you to gather CLS, FID, LCP, FCP and TTFB data, which is more than enough to identify pages that perform poorly.

You can pipe the data gathered to your own API, or to Google Analytics for analysis.

If you gather and then combine the web vitals information with User Agent strings (to get the browser and OS) and the browser size information (to get the effective screen size) you can narrow down if the issue is down to a certain browser, a certain screen size, a certain connection speed (as you can see slower connections from high FCP / LCP figures) etc. etc.

Page Speed Insights (PSI) is designed for simulating a first time user to the site, so your cookies popup would always show.

It does not cache cookies or anything else. There is no way to send cookies to PSI.

If you are using Lighthouse in the browser simply untick the "Clear Storage" option in the top bar (you may have to click the gear icon top right to reveal this) and at that point run the page twice (once to set the cache), cookies will be stored and you will record a run with cached images, files etc.

If you wanted to create a run where cookies are stored but nothing else is cached you could go to the application tab in developer tools and remove everything other than the cookies.

However as this is not indicative of a real world scenario I do not see the benefit and is only included as it answers the original question.

Your final option for complete control would be to run Lighthouse CLI on your own machine.

The source code for Lighthouse is available on GitHub, takes a short while to set up, installing chromium etc. but it is worth it.

At that point you have more control, if you partner it with Puppeteer then you have all the control to set individual cookies etc.

However it does appear that you should be able to pass cookies directly to Lighthouse via config according to this thread, but it might not work and ultimately ends up recommending puppeteer. Perhaps that is a feature that will get improved upon soon.

It seems to be the context of this issue.

In your getLocations() try adding this line before the fetch:

let vm = this

then inside your fetch function use:

vm.locationList.push(list); instead of this.locationList.push(list);

Hope it helps. Good luck.

I use html-webpack-plugin inject the output from Webpack into a index.html file.

Assuming you mean you want to inline all those files into one http request of index.html you can use html-webpack-inline-source-plugin to achieve this.

The speed (in seconds, not scores) displayed on the speed test results is very influential on the test server region. The closer the test server region is, the faster the loading time will be.

Example of speed test results for your page, using servers from Australia - Sydney, Canada - Vancouver, and your base location: Brazil - São Paulo, using GTmetrix.

• Australia - Sydney (3,2s)
• Canada - Vancouver (1,9s)
• Brazil - São Paulo (0,8s)

So, it can be concluded LARGE POSSIBLE test server region used by Google Search Console is far from your base location.

By the way, when I open your page from Indonesia, it only takes about 0.9-1.2 seconds. So, congratulations, your page is fast!

Remove the font_awesome_flutter plugin from pubspec.yaml and wherever you are using it in your project.

You can just extract the icons you need from the font and discard the rest. An east way to do this is to use the IcoMoon site. For example I used the site to generate a font with only the Apple logo icon.

Note the code (eabe). You'll use it later.

You get get instructions for doing that here. I called my font family Apple.

To use your icon just use a Text widget with the code as the text and specify the font family that you registered in step 2.

If your video has sound, this will cause a delay in loading. As per the apple developer release notes for Safari 10, ".. videos without audio tracks or with disabled audio tracks can play automatically when the webpage loads". A note is also added on caniuse.com that the autoplay feature is only available to non-audible videos.

You could try putting the muted attribute before the autoplay in your video code, or muting the audio track of your video [in a vid editor] and then re-export/upload a silent version to see if that makes a difference.

Good luck!

The color key is at the top. It just tells you what type of asset is being loaded except for the DNS + connect + ssl which combined together make up the process of establishing the initial connection to a domain.

The Atelier theme doesn't seem to have been centered around performance, but you should still be able to get things loading faster. One thing that you could fix is you can make sure you're only loading the necessary scripts/css for each page. https://www.kaybojesen.dk/wp-content/plugins/instagram-feed/css/sb-instagram.min.css doesn't need to be loaded on the homepage. Some items such as the cookie notice, could be loaded after everything else. Fixing that should give you a big improvement. You can also load the CSS/JS from a CDN. Make sure you're using a good caching plugin if you're not already doing so.

It's easy to spot some of these problems such as the cookie notice loading too early. The tricky part is finding plugins or code snippets that you can use to fix these performance issues.

If you look at the "browser main thread" at the bottom it will tell you what is happening during the "wait" time. According to this, There is a bunch of layout happening. Chrome just needs some time after receiving all of the CSS to process it before it continues loading the page. I think webpagetest's server's are slower than your typical computer, so they spend more time in the wait stage, but it's probably a good idea to optimize for the worst case scenario. Anyhow, that's what the wait is all about.