Why is creating a window slower than reloading it
Asked Answered
S

3

14

Context: I'm going to explain the context of this question, but I think that the answer to the question is not very context specific.

I have a background page in chrome a chrome extension. The page does the following:

chrome.commands.onCommand.addListener(function(){
    chrome.windows.create({
        url:"page.html",
        type:'popup'
    });
});

As you can see this creates a new window loading the page.html file from within my extension, when the user triggers the command (by using a hotkey).

The page page.html is a fairly heavy page. It runs a bunch of scripts (all from the extension directory) and a bunch of images (also all from the extension directory).

Punchline of context: The important thing here, is that the page is loading entirely locally. Nothing (until user input) calls out to the internet and it loads just fine when I am offline.

Question:

  • When I load the window by triggering the event, as described above, it takes some time to load, lets say maybe 1.5 seconds. If I then refresh the new window (page.html), it loads in less than .5 seconds. What is causing this difference in time?
  • How could I capitalize on the faster refresh rate to make my initial page load faster? Could I load a hidden version somehow? Or prerender it somehow? Any suggestions would be appreciated.
Shreeves answered 20/1, 2018 at 5:7 Comment(7)
When you refresh a page you do not need to grab everything again. A lot of the images which take up a lot of the load time can remain. Try it on any website. Refreshing it always faster than opening a new webpageOsteen
That doesn't explain this situation where everything is in a local folder.Shreeves
That local folder I am assuming is not in RAM until it is called upon. So loading the images from hard disc to RAM takes much more time than if the images are already in RAM even with no network involved. I am assuming chrome also does some sneaky stuff with caching as well and other tricks to make pages load even fasterOsteen
Well, part of it is going to be the overhead of creating the window object in memory (the chrome [meaning window borders, sizers, etc.], render engine, etc.). That doesn't need to happen when reloading.Estafette
evaluating the speed of loading or reloading is fantasy on Windows systems where the captain is everything else(windows 8 ,81,10) and not the application you are interesting in.So random delays will appear even you disable fine or somehow: Windows Firewall,Defender,etc will be something there other than your Chrome to delay. I think similar things happening with other Operating Systems too.On my system with several things MIcrosoft made on by force are disabled i can replicate your situation(unexplain delays) calculating php scripts parsing microsecconds of execution time.i had similar resultsSwollen
What are you using to measure those times? Are you counting the half-seconds yourself?? ... When do you start counting? Are there distinct "milestones" during the load process? (E.g., does it take 0.5 seconds for the window to open? Another 0.5 before things start showing on the screen? and 0.5 for the page to finish rendering?) ... What is the page loading and doing? ... Can we see it? ... Also, what kind of hardware are you testing on? How much CPU? How much RAM? How much of that RAM is free? ...Capstan
@Shreeves Did you find a soluation? I'm desperate to fix that!Wow
B
2

Regarding the first question:

Refreshing a page doesn't cause everything (like rendering engine) to be initialized again. Depending on the implementation of the browser, the browser keeps a lot of resources in cache, and when the same URL is accessed again (page refresh in this case) the resources are loaded from cache, which is faster. Hence causing the difference in time.

Regarding the second question:

@elfin forest's answer may give you some insight.

Bilyeu answered 23/1, 2018 at 7:35 Comment(4)
When you say "cache" what exactly are you referring to? It is my understanding that caching merely saves network time. If all the files are already local why would this be be faster?Shreeves
I am referring to the storage of the browser. Yes it does save network time, but it does a lot more than that. When the page loads the first time, irrespective of the page is stored locally or in some server, the browser caches (or stores) some parts of the page (depending on its implementation) it is storage. So when the page loads next time (in your case it is refresh) it gets the page from its memory, rather than locally. Fetching data from cache is faster than fetching it locally. You can see (and clear) the size of the build up cache.(technipages.com/google-chrome-clear-cache)Bilyeu
@WaleedIqbal what do you mean with "@elfin forest's answer may give you some insight"? Can't see the answer or anything that tells how to speed up window creation. Would greatly appreciate a solution!Wow
Seems like his answer is deleted now.Bilyeu
P
1

If you do a right click on Reload button when developer tools are open, then you get three options.

Normal reload

It is the default(pressing F5). This will use the cache but revalidate everything during page load, looking for "304 Not Modified" response. If the browser can avoid re-downloading cached JavaScript files, images, text files, etc. then it will. That probably is the reason why you are getting the difference in speed.

Hard reload

Does not use anything in the cache when making the request. It forces the browser to re-download every JavaScript file, image, text file, etc.

Empty Cache and Hard Reload

This is the third option, and it clears the cache and then reloads.

Try the remaining two forms of reload, and then please report if the speed difference is still noticeable.

Paucker answered 29/1, 2018 at 12:36 Comment(0)
D
-1

When you refresh the Page, Google already has all of the data it needs to get to run the script. This means that when you refrsh the script, all it has to do is run thus removing the 1 second it needs to collect the data.

Deafanddumb answered 29/1, 2018 at 19:28 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.