New Tab Page Load Delay



  • Does anyone else notice a significant delay between pressing return to submit a URL request in the address bar, and the browser beginning to actually do anything?

    I am running on a 2015 MBP running Sierra, and I have tried various versions of 1.17 and 1.18. Interestingly, this only seems to happen if you are loading a new domain in a tab.

    For example, new tab, go to google.com = delay present
    already loaded a google.com page, load a different google.com page = no delay present
    switching from google.com to yahoo.com = delay present
    google.com -> yahoo.com, and then BACK to google.com = delay present

    The logging data below was dumped when opening a new tab and then loading this simple html page:

    http://www.december.com/html/demo/telecom.html

    Notable timestamps

    135039.914730 : Enter pressed to request webpage - the following 2 lines are generated

    [94926:775:0325/135039.914730:INFO:cpu_info.cc(50)] Available number of cores: 4
    [94872:775:0325/135039.925764:VERBOSE1:gles2_cmd_decoder.cc(3323)] GL_EXT_packed_depth_stencil supported.

    135044.288048 : Page begins to load (nearly a 4.5 sec delay here, no activity in logs)

    [94926:775:0325/135044.288048:VERBOSE2:prescient_networking_dispatcher.cc(23)] Prefetch DNS: www.december.com

    135044.424767 : Page appears to have loaded completely (page loaded in a fraction of a second)

    BEGIN LOG DATA

    [94874:775:0325/135033.172396:VERBOSE1:HTMLPlugInElement.cpp(521)] OBJECT id="browser-plugin-17" style="width: 100%; height: 100%;" Plugin URL: <null>
    [94874:775:0325/135033.172449:VERBOSE1:HTMLPlugInElement.cpp(522)] Loaded URL: <null>
    [94872:775:0325/135033.184199:VERBOSE1:gles2_cmd_decoder.cc(3323)] GL_EXT_packed_depth_stencil supported.
    [94872:775:0325/135033.280623:VERBOSE1:gles2_cmd_decoder.cc(3323)] GL_EXT_packed_depth_stencil supported.
    [94869:775:0325/135033.383782:VERBOSE1:web_view_private_api.cpp(190)] captureVisibleTab() got image from backing store.
    [94874:775:0325/135033.461555:VERBOSE2:password_generation_agent.cc(252)] Skipping form as it would not be saved
    [94869:775:0325/135038.374482:VERBOSE1:web_view_private_api.cpp(190)] captureVisibleTab() got image from backing store.
    [94874:775:0325/135039.847964:VERBOSE2:password_generation_agent.cc(252)] Skipping form as it would not be saved
    [94926:775:0325/135039.914730:INFO:cpu_info.cc(50)] Available number of cores: 4
    [94872:775:0325/135039.925764:VERBOSE1:gles2_cmd_decoder.cc(3323)] GL_EXT_packed_depth_stencil supported.
    [94926:775:0325/135044.266019:VERBOSE2:password_generation_agent.cc(136)] Password Generation is Enabled
    [94872:775:0325/135044.281855:VERBOSE1:gles2_cmd_decoder.cc(3323)] GL_EXT_packed_depth_stencil supported.
    [94872:775:0325/135044.283454:VERBOSE1:gles2_cmd_decoder.cc(3323)] GL_EXT_packed_depth_stencil supported.
    [94926:775:0325/135044.288048:VERBOSE2:prescient_networking_dispatcher.cc(23)] Prefetch DNS: www.december.com
    [94926:775:0325/135044.288331:VERBOSE2:prescient_networking_dispatcher.cc(23)] Prefetch DNS: www.december.com
    [94926:775:0325/135044.288405:VERBOSE2:prescient_networking_dispatcher.cc(23)] Prefetch DNS: www.december.com
    [94926:775:0325/135044.422619:VERBOSE1:script_context.cc(111)] Created context:
    extension id: (none)
    frame: 0x35eb1561d98
    URL:
    context_type: WEB_PAGE
    effective extension id: (none)
    effective context type: WEB_PAGE
    [94926:775:0325/135044.423713:VERBOSE1:script_context.cc(111)] Created context:
    extension id: (none)
    frame: 0x0
    URL:
    context_type: UNSPECIFIED
    effective extension id: (none)
    effective context type: UNSPECIFIED
    [94926:775:0325/135044.424504:VERBOSE1:dispatcher.cc(421)] Num tracked contexts: 1
    [94926:775:0325/135044.424600:VERBOSE1:script_context.cc(111)] Created context:
    extension id: mpognobbkildjkofajifpdfhcoklimli
    frame: 0x35eb1561d98
    URL:
    context_type: CONTENT_SCRIPT
    effective extension id: mpognobbkildjkofajifpdfhcoklimli
    effective context type: CONTENT_SCRIPT
    [94926:775:0325/135044.424767:VERBOSE1:script_context.cc(111)] Created context:
    extension id: (none)
    frame: 0x0
    URL:
    context_type: UNSPECIFIED
    effective extension id: (none)
    effective context type: UNSPECIFIED



  • I will also add that this delay is not present in any version Firefox, Chrome or Safari that I have tried. I enjoy Vivaldi a great deal aside from this one issue, but this one issue makes it a very frustrating experience for my workflow.


  • Moderator

    @o0beaner: Actually, no. For me, it's instantaneous. But then, I'm on Win10. So perhaps other Mac users can answer.



  • @Ayespy I use Vivaldi on my Windows machine as well, and the delay is not present. This seems isolated to MacOS. I don't have another Mac handy to test either, to see if it is something isolated to my machine.



  • Are any other Mac users able to reproduce this? Or is this just my issue?



  • @o0beaner said in New Tab Page Load Delay:

    http://www.december.com/html/demo/telecom.html

    No, generally sites start loading instantly. Tested this with your link pasted in new tab just now. But for what it's worth I'm still on el capitan.



  • @luetage thanks for your report.

    I got ahold of another system running Sierra and observed the very same delay, and I am wondering if it has to do with the OS version. What version of Vivaldi are you running?

    The other interesting bit that I just discovered is that it happens when dealing with local (vivaldi:// and chrome://) pages as well.

    Would love the devs to weigh in on this.



  • I've had this problem for a long time but very randomly. Diagnosis: "Paroxysmal bradytabia".

    Today I think I found a reason for the delay. I only encounter the delay issue if the driver of my audio interface gets messed up after computer sleep and that is when the delay present in Vivaldi (not in any other browser). Turning the audio interface off and on always resolves the delay issue.

    Interface in question is Roland Duo-Capture EX with driver version 1.02.



  • @pahannes Interesting find, but I definitely don't have any special interface configured on either one of my systems, and it happens immediately after a reboot. If I boot and immediately open Vivaldi, I still see this issue.



  • As an update, I discovered what is going on during the delay.

    The following errors are generated in my machine's syslog before a page loads (each try seems to be on a 1s timeout):

    default 08:06:00.172522 -0500 Vivaldi Helper dnssd_clientstub ConnectToServer: connect()-> No of tries: 1
    default 08:06:01.173999 -0500 Vivaldi Helper dnssd_clientstub ConnectToServer: connect()-> No of tries: 2
    default 08:06:02.178501 -0500 Vivaldi Helper dnssd_clientstub ConnectToServer: connect()-> No of tries: 3
    default 08:06:03.183799 -0500 Vivaldi Helper dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mDNSResponder Socket:23 Err:-1 Errno:1 Operation not permitted

    Vivaldi Helper is trying ot use mDNSResponder without having the rights to do so.

    I read about some other applications having similar issues and having to modify their default sandbox configuration in OSX (this is not ideal; requires root access and disabling System Integrity Protection) so I gave it a shot.

    I modified the mDNSResponder block in /System/Library/Sandbox/Profiles/application.sb from the default of:

    (unless
    (or (entitlement "com.apple.security.network.client")
    (entitlement "com.apple.security.network.server"))
    (deny network-outbound (literal "/private/var/run/mDNSResponder")))

    To:

    (unless
    (or (entitlement "com.apple.security.network.client")
    (entitlement "com.apple.security.network.server")
    (equal? (param "application_bundle_id") "com.vivaldi.Vivaldi")
    (equal? (param "application_bundle_id") "com.vivaldi.Vivaldi.helper"))
    (deny network-outbound (literal "/private/var/run/mDNSResponder")))

    ...but to no avail.



  • I think this is about as far as I can go.

    There is obviously some call that is being made by Vivaldi (and not being reported in the debug logs) that either is not resolving, or is being blocked by the OS for some reason.



  • Anyone have any insight or helpful information? Feedback?



  • I too have significant page load delays. Running Windows 7 with 32Gb RAM, Vivaldi 1.8.770.50 (Stable channel) (32-bit). Looking for solutions now. I recently switched from Firefox for a variety of reasons, and I gradually became very pleased with Vivaldi as an alternative ... until the page-load issue cropped up. I'm not sure how much more delay I can tolerate. If I figure it out, I'll post. If you do, please post!



  • I've seen this. Just wondering do you have "Lazy Load Restored Tabs" enabled? I've noticed my slow downs have typically occurred when the option is enabled... coupled when I have a tab from the same subdomain open.



  • Unfortunately, this doesn't line up with my situation. Turning off lazy load doesn't seem to make a difference, and this happens even when loading about:blank on a brand new tab in a new session.



  • Alright, I just solved this. It has to do with MacOS' sandbox restrictions on mDNSResponder.

    For clarification, this ONLY addresses the delay issue that comes in conjunction with these errors being visible in your system console:

    default 08:06:00.172522 -0500 Vivaldi Helper dnssd_clientstub ConnectToServer: connect()-> No of tries: 1
    default 08:06:01.173999 -0500 Vivaldi Helper dnssd_clientstub ConnectToServer: connect()-> No of tries: 2
    default 08:06:02.178501 -0500 Vivaldi Helper dnssd_clientstub ConnectToServer: connect()-> No of tries: 3
    default 08:06:03.183799 -0500 Vivaldi Helper dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mDNSResponder Socket:23 Err:-1 Errno:1 Operation not permitted

    The fix:

    First of all, this requires System Integrity Protection (SIP) to be turned off, and I find that to be ridiculous for getting a browser to work correctly.

    Anyway:

    sudo vi sudo vi /usr/share/sandbox/mDNSResponder.sb

    find the line that looks identical to the following, and add a new line underneath:

    (allow mach-lookup

    Your new line should look like:

    (global-name "com.vivaldi.Vivaldi.helper")

    This forces mDNSResponder to allow Vivaldi Helper to make lookup requests.



  • Oh, I forgot. You'll also have to kill mDNSResponder to get it to work. The daemon will start again automatically. Just run this in a terminal:

    sudo kill $(ps aux | grep '[m]DNSResponder' | awk '{print $2}')


  • Moderator

    @o0beaner I don't know how I missed this thread but I'm now trying to make sense of what's going on here.

    In addition to Vivaldi, have you ever run into similar issues with Safari, Chrome, Firefox, or any other browser? (You said no previously but would appreciate it if you could confirm that this is still the case without Vivaldi running or being tested at the same time.)

    Is your Internet service IPv4 only or dual stack IPv4/IPv6?

    Does IPv6 actually work on your system? Are you running into a strange situation where DNS queries are returning IPv6 AAAA records but IPv6 routing to your destination is broken? (...and your IPv6 connection is timing out before falling back to IPv4)

    Is your Mac using your home router as its DNS name server or is it sending DNS queries directly to name servers on the Internet?

    I've run into resolver-related issues too with dual-stack IPv4/IPv6 on my Internet firewall/gateway but I've never had to do anything weird/special on my Mac to get them fixed. I'm running OS X 10.11.6.



  • @xyzzy Thanks for your post. I checked my network adapter settings and IPv6 was disabled. I've now enabled it and will keep my fingers crossed. Also upgraded to the most recent version: 1.9.818.49 (Stable channel) (32-bit)

    Regarding comments that this might be Mac only ... nope. I run Windows 7 and experience these delays. Not always, but regularly. Maybe enabling IPv6 will do the trick. Thanks again.


  • Moderator

    @RonOnThePond Sorry. This is the "Mac" forum and I didn't mean to ignore or disrespect any non-Mac users that have joined in. You're all welcome here! :-)

    I actually have a networking/telecom background and only jumped in here because the fix that the OP described should not have been necessary. I also have IPv4 and IPv6 Internet connectivity and have used my Mac (and Vivaldi) IPv4-only and IPv4/IPv6 dual-stack without any issues.

    With regard to your particular situation, have you checked the "simple stuff" like making sure that an extension is not causing you any grief? Things should work just fine if your system is IPv4-only and you have a working IPv4 (or IPv4/IPv6) Internet connection. The only problem that you should encounter is not being able to connect to any IPv6-only sites, and that (today) is a very uncommon problem.

    IPv6 is actually more than 20 years old now and well-supported on modern computer systems, and systems should run just fine with both IPv4 and IPv6 enabled. However, if there are problems in the network path, whether its a misconfiguration somewhere, a problematic network device, a routing issue, DNS issue, whatever... weird stuff can happen and they can be tedious and painful to troubleshoot. Really "fun" things also happen when you have a fully functional IPv4 network and a partially-broken IPv6 network.

    https://en.wikipedia.org/wiki/IPv6_brokenness_and_DNS_whitelisting
    https://en.wikipedia.org/wiki/Happy_Eyeballs

    IPv6 is the "way of the future" so you'll have to enable it at some point. Before you do, make sure that you have a functional IPv6 firewall between you and the Internet.


Log in to reply
 

Looks like your connection to Vivaldi Forum was lost, please wait while we try to reconnect.