I'm using EWW Emacs browser for opening various remote pages(mostly documentation) which is very handy most of the time.
I'm still trying to understand why certain pages take 4-5-6+ seconds to be rendered in eww(which take <1s in Chrome, for comparison).
For my tasks, I only care about the loaded content - images and fancy styles are not needed.
Is there any simple way to speed it up?
Like setting readable mode/disabling images before calling eww? If that's possible at all.
Update from a few weeks later
I made a few experiments and from what I found the biggest contributing factor in my case is when a page has lots of third-party fonts.
I wasn't able to find a way to disable font fetching in eww source code so probably true "text based" browser like w3m was a better solution in the first place.
Any clarification comments and answers are still very welcome.
Related
Any help/advice on this would be greatly appreciated.
I'm looking for what I would consider a standard setup for modern day web design/development. Basically I have a dual monitor setup and I would like to code on one screen and have the changes displayed in real-time on the other screen.
Up until yesterday I was using jsbin in this way and it was working great. I had one browser setup with the coding stuff (HTML/CSS/jQuery) and I then had another separate browser open on the second monitor which updated instantly as I typed. So if I changed a CSS rule for example it was shown in real-time on the second monitor without me having to do ANYTHING. No saving, no refreshing, no switching tabs - NOTHING.
However, for whatever reason jsbin now refuses to update in real-time and it will only show the code changes if I manually refresh the browser. I've emailed jsbin about this but they can't diagnose the issue.
So what I'm looking for is either an online alternative, or a local alternative. However, everything (and I mean EVERYTHING) that I've tried so far can't do what jsbin did.
dabblet.com, jsFiddle.net, liveweave.com, codepen.io, cssdeck.com etc
But all of the above don't offer a second tab/browser that I can move to the second monitor to show the code updates in real-time which is the most important thing.
Surely there must be an easy solution to this? Is it not common to code in this way on 2 monitors whilst developing a website? I'd really appreciate any help on this.
Many thanks
Ben
For local option, Brackets has Live Preview mode.
After you open your project or file for editing, select File -> Live Preview
It launches a browser window, then your changes are reflected as you type, no save or browser refresh needed.
I use Liveweave with my dual monitor setup. I keep the HTML/CSS in my left window/monitor and the JS/Preview in my right monitor. Works great!
So here is my problem:
I have a website coded in xPages that loads iNotes (E-Mail Client) in an iFrame. Problem is that iNotes only works with document mode set to IE8 but I do not want to put the entire page into that document mode. So as it isn’t possible to set different document modes for iframes (at least I read that at microsoft and it didn’t work when I tried it) I thought about using frames where it seems to be (again: read it) possible.
So the question is, will it work? Before spending a lot of hours into a solution that does not, I wanted to ask here. Especially because someone might come up with an even better solution (which would be greatly appreciated!) ...
I have a very large (as in feature-rich) responsive website. It consists of over 150 different UI pages, and so far both rendering and performance on mobile are fine (I'm using an iPhone5 to test, and occasionally other devices).
Except for one page, which I am coding now. Here's the temporary dev URL:
http://www.jungledragon.org/apps/jd3/daylight
On Mobile Safari, this page performance extremely poorly:
- It takes several seconds to load, much slower than all other pages
- Once loaded, a touch scroll can take 5-10 secs to do anything
- Mobile Safari as a whole becomes non responding or close to it
I'm trying to troubleshoot the root cause of the issue, but no luck so far. I cannot reproduce this on any desktop browser using a small viewport, not even on desktop Safari. On the desktop, I've inspected several web debuggers to check for any long-running processes, but found none.
Some explanation on what the page does:
It will try to detect your current location (using alerts I discovered this takes little time)
Based on your current location and the current date, it will calculate the sun times for the day. This too is nearly instant
Based on the suntimes, it will dynamically generate a table, and then finally show it on screen
Here's the what I am seeing in detail on mobile Safari:
The server response is fine, the page loads quickly and shows the site header soon
Next, the content body is blank and stays blank for several seconds (which I cannot explain)
Finally, the suntimes table renders.
This completes the page, yet as of this point, the page as well as the browser are extremely sluggish, scrolling takes forever, and Safari controls are nearly irresponsive. It looks and feels as if the browser can crash any moment.
Based on my research so far, and given fine performance in all other pages on the site, I'm totally in the dark on what causes this.
Edit: Using BrowserStack I did some more tests:
iPhone 4S: no issues
iPhone 5S: no issues
Galaxy SII: no issues
HTC One X: no issues
iPhone 5: same issue as above
So I'm not seeing the issue on any desktop browser, and on no mobile device except for the iPhone 5 (iOS7).
Edit2: adding more findings and explanation based on comments received:
The issue does not seem animation-related. For this I have a number of proof points. A simple proof point is the page does not do any visual rendering that is much different from any of the other 100+ pages on the site which have no performance issue.
The 2nd proof point can be explained by understanding what is going on in this specific page. What happens is this:
The system will detect the current user's time and location. For now assume that the user actually allows location sharing. Using a simple alert, I've been able to proof that location detection is not the bottleneck.
Based on the user's time and location, the daylight periods are calculated. This is done by using the Suncalc JS library (https://github.com/mourner/suncalc).
The Suncalc library returns an array of daylight periods for the given date and location. I render that array as a table with colored background rows. That is all.
Rendering a table with 12 rows and different background colors is not likely to cause such enormous issues. My theory therefore lies in step 2 being the root cause. The Suncalc library has a lot of advanced math in it. I am thinking (without evidence yet) that either my mobile processor is horrible at those kind of operations, and/or the specific calculation for some reason cause a peak in memory usage (or even a leak).
As an additional proof point: once the page is loaded on mobile, use the right arrow next to the date to navigate to "tomorrow". Again you will see the extremely bad performance. During that step, there is no network activity, no location detection, nothing, just calculations and some very simple rendering. This validates my theory that perhaps the issue lies in the calculation.
Sadly, it looks like native Javascript profilers on that platform are non-existent. You may also want to try the Javascript Microtime function referenced in this answer. You will need to seed your script with calls at points where you think the bottleneck might be.
Just ran this through Chrome remote debugger (https://developers.google.com/chrome-developer-tools/docs/remote-debugging) on my S3, and it looks like Modernizr's cancelZoom function (showing up in jd3_0006.js) is getting called recursively too many times or by too broad a selector. I've uploaded the profiles into dropbox: https://www.dropbox.com/s/kubxk44smm6qqkx/jungledragon_debug..zip
You can import them into Chrome's debugger on the "Profiles" tab.
I believe your performance problem centers around the use of navigator.geolocation.getCurrentPosition() in your runMap() function
if (urlDate != null) {
urlPos(latitude,longitude);
} else {
if (navigator.geolocation) {
$(".img-loading").show(100);
navigator.geolocation.getCurrentPosition(successPos, errorPos{maximumAge:600000,timeout:10000});
} else {
errorPos('');
}
}
Consider using watchPosition() instead with a callback which will not halt processing of the script thread. You can cancel the watchPostion() update by using clearWatch()
So I've played with this some more, and ran the "Timeline" feature on Chrome (load this file into your chrome timeline tool: https://www.dropbox.com/s/2vpl6z1ntuk3aqj/TimelineRawData-20140328T105820.json), and it looks like this might be your main problem.
Your scripts and libs (including loading Google Maps and jQuery) are getting evaluated AFTER parsing the HTML and running Google Analytics because they are at the bottom of the body, not head. Unless you have a very good reason to do that, I would recommend moving those to the head.
There seems to be a separate problem with scrolling, but perhaps it will be resolved by this change.
How do you put the Amazon Kindle web browser into Article Mode via HTML or Javascript?
Editor's note: Some pages are not automatically detected as "articles" by the Kindle 3 browser, and give an error message when trying to go into Article mode. What does the Article mode use to determine what portion of the page to display?
Is this related at all to Readability?
http://lifehacker.com/5163401/readability-bookmarklet-quick+formats-pages-for-smoother-text
Actual JavaScript code for Readability, which is heuristic based:
// Study all the paragraphs and find the chunk that has the most <p>'s and keep it:
This also appears to be related to Safari 5's Reader mode. Here is what is required for Safari Reader:
This definitely needs more investigating, but so far, these appear to be the most important factors for Safari’s Reader functionality to kick in:
Use the right markup, i.e. make sure the most important content is wrapped inside a container element. Whether you use <article>, <div> or even <span> doesn’t seem to matter — as long as it’s not <p>.
The content needs to be long enough. Use enough words, use enough paragraphs, use enough punctuation. Every paragraph should have at least 100 characters.
Reader doesn’t work for local documents.
http://www.wired.com/gadgetlab/2010/09/simple-tip-turns-kindle-into-ultimate-news-reader/ - The "f" key feature outlined above or some other feature? Not quite sure what article mode means.
It means that the browser will try to identify if the page you are looking at has a main body of text (is an article), parse it out and then display only that text without clutter and for easy scrolling.
I don't think you can force it via the web page's code
As far as I know, once the website has loaded (and if you are on an specific topic) you can turn on the "Article Mode" from the menu.
I've seen similar JS tools for Chrome too, so I assume it's part of webkit.
Has anyone had experience with MySource Matrix as a content management system? If so, thoughts/opinions/comments?
Thanks in advance.
Absolutely excellent. It takes little while to get used to how it does things with its asset structure, but it is really flexible and powerful. Simple edit interfaces are great too.
Make sure you give it enough hardware. If you want dynamic content without caching you need heaps of grunt to make it hum.
Hands down the best CMS I have ever used. We use it on the Pacific Union College website, as well as many side projects. I am still amazed at all it has to offer compared to other products that are not free.
Give it a good look, and take some time to get past the learning curve, but once you do, it will be more than worth it. :)
I've recently been trying to use it in an organization where many non power users are generating content. - it has many interface bugs and odd behavior, so that many simple tasks (i.e. loading images) often have to be done by an power user (i.e. me).
When you are editing the HTML of page content white space is not preserved. If you where to format the HTML in the WYSIWYG editor, save you changes, and then come back the whitespace you've added will be removed - actually when you switch the WYSIWYG editor into HTML mode it doesn't show you the exact HTML, and does some silly things - like pressing enter inserts non breaking spaces - but doesn't show them until you save and re-enter HTML mode.
it is a number of little details like this which make it generally frustrating to use and disliked by everyone here.