It has been a little over a week since the last Wahoo (12.00) snapshot, so here is a shiny, new update. ;)

As you might expect, internally work continues apace on Hardware Acceleration and other upcoming features. For this snapshot however the focus is improving stability and as such there are several key crash fixes.

In terms of feedback we primarily interested in any new regressions you notice since the previous Wahoo snapshot (12.00-1301), so please keep on topic and let us know if you find anything.

WARNING: This is a development snapshot: It contains the latest changes, but may also have severe known issues, including crashes, and data loss situations. In fact, it may not work at all.

Download

• Windows
• Mac
• Linux/FreeBSD

...

It's Thursday, and time for another 11.62 snapshot.

As you can see from the changelog it's mainly about stability, but we've also fixed an issue where window controls (resize, minimize, close) would not be available when the menu bar was enabled, and the close button on each tab was disabled.

WARNING: This is a development snapshot: It contains the latest changes, but may also have severe known issues, including crashes, and data loss situations. In fact, it may not work at all.

Download

• Windows
• Mac
• Linux/FreeBSD

Changelog

• CORE-39969 Regex crash
• CORE-41927 documentEditable crash
• CORE-43122 SVG crash
• DSK-355931 No window control buttons on the menu bar when disabling the close button on tabs
• Reverted DSK-346719 [Mac] Crash when zooming with datalist suggestion box open (caused blinking in address field)
• Reverted DSK-356977 Crash when clicking extension button with open popup (caused tabs not to close while popup open)
• Reverted DSK-351582 Crash when writing in address field after bookmark has been deleted (possibly caused a crash on exit)

Permalink | Leave a comment  »

Yesterday I did a workshop at Google Ventures for some of their portfolio companies. I didn’t know how much performance background the audience would have, so I did an overview of everything performance-related starting with my first presentations back in 2007. It was very nostalgic. It has been years since I talked about the best practices from High Performance Web Sites. I reviewed some of those early tips, like Make Fewer HTTP Requests, Add an Expires Header, and Gzip Components.

But I needed to go back even further. Thinking back to before Velocity and WPO existed, I thought I might have to clarify why I focus mostly on frontend performance optimizations. I found my slides that explained the Performance Golden Rule:

80-90% of the end-user response time is spent on the frontend.
Start there.

There were some associated slides that showed the backend and frontend times for popular websites, but the data was old and limited, so I decided to update it. Here are the results.

First is an example waterfall showing the backend/frontend split. This waterfall is for LinkedIn. The “backend” time is the time it takes the server to get the first byte back to the client. This typically includes the bulk of backend processing: database lookups, remote web service calls, stitching together HTML, etc. The “frontend” time is everything else. This includes obvious frontend phases like executing JavaScript and rendering the page. It also includes network time for downloading all the resources referenced in the page. I include this in the frontend time because there’s a great deal web developers can do to reduce this time, such as async script loading, concatenating scripts and stylesheets, and sharding domains.

For some real world results I look at the frontend/backend split for Top 10 websites. The average frontend time is 76%, slightly lower than the 80-90% advertised in the Performance Golden Rule. But remember that these sites have highly optimized frontends, and two of them are search pages (not results) that have very few resources.

For a more typical view I looked at 10 sites ranked around 10,000. The frontend time is 92%, higher than the 76% of the Top 10 sites and even higher than the 80-90% suggested by the Performance Golden Rule.

To bring this rule home to the attendees I showed the backend and frontend times for their websites. The frontend time was 84%. This helped me get their agreement that the longest pole in the tent was frontend performance and that was the place to focus.

Afterward I realized that I have timing information in the HTTP Archive. I generally don’t show these time measurements because I think real user metrics are more accurate, but I calculated the split across all 50,000 websites that are being crawled. The frontend time is 87%.

It’s great to have this updated information that shows the Performance Golden Rule is as accurate now as it was back in 2007, and points to the motivation for focusing on frontend optimizations. If you’re worried about availability and scalability, focus on the backend. But if you’re worried about how long users are waiting for your website to load focusing on the frontend is your best bet.

 

Hey
So as Håvard pointed out we intend to do a 11.6x snapshot every Thursday (as principle), but as this thursdays snapshot had a very bad crash regression when saving files on windows we decided to revert the fix that caused it and throw out a new build today.
We also managed to fix one or 3 more bugs

Please help us find regressions since 11.61 :-)

WARNING: This is a development snapshot: It contains the latest changes, but may also have severe known issues, including crashes, and data loss situations. In fact, it may not work at all.

Download

• Windows
• Mac
• Linux/FreeBSD

Changelog

• Reverted DSK-335820 Opera replaces existing saved files without warning when the File Name field in the Save As dialog does not show the file extension
• DSK-356977 Crash when clicking extension button with open popup
• CORE-32642 Support Ctrl+F5 and Shift+F5 for unconditional reload of web page (bypass cache)

This is an Opera 12 (Wahoo) snapshot.

As you can see from the changelog, this build introduces quite a few fixes, changes and improvements. Since there's a lot of it, I'll highlight a few important things below.

Privacy

This Wahoo build adds support for Do Not Track, which allows browser users to opt out of being tracked on the web. It is currently disabled by default, but can be enabled by enabling the following option in Opera's Preferences dialog: "Preferences > Advanced > Security > Ask websites not to track me"

Note that this will only work if the site actually honors the request. Few sites currently do, and the effect of DNT will have to be evaluated to see if it is a viable solution in the long run.

SSL performance

This build also introduces a first round of optimizations for faster SSL handling (CORE-41667):

• TCP optimization to eliminate roundtrips
• Improved session negotiation to save on waiting times
• Improved connection handling which improves both HTTP and HTTPS connections
• Quicker closing of connections allows for new connections at an earlier stage
• Parallelizing OCSP/CRL uses half as much time to do revocation checking
• Strict transport security improves security and will also improve speed when servers start using this feature

As an example, the first load at skandiabanken.no was reduced by one second or more. With 10 subsequent page loads, the time to open the page was almost cut in half in total.

XHR

With CORE-41784 (XMLHttpRequest Level 2 upload and progress events), we completed our support for progress events in XMLHttpRequest, for upload, download, and timeout update. This will improve the upload experience on Google services (no more Flash uploaders on YouTube and Gmail), and more sites are to follow.

More

There are numerous other improvements, including Core, mail and theme fixes. Take a look at the changelog for more information.

WARNING: This is a development snapshot: It contains the latest changes, but may also have severe known issues, including crashes, and data loss situations. In fact, it may not work at all.

Download

• Windows
• Mac
• Linux/FreeBSD

...

Following up on our Christmas gift we are pleased to offer an updated release of the out of process plug-in and 64-bit Labs builds of Opera. If you just can't wait, head over to the Opera Labs blog, and grab the builds right now!

Please keep sending in your feedback :yes:

WARNING: This is an Opera Labs build: It contains work in progress, which may also have severe known issues, including crashes, and data loss situations. In fact, it may not work at all. Opera Labs builds are not based on current Wahoo snapshot releases.

Here's another 11.62 snapshot. We will probably try to do weekly snapshots of Opera 11.6x every Thursday or so.

While testing, please pay particular attention to the following Core (Presto) fixes:

• CORE-10115 (Hide window.event, attachEvent and detachEvent from visibility (like document.all))
• CORE-24242 (Remove readystatechange events for SCRIPT element (live.com search fields on third-party sites))

If you notice any sites breaking when compared to Opera 11.61, let us know!

Known issues:

• Opera crashes when saving files
  
  WARNING: This is a development snapshot: It contains the latest changes, but may also have severe known issues, including crashes, and data loss situations. In fact, it may not work at all.
  
  Download
  
• Windows
• Mac
• Linux/FreeBSD

Changelog

Core

• CORE-10115 Hide window.event, attachEvent and detachEvent from visibility (like document.all)
• CORE-41951 Crash in svg filter on path without 'd'
• CORE-42489 Cached text-info not recomputed in indirect traversals on font invalidation
• CORE-40953 NO_MODIFICATION_ALLOWED_ERR thrown on modifying SVGElement.className (SVGAnimatedString)
• CORE-42761 Hidden SVG element prevents hover of underlying element in Raphael.js
• CORE-42776 animateTransform + SVG filter not placed correctly
• CORE-43829 Error message when sending mail at centrum.cz
• CORE-43506 POST request for application/x-www-form-urlencoded is always sent as two packets (retry)
• CORE-43285 Clicking to set cursor position after searching a textarea fails, and scrolls to the top instead
• CORE-38412 Some progressive JPEGs aren't decoded properly
• CORE-43893 Crash on setting border-style to hidden on one border of a table row with collapsed borders
• CORE-44335 Qt plugin AVPlayer is crashing Opera
• CORE-44263 Crash when (1<<31).toString(2)
• CORE-43716 Dropdown menu at blocket.se
• CORE-42571 Setting selectedIndex = -1 prevents choosing just one categorie at mercadolibre.cl
• CORE-43684 Overflowing integral addition not computed
• CORE-44291 @include / @exclude filters in UserJS are not respected on change
• CORE-43149 Facebook chat list scrolls back up - setting style on overflow element with generated content
• CORE-24242 Remove readystatechange events for SCRIPT element (live.com search fields on third-party sites)
• CORE-43180 Increased memory usage with iframes in HTML5 parser
• Reverted CORE-44002 Parallel download of script and images

Desktop

• DSK-356060 [Mail] Scrolling and switching views is slow when there are messages with lots of addresses
• DSK-356929 Updated tr/hu/cs language strings
• DSK-337608 Crash on exit after installing Speed Dial extensions
• DSK-355591 Clicking a button on hidden panel crashes Opera
• DSK-298032 Find in page (Ctrl+F) uses last used Find inline type
• DSK-335820 Opera replaces existing file when the the Save As dialog does not show the file extension
• DSK-340816 Address field focus lost on restart when installing extensions with a toolbar button
• DSK-351582 Crash when writing in address field after bookmark has been deleted

Recently I have been working on improvements in the address field. The main UI related complaint was that Opera didn't show the full address any more, even when there is room for it. That was true; in 11.6x versions the length was limited to around 1/3 of the address field length.

As a result, we have replaced the 3 column solution (icon, URL, title) with 2 columns. The first column contains the icon (no, not favicon yet), and the second column contains the text. This text includes the address, page title, and optional page excerpt (when the row contains information provided by history results). In cases where there is not enough space, we still cut the text.

We have also improved bolding rules, and provided new colors.

For bookmarks fans, we have further adjusted bookmark prioritization when ordering them in the drop down.


Please remember that work here is still ongoing, and further improvements are planned.

Known issues

• Further improvements to contrast and formatting are still being considered
• Favicons are not displayed and there is currently no option to bring them back
• Important parts of URLs can be cut off, if there is not enough space
• Mac: Some font rendering issues, and crashes with Web fonts

WARNING: This is a development snapshot: It contains the latest changes, but may also have severe known issues, including crashes, and data loss situations. In fact, it may not work at all.

Download

• Windows
• Mac
• Linux/FreeBSD

...

Hello everyone!

My name is Kristine and I'm an all year round intern in Desktop QA. It’s been 938 days since my last blog post and it's good to be back ;)

We are preparing another maintenance release for 11.6x ‘Tunny’ with some stability fixes. This is a normal Opera release, not Opera Next. All of the below fixes are already in the current Opera Next release.

Known issues

• [Mac] Address field blinks while typing
• [Linux] The 64-Bit build has a different build number but is in fact identical

Download

• Windows
• Mac
• Linux/FreeBSD

...

I started the HTTP Archive back in October 2010. It’s hard to believe it’s been that long. The project is going well:

• The number of websites archived has grown from ~15K to ~55K. (Our goal for this year is 1M!)
• In May we partnered with Blaze.io to launch the HTTP Archive Mobile.
• In June we merged with the Internet Archive.
• Joining the Internet Archive allowed us to accept financial support from our incredible sponsors: Google, Mozilla, New Relic, O’Reilly Media, Etsy, Strangeloop, and dynaTrace Software. Last month Torbit became our newest sponsor.
• As of last week we’ve completely moved to our new data center, ISC.

I’m pleased with how the WPO community has contributed to make the HTTP Archive possible. The project wouldn’t have been possible without Pat Meenan and his ever impressive and growing WebPagetest framework. A number of people have contributed to the open source code including Jonathan Klein, Yusuke Tsutsumi, Carson McDonald, James Byers, Ido Green, Mike Pfirrmann, Guy Leech, and Stephen Hay.

This is our first complete calendar year archiving website statistics. I want to start a tradition of doing an annual recap of insights from the HTTP Archive.

2011 vs 2012

The most noticeable trend during 2011 was the size of websites and resources. Table 1 shows the transfer size of content types for the average website. For example, “379kB” is the total size of images downloaded for an average website. (Since the sample of websites changed during the year, these stats are based on the intersection trends for 11,910 websites that were in every batch run.)

Table 1. Transfer Size by Content Type Jan 2011 Jan 2012 change HTML 31kB 34kB +10% JavaScript 110kB 158kB +44% CSS 26kB 31kB +19% Images 379kB 459kB +21% Flash 71kB 64kB -10% total 638kB 773kB +21%

One takeaway from this data is that images make up a majority of the bytes downloaded for websites (59%). Also, images are the second fastest growing content type for desktop and the #1 fastest growing content type for mobile. These two observations highlight the need for more performance optimizations for images. Many websites would benefit from losslessly compressing their images with existing tools. WebP is another candidate for reducing image size.

A second takeaway is the tremendous growth in JavaScript size – up 44% over the course of the year. The amount of JavaScript grew more than twice as much as the next closest type of content (images). Parsing and executing JavaScript blocks the UI thread and makes websites slower. More JavaScript makes the problem worse. Downloading scripts also causes havoc with website performance, so the fact that the number of scripts on the average page grew from 11 to 13 is also a concern.

On a positive note, the amount of Flash being downloaded dropped 10%. Sadly, the number of sites using Flash only dropped from 44% to 43%, but at least those swfs are downloading faster.

Adoption of Best Practices

I personally love the HTTP Archive for tracking the adoption of web performance best practices. Some trends year-over-year include:

• The percent of resources that had caching headers grew from 42% to 46%. It’s great that the use of caching is increasing, but the fact that 54% of requests still don’t have any caching headers is a missed opportunity.
• Sites using the Google Libraries API jumped from 10% to 16%. Using a CDN with distributed locations and the ability to leverage caching across websites make this a positive for web performance.
• On the downside, websites with at least one redirect grew from 59% to 66%.
• Websites using custom fonts quadrupled from 2% to 8%. I’ve written about the performance dangers of custom fonts. Just today I did a performance analysis of Maui Rippers and discovered the reason the site didn’t render for 6+ seconds was a 280K font file.

It’s compelling to see how best practices are adopted by the top websites as compared to more mainstream websites. Table 2 shows various stats for the top 100 and top 1000 websites, as well as all 53,614 websites in the last batch run.

Table 2. Best Practices for Top 100, Top 1000, All Top 100 Top 1000   All total size 509kB 805kB 962kB total requests 57 90 86 caching headers 70% 58% 42% use Flash 34% 49% 48% custom fonts 6% 9% 8% redirects 57% 69% 65%

The overall trend shows that performance best practices drop dramatically outside of the Top 100 websites. The most significant are:

• Total size goes from 509 kB to 805 kB to 962 kB.
• Total number of HTTP requests is similar growing from 57 to 90 and a small decrease to 86 requests.
• The use of future caching headers is high for the top 100 at 70%, but then drops to 58% and even further to 42%.

The Web has a long tail. It’s not enough for the top sites to have high performance. WPO best practices need to find their way to the next tier of websites and on to the brick-and-mortar, mom-and-pop, and niche sites that we all visit. More awareness, more tools, and more automation are the answer. I can’t wait to read the January 2013 update to this blog post and see how we did. Here’s to a faster and stronger Web in 2012!

Annotations:

• Get your developers - either your agency or IT - thinking in components, if they aren't already. You can componentize at the presentation layer (call them widgets, if you must), at the services level, and at the content level. You should have a strategy at all three levels. If you don't have a services layer, have a sit-down with your IT staff and break the news to them. More devices are coming; more change is on the horizon.

Ook! I'm Dustin Wilson, and I'm a user experience designer for desktop here at Opera. You've probably seen my lurking around here before. I've been with the My Opera community since 2003, and I've been quite a vocal supporter of Opera. I just started working here on the 11th of January, and shortly thereafter I flew out to Oslo to meet and work with everyone. It's been extremely cold and dark, but great. I'm working with a great team, and we have a lot of awesome stuff planned. Fortunately for you all there are some nice design changes coming up! Stay tuned!

Why am I writing this post, then? They just needed a scapegoat person to write an intro to this Opera Next snapshot, and I was readily available and willing to do so. I'm perfectly sure this build contains many worthwhile changes! Have fun testing the build. :D

Known issues

• Crash on start up with saved sessions
• Mail header layout is broken
• Mac: Some font rendering issues, and crashes with Web fonts

WARNING: This is a development snapshot: It contains the latest changes, but may also have severe known issues, including crashes, and data loss situations. In fact, it may not work at all.

Download

• Windows
• Mac
• Linux/FreeBSD

...

We have already introduced address field search suggestions powered by our partners Google (default), Bing, Яндекс (Yandex), and Wikipedia (English only). Now we want our own address field suggestions to meet the same high quality standards as the ones provided by our partners for your bookmarks and history entries.

In our old system; everything including bookmarks was matched against page URL, title, or page content and then ordered in one giant list sorted by last visited time.

The new system assigns a score to each suggestion based on more factors than just the last visited time. For example, we prioritize your bookmarks, the position in the URL where we find a match, and the number of times we get a match on the page.

We are not done yet, and will work on integrating Speed Dials and further improve the scoring system.

What do you think about the new results in the address field? Are we getting you to where you wanted to go?

If you already know exactly where you want to go and don’t care too much about the above improvements; then you will certainly appreciate that we’ve also worked on getting you on your way faster. (Nice segue, huh?) Start-up times and session handling should be snappier in this build. We’ve ironed out a bunch of smaller issues that we think will make a big difference.

PS: There are some other treasures in the change log as well. :pirate:

Known issues

• Mail header layout is broken
• Mac: File uploading, and large network requests never finishes
• Mac: Some font rendering issues and crashes with Web fonts

WARNING: This is a development snapshot: It contains the latest changes, but may also have severe known issues, including crashes, and data loss situations. In fact, it may not work at all.

Download

• Windows
• Mac
• Linux/FreeBSD

...

Opera 11.61 is now available for download.

This is a recommended security and stability update.

Download Opera 11.61
(build 1250)
Changelogs:

• Windows
• Mac
• Linux

This is a Release Candidate for Opera 11.61. Take a look at the changelog for more information about the changes since the previous build.

Download

• Windows
• Mac
• Linux/FreeBSD

Changelog

• CORE-43788 Can't scroll with mouse wheel over iframe with scrolling=no if smooth scrolling is enabled
• CORE-42642 JavaScript crash
• CORE-43273 Opera freezes when loading a big session with the Tab Vault extension
• CORE-42012 Crash in Carakan on WebGL benchmark
• Reverted CORE-43506 POST request for application/x-www-form-urlencoded always sent as two packets
• CORE-41923 [*nix] Vega crash
• DSK-350900 Block the VLC plug-in due to excessive crashing
• DSK-353378 Opera loses advanced download settings after restart
• DSK-353217 [*nix] Red and blue channels swapped when run with a 16-bit color depth
• DSK-350402 Crashes if you unpin the last message in the "Pinned" view
• DSK-355394 Crash when closing mail window
• DSK-350332 Mail unread count is wrong
• DSK-355604 Update opera:about to show 2012

CSSrefresh is a small, unobstructive javascript file that monitors the CSS-files included in your webpage. As soon as you save a CSS-file, the changes are directly implemented, without having to refresh your browser.

Tags: css javascript webdesign

Last night I spoke at the San Francisco JavaScript Meetup. I gave a brand new talk called JavaScript Performance that focuses on script loading and async snippets. The snippet example I chose was the Google Analytics async snippet. The script-loading part of that snippet is only six lines, but a lot of thought and testing went into it. It’s a great prototype to use if you’re creating your own async snippet. I’ll tweet if/when the video of my talk comes out, but in the meantime the slides (Slideshare, pptx) do a good job of relaying the information.

There are two new data points from the presentation that I want to call out in this blog post.

Impact of JavaScript

The presentation starts by suggesting that JavaScript is typically the #1 place to look for making a website faster. My anecdotal experience supports this hypothesis, but I wanted to try to do some quantitative verification. As often happens, I turned to WebPagetest.

I wanted to test the Alexa Top 100 URLs with and without JavaScript. To load these sites withOUT JavaScript I used WebPagetest’s “block” feature. I entered “.js” which tells WebPagetest to ignore every HTTP request with a URL that contains that string. Each website was loaded three times and the median page load time was recorded. I then found the median of all these median page load times.

The median page load with JavaScript is 3.65 seconds. Without JavaScript the page load time drops to 2.487 seconds – a 31% decrease. (Here’s the data in WebPagetest: with JavaScript, without JavaScript.) It’s not a perfect analysis: Some script URLs don’t contain “.js” and inline script blocks are still executed. I think this is a good approximation and I hope to do further experiments to corroborate this finding.

Async Execution Order & Onload

The other new infobyte has to do with the async=true line from the GA async snippet. The purpose of this line is to cause the ga.js script to not block other async scripts from being executed. It turns out that some browsers preserve the execution order of scripts loaded using the insertBefore technique, which is the technique used in the GA snippet:

var ga = document.createElement(‘script’);
ga.type = ‘text/javascript’;
ga.async = true;
ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl’ : ‘http://www’) + ‘.google-analytics.com/ga.js’;
var s = document.getElementsByTagName(‘script’)[0];
s.parentNode.insertBefore(ga, s);

Preserving execution order of async scripts makes the page slower. If the first async script takes a long time to download, all the other async scripts are blocked from executing, even if they download sooner. Executing async scripts immediately as they’re downloaded results in a faster page load time. I knew old versions of Firefox had this issue, and setting async=true fixed the problem. But I wanted to see if any other browsers also preserved execution order of async scripts loaded this way, and whether setting async=true worked.

To answer these questions I created a Browserscope user test called Async Script Execution Order. I tweeted the test URL and got 348 results from 60+ different browsers. (Thanks to all the people that ran the test! I still need results from more mobile browsers so please run the test if you have a browser that’s not covered.) Here’s a snapshot of the results:

The second column shows the results of loading two async scripts with the insertBefore pattern AND setting async=true. The third column shows the results if async is NOT set to true. Green means the scripts execute immediately (good) and red indicates that execution order is preserved (bad).

The results show that Firefox 3.6, OmniWeb 622, and all versions of Opera preserve execution order. Setting async=true successfully makes the async scripts execute immediately in Firefox 3.6 and OmniWeb 622, but not in Opera. Although this fix only applies to a few browsers, its small cost makes it worthwhile. Also, if we get results for more mobile browsers I would expect to find a few more places where the fix is necessary.

I also tested whether these insertBefore-style async scripts block the onload event. The results, shown in the fourth column, are mixed if we include older browsers, but we see that newer browsers generally block the onload event when loading these async scripts – this is true in Android, Chrome, Firefox, iOS, Opera, Safari, and IE 10. This is useful to know if you wonder why you’re still seeing long page load times even after adopting async script loading. It also means that code in your onload handler can’t reliably assume async scripts are loaded because of the many browsers out there that do not block the onload event, including IE 6-9.

And a final shout out to the awesomeness of the Open Source community that makes tools like WebPagetest and Browserscope available – thanks Pat and Lindsey!

It's Friday the 13th, so what better day to stay safely at home and do a bit of testing?

Then again, they say that most accidents happen at home... I think I'll leave it to you to make the decision.

Safe testing!

WARNING: This is a development snapshot: It contains the latest changes, but may also have severe known issues, including crashes, and data loss situations. In fact, it may not work at all.

Download

• Windows
• Mac
• Linux/FreeBSD*

* Note: 64-bit Linux has a higher build number, but it's exactly the same as the other ones. ...