17 ms·

Building a Shop with Sub-Second Page Loads: Lessons Learned

271 points by DivineTraube 10y ago

deleted 10y ago
[deleted]
CurlyBraces 10y ago
This must be really frustrating when your startup gets so much attention that your shop breaks down and you end up making no money out of that
- DivineTraube 10y ago
  And it not only hurts because of revenue. Slow sites also let users preceive quality and credibility as lower (Fogg et al. 2001; Bouch, Kuchinsky, and Bhatti 2000). The startup/brand will end up being seen as less interesting and attractive (Ramsay, Barbesi, and Preece 1998; Skadberg and Kimmel 2004). So being slow or offline can even have a long-lasting negative impact on the coolness of your startup.
  - dahdum 10y ago
    The site is taking 10+ seconds on the "createTransaction" call when trying to checkout right now.
    - DivineTraube 10y ago
      Unfortunately on the server that method executes a synchronous API call to Paypal Plus, which has very flaky response times.
  - stonogo 10y ago
    Do you have any references dating after mobile browsing became ubiquitous? People have definitely adjusted to shitty cellular connections. I have severe concerns whether these studies from pre-iphone eras are of any modern value.
    - DivineTraube 10y ago
      Sure. There is an abundance of studies. My favourites are [1]: -100ms of additional page load time cost 1% revenue (Amazon) -400ms means -9% vistors (Yahoo) -Showing 30 search results instead of 10 and therefore accepting 500ms of additional page load time means traffic goes back by 20% (Google) -Every second of page load time reduces conversions by 7% There are many more. There is a nice infographic summarizing a few more studies in a nice way [2]. In fact, I think the trend is quite the opposite: as devices and connections get better, people start to expect that websites are very responsive and load fast. [1] http://www.baqend.com/product.html http://www.baqend.com/product.html [2] http://infographicjournal.com/wp-content/uploads/2016/02/How-Page-Speed-Impacts-your-Sales1.png http://infographicjournal.com/wp-content/uploads/2016/02/How...
      - icebraining 10y ago
        The first and third are from 2006 and the second is from 2008 or earlier, so they don't seem to fit with stonogo's request for references after mobile browsing became ubiquitous (the iPhone only came out in 2007, and the first Android only in late 2008).
        DivineTraube 10y ago
        How about Googles Doubleclick (2016): 53% of mobile site visits are abandoned if pages take longer than 3 seconds to load [1]. Mobify (2016): For every 100ms decrease in homepage load speed, Mobify's customer base saw a 1.11% lift in session based conversion, amounting to an average annual revenue increase of $376,789. Similarly, for every 100ms decrease in checkout page load speed, Mobify's customers saw a 1.55% life in session based conversion, amounting to an average annual revenue increase of $526,147 [2]. Staples (2014): conversion increase per second [3]. Or the Obama campaign (2012): making the page 60% faster increased donations by 14% [4]. More new studies from recent years can be found at WPO stats [5]. [1] https://www.doubleclickbygoogle.com/articles/mobile-speed-matters/ https://www.doubleclickbygoogle.com/articles/mobile-speed-ma... [2] http://resources.mobify.com/2016-Q2-mobile-insights-benchmark-report.html http://resources.mobify.com/2016-Q2-mobile-insights-benchmar... [3] http://de.slideshare.net/cliffcrocker/velocity-ny-how-to-measure-revenue-in-milliseconds#stats-panel http://de.slideshare.net/cliffcrocker/velocity-ny-how-to-mea... [4] http://kylerush.net/blog/meet-the-obama-campaigns-250-million-fundraising-platform/ http://kylerush.net/blog/meet-the-obama-campaigns-250-millio... [5] https://wpostats.com/ https://wpostats.com/
- user5994461 10y ago
  Personal story (P.S. I am not the author, I just worked in startups as well): For me it didn't, especially when we were not prepared for it, and we know that we couldn't take the traffic if it happened. What really killed me instead, was when our site was slowish or half-fucked during some events. And people still managed to use it harder and harder for the entire day. And we made unusual loads of money and new customers, with a crap site xD There is of course a feeling of "how much did we miss out? that must be a lot considering how much we did get.", but it's less prominent than the feeling of "how the hell did all these people manage to pay us at all? and why the fuck did they keep using the site?". That does contradict every known blog and article out there about people just leaving.
meta_AU 10y ago
5ms average load latency. But the max looked like it was more than 5 seconds.
- DivineTraube 10y ago
  The JMeter load tests were conducted to test the throughput of the CDN and backend setup (browser caching was disabled). The load generating servers where hosted in Frankfurt (Germany) where the CDN (Fastly) also has an edge location. This lead to average response time of 5ms. We experienced some hickups within JMeter causing single requests to stall up to 5 seconds. For the 10 million requests we got an 99.9th percentile of below 10ms. We couldn't quite figure out why JMeter had these hiccups, maybe those were GC pauses, maybe something else, but it was consistent across different setups and servers.
  - greglindahl 10y ago
    One wonders about the irony of carefully avoiding bad stuff (like GC) when serving pages, and then using a test rig that has potential GC delays to test performance.
    - erikwitt 10y ago
      You have a point there. I found jMeter, however, really easy to use. I could simply let it monitor my browser (via a proxy) while i clicked through the website and the checkout process to record the requests of an average user. Then I configured the checkout process to only be executed in 20% of the cases to simulate the conversion rate. Even executing the test distributed over 20 servers wasn't that hard. Which tools would you use to generate this amount of traffic?
      - greglindahl 10y ago
        In a previous life we started with ApacheBench, and then wrote our own async perl benchmarker because we wanted to generate steady hits-per-second instead of ApacheBench's N concurrent requests at a time. By now there's probably a tool out there that does what our custom tool did.
inian 10y ago
We also realised that tackling web performance takes a lot of effort..so have been building different tools which can automate front end optimization techniques. Our recent tool (https://dexecure.com https://dexecure.com) tackles image optimization by generating different formats (WebP, JPEG XR), different sizes of images and compressed to different qualities depending on the device and browser the user is using. All of the images are served with a fast HTTP/2 connection. We have seen people integrate with it in under 5 minutes and cut down their page size by 40%!
- deleted 10y ago
  [deleted]
- rkwz 10y ago
  +1 Images are a great starting point for improving page load performance as they sometimes represent a big chunk of the total page weight.
meira 10y ago
I Look at it only to criticise but it is really fast, congrats.
dahdum 10y ago
Great info on how to optimize. However, in basket, I clicked "Zur Kasse" to checkout, and the response took 11.08 seconds to get to the checkout page per Chrome network tab. Repeated multiple times with same result. Also, I don't see any product detail pages, categories, search result pages, or anything other than 7 products on the homepage that add directly to cart. Does this strategy scale to regular ecommerce site levels?
- DivineTraube 10y ago
  You're pointing out an important point: third-party services have to be fast, too. The call that starts the checkout does a synchronous request to Paypal Plus, which has very ugly request latencies from time to time. The shop is indeed quite minimal at this time. The optimizations scale very well to regular ecommerce sites, though. Detail pages and categories can be cached very well, as they only change by actions of human editors. A notable exception are recommendations. If they are item-based (e.g. a-priori algorithm) they can also be cached very well. If they are user-based (e.g. collaborative filtering) that part has to be fetched from the server-side recommendation model. The same is true for search results. The heavy-hitters, i.e. the most-searched-for keywords are cached, while the others are fetched from the database. That is the part where server-side scalability and latency optimization is of utmost importance. At Baqend we support both MongoDB full text indexes and automatic separate indexing in an ElasticSearch cluster with automatic CDN and browser caching for the most frequent search results.
  - dahdum 10y ago
    Why do you need to call Paypal before the payment selection screen? Still happening for me, and there is no visible feedback when you click checkout. It just looks broken for 10 seconds. The rest of it is so well done, but I have to wonder how many sales were lost because of this checkout issue.
    - DivineTraube 10y ago
      You're absolutely right, latency in the checkout process is a conversion killer. Somehow Paypal currently seems broken, maybe it's still related to the Dyn DDOS attacks which took Paypal down completely. During our testing, Paypal had latencies of ~100-500ms but these new latency outiers of 10 seconds are a no-go. We will definitely change the code to make that API call asnychronous. Generally Paypal Plus is still quite buggy and not well documented.
user5994461 10y ago
> Furthermore, browser caching is highly effective and should always be used. It fits in all three optimization categories because cached resources do not have to be loaded from the server in the first place. That is incorrect. The browser issues requests for all cachable content with a last-modified-date [or similar special metadata], the webserver replies with a 304-not-modified + empty body, if the file was not updated. There are still HTTP requests sent, there is still network latency, there is still server processing involved. [Worst case scenario: For tiny JS/css/icon files, the latency might dominate everything and nullify the benefits of caching]. It gets more complex: Since a few years ago, Firefox stopped issuing HTTP requests ENTIRELY for some cached content. It speeds the load time but it causes caching issues. Last I checked, chrome and IE didn't adopt this behavior yet. That may or may not chance in the (near?) future. P.S. I felt like being pedantic about caching tonight. Otherwise, a nice article =)
- nimrody 10y ago
  > There are still requests sent, there is still network latency. [In the case of small JS/css/icon files, the latency can be as much as the transfer time]. What? When the "Expires" header indicates the item is still valid the browser should use the cached object without making any requests. Some servers (Rails for example) just serve assets with "Expires" set to some distant future time. When they want to expire these files, they simply change the name (hence the long numeric suffix appended to js/css/etc. files)
  - jandrese 10y ago
    Yeah, I was wondering why I bother to set the expires header if the browser is going to ignore it and check every time anyway.
    - user5994461 10y ago
      To give a hint to the cache manager about when to remove the file from its storage ;)
    - idunno246 10y ago
sotojuan 10y ago
Very good view to an often ignored part of web development. And as usual, the Medium posts loads way slower than the actual website.
diafygi 10y ago
I work in energy, and there's a saying: "The cheapest kwh is one you don't use." Want to make your website faster? Don't send so much stuff. Removing unnecessary code or content from your site has always had the biggest impact on performance. Unfortunately, it seems that often the people in charge of increasing performance aren't the people who get to choose what has to be on the website. The Website Obesity Crisis: https://vimeo.com/147806338 https://vimeo.com/147806338 I want to share with you my simple two-step secret to improving the performance of any website. 1. Make sure that the most important elements of the page download and render first. 2. Stop.
- blaze33 10y ago
  100% this, there is a nice presentation about the bloated web but I couldn't find it now. Remember that performance is a feature: https://blog.codinghorror.com/performance-is-a-feature/ https://blog.codinghorror.com/performance-is-a-feature/ That being said having a fast loading site and being able to serve a spike in load are two different issues (even if having fast loading pages in the first place obviously helps). Also don't forget that measuring (page size/response times/etc.) is the the first step. You can't optimize what you don't know!
- sotojuan 10y ago
  Here's an easy way to do it: Want to make your website faster? Use a 3G connection when developing or testing. Chrome Dev Tools make this easy and you can also adjust the latency as needed.
  - DivineTraube 10y ago
    That should be done a lot more than it's usual today. Part of "mobile first" should be testing mobile speed. One problem is of course that mobile networks vary greatly in both latency and bandwidth. A great resource on performance considerations for mobile networks is Ilya Grigoriks open book [1]. [1] https://hpbn.co/mobile-networks/ https://hpbn.co/mobile-networks/
  - acqq 10y ago
    Use 2G connection to really feel the pain. More often than I'd like, I'm trying to read different content "on the go," on the places where the environment blocks the 3G signal and I'm left with the "E" on the iPhone. There are pages that will load (like HN) and the pages that are just "forget it it will never even load." That's the difference between "accessible" and "shiny but just forget it with the slow internet." I don't use blockers. It seems that's why they are becoming necessary?
CydeWeys 10y ago
It's interesting to me that the website "thinks.com" is entirely in German. I'm used to seeing sites on .com in English, and indeed I can't even think of another site right now that isn't. Why didn't you use the .de ccTLD? Given that most German websites are not using .com domains, isn't this potentially confusing, and causing you to lose traffic? You don't even own thinks.de; it's blank.
- haylem 10y ago
  You're mistaken. A lot of businesses in many countries use .com addresses even for their local shops. For one othing, .com stands for "commercial". .us is for USA. Regarding whether it's right to do so or not is another question. For starters, it depends on the regulations of each country, as in some of them you simply are not allowed to operate under a different TLD. But most countries are not this restrictive. One of the many things that were supposed to "make sense" at the dawn of the web, and that were quickly abused and evolved into more than what anyone could possibly have thought of at first. (No, no, I'm not thinking of HTTP at all while writing this. Why would I?)
- icebraining 10y ago
  I'm used to seeing sites on .com in English, and indeed I can't even think of another site right now that isn't. If you mostly frequent English sites, that's not surprising, but in reality many .com sites are not in English. Some reasons include restrictive ccTLD rules (for example, until 2012 you couldn't register a .pt domain, only .com.pt/.org.pt/etc), better recognition of the TLD by users and SEO. Some examples from the top 200 sites: http://baidu.com http://baidu.com, http://qq.com http://qq.com, http://taobao.com http://taobao.com, http://sohu.com http://sohu.com, http://naver.com http://naver.com, http://coccoc.com http://coccoc.com, http://globo.com http://globo.com
- markdown 10y ago
  .com domains are usually cheaper and usually much easier to register than ccTLD's. In my country, the ccTLD costs more than double the .com equivalent, and requires manual intervention to set up. I have to wait for a guy (and it's just one guy who's been handling it for over a decade) to show up for work on Monday, go through his emails, finish his coffee, and then manually set up my DNS. Given the above, .com's are always the first choice.
nucotano 10y ago
I feel concerned by this new trend of using slow languages/stacks and the "we'll fix it later" mantra. I can't believe there are webpages such as reddit with such horribly awful generation times, do their tech guys sleep well at night?
- conorh 10y ago
  This is not a new trend. This is a trend since the dawn of, well, as long as I've been programming, ~20 years now. Turns out that most of the time there are many more important things than your stack or language speed, and yes, often times "fix it later" is the right tradeoff.
  - erikwitt 10y ago
    On the other hand, there are things where "fix it later" just won't work. Especially when it comes to scalability, which has to be considered right from the start to get it right.
    - jis 10y ago
      Security is another one where the "fix it later" mentality leaks in, with the resulting consequences!
      - halostatue 10y ago
        It’s all about the acceptable trade-offs. There are certain things that I am not willing to compromise on security; there are other things where I’m not as concerned. We currently don’t use HTTPS inside our firewall; once you’ve passed our SSL termination, we don’t use SSL again until outbound requests happen that require SSL. Should we? Well, it depends. There are things that I’m concerned about which would recommend it to us, but it’s not part of our current threat model because there are more important problems to solve (within security as well as without).
        jis 10y ago
WhitneyLand 10y ago
Great article Erik et al. Shows how engineering requires grounding in theory, clever implementation, and lots of trial and error. Is there a particular target customer space that you are focused on?
- DivineTraube 10y ago
  We built Baqend around the caching algorithms that we developed at the university. Our goal was to make the performance optimizations applicable to as many contexts a possible. We went for the "serverless" pardigm and backend-as-a-service to accelerate any application (website or app) that uses our APIs and hosting. Currently most of our customers are e-commerce, web and app agencies, startups and software companies that look for web performance in combination with scalability. We're currently getting lots of request from e-commerce, so we are building out our support for shop features (e.g. advanced search, payment, content management). We are developing a Magento plugin to make the transition to our platform and its performance benefits as easy as possible.
kilroy123 10y ago
Great work. When I loaded the page I even thought to myself, oh shit this is fast. One huge problem, with most large platforms for e-commerce stores, they are terrible at speed optimization! For example, I have a store on Shopify and it's basically impossible to do most of what you explained. With Shopify, you can customize HTML / SCSS files with dynamic content. All of which gets compiled on their back-end. You have no access to the final compiled HTML and markup. You're sadly limited in what you can do. It seems you need to have a custom store to really be able to optimize this hard-core.
- merb 10y ago
  they could do even better. I mean something is really bad here, since their uncached css from frankfurt to my house should not take over 100ms. and they also serve images, css and js from the same domain. and they download the text's as a extra request. and somehow http2 doesn't kick in.
- hbrundage 10y ago
  This is largely incorrect. All the front end customizations that this article describes are possible with Shopify because you have complete control over the HTML, JS, and CSS that the platform spits out. While true that you can't "access" the final compiled HTML to edit it, the templates that power your theme are very close to that output, and not hard to change if you're familiar with HTML/CSS. The Javascript optimizations are all completely possible as well but you either have to pick a theme that has been optimized or implement them yourself in your own theme. Shopify also supports AMP and responsive themes (because it's just HTML). It is true that with Shopify or similar platforms you aren't able to make backend choices or implement caching like the article has described, and yes it's true that all the themes in the theme store aren't perfectly optimized for page load time -- but the question really is do you want to do any of this stuff yourself? Shopify has invested years in their platform to make your website as fast as possible for as little money as possible. The themes that Shopify publishes in the theme store undergo huge amounts of performance testing to ensure that you aren't losing money from latency. The platform comprises a world class CDN, and Shopify doesn't charge for bytes through it. The platform uses many layers of backend caching at the data access, logic, and rendering layers to make your shop as responsive as possible if anyone has been to it before. Shopify powers some of the biggest sales on the internet that truly dwarf Good Morning America. The platform is also geographically redundant such that an entire datacenter can fail with only a moment of visible impact to you and your customers. If what I'm saying is true and you don't actually sacrifice that much flexibility on the Shopify platform, why would you choose to have to implement all the above? Another angle is operations: How many people do you think they have monitoring it and ready to respond to any incidents? Shopify serves an order of magnitude more traffic than Baquend saw at the very peak of this occurrence every single minute of the day with a better response time on average. The Shopify platform took an army of engineers 10 years to build so it would seem unlikely that Baquend has all the same features and stability. How much do you think Baquend charged Thinks to build this? Is it more than $29 / month? Source: work at Shopify and built many of these systems.
imaginenore 10y ago
I get pretty bad layout thrashing upon load.
ecommerceguy 10y ago
FWIW there are some clever Magento shops running pretty stout at sub second load times on AWS. Puts Magento back in the upper echelon for carts again, imo.
- thekonqueror 10y ago
  Can you please share some URLs of faster Magento stores? I'm working on a similar project that will offer optimization as a service for e-commerce. I'm curious to see what others are doing.
  - porker 10y ago
    Not a site, but what I've seen that looks really interesting is LiteSpeed's LiteMadge Cache: https://www.litespeedtech.com/solutions/magento-acceleration https://www.litespeedtech.com/solutions/magento-acceleration. Not used, only seen and wanted to understand how it works.
crdb 10y ago
I checked out Baqend ("we" in the article) and the site prevents me from navigating back when I press "back" (I think by injecting itself as the previous page - I'm not really up to date on dark patterns). This is the kind of behaviour that is an auto-no for me when buying B2B, not just by itself but because of what it signals about the company. I recommend you remove it. On the article itself: you can do very fast pages off a relational DB. In one case, the round trip on a Postgres full text search for auto complete on millions of rows from multiple tables was so fast we had to add a 10ms delay - on a $5/month VM.
- daveguy 10y ago
  It looks like the dark pattern they used to get that "no back" behavior is: "open in a new tab". Edit: I stand corrected, link from the article opens in a new tab, so the back issue is moot there. Definitely red flag behavior. Baqend folks, if you are listening, you should fix it, and if it is the default behavior of your framework you should definitely fix it. No one likes hijacked back buttons.
  - crdb 10y ago
    How to replicate: google "Baqend", click on their page (should be top result), press back button, press "back" arrow on browser. Screenshot: http://imgur.com/a/mLXdc http://imgur.com/a/mLXdc Compare with: http://imgur.com/a/UnQOG http://imgur.com/a/UnQOG
    - DivineTraube 10y ago
      Thanks a lot, it's fixed now.
  - erikwitt 10y ago
    That is definitely unintended behavior. We'll fix it! Fortunately, only www.baqend.com has this bug, it's not in our framework.
- DivineTraube 10y ago
  We fixed that problem and deployed it. It turned out to be the iframe with the tutorial app. That sets a new hash with a random todo list id and that captures the back button. It was not intended to keep people on our site. Thanks for pointing the issue out! BTW, I agree, RDBMSs are a great choice if the hot data set fits in main memory and queries are well-optimized through appropriate indexes. Issues usually only start to occur if 1) the data set is too large 2) queries cannot be optimized by the query optimizer and involve full-table scans 3) interleaved transactions contend on few rows.
chetanahuja 10y ago
Oh the irony. The Medium page this blogpost was hosted on is ~3.5MB in size and took ~5 seconds (on my 20Mbps cable internet connection with 11ms ping to cloudfront) to first readable render.
cpcallen 10y ago
I am amazed that it is 2016 and people talk about sub-second page loading times as if it is an accomplishment to be proud of. That it is an accomplishment of a sort (in contrast to the depressing reality of bloated websites everywhere) shows just how badly wrong we have gone. Maybe we should force web devs to go back to dialup; then we'd get sites that have the performance of http://info.cern.ch/hypertext/WWW/TheProject.html http://info.cern.ch/hypertext/WWW/TheProject.html again.

271 points by DivineTraube 10y ago

deleted 10y ago

[deleted]

This must be really frustrating when your startup gets so much attention that your shop breaks down and you end up making no money out of that

DivineTraube 10y ago
And it not only hurts because of revenue. Slow sites also let users preceive quality and credibility as lower (Fogg et al. 2001; Bouch, Kuchinsky, and Bhatti 2000). The startup/brand will end up being seen as less interesting and attractive (Ramsay, Barbesi, and Preece 1998; Skadberg and Kimmel 2004). So being slow or offline can even have a long-lasting negative impact on the coolness of your startup.
- dahdum 10y ago
  The site is taking 10+ seconds on the "createTransaction" call when trying to checkout right now.
  - DivineTraube 10y ago
    Unfortunately on the server that method executes a synchronous API call to Paypal Plus, which has very flaky response times.
- stonogo 10y ago
  Do you have any references dating after mobile browsing became ubiquitous? People have definitely adjusted to shitty cellular connections. I have severe concerns whether these studies from pre-iphone eras are of any modern value.
  - DivineTraube 10y ago
    Sure. There is an abundance of studies. My favourites are [1]: -100ms of additional page load time cost 1% revenue (Amazon) -400ms means -9% vistors (Yahoo) -Showing 30 search results instead of 10 and therefore accepting 500ms of additional page load time means traffic goes back by 20% (Google) -Every second of page load time reduces conversions by 7% There are many more. There is a nice infographic summarizing a few more studies in a nice way [2]. In fact, I think the trend is quite the opposite: as devices and connections get better, people start to expect that websites are very responsive and load fast. [1] http://www.baqend.com/product.html http://www.baqend.com/product.html [2] http://infographicjournal.com/wp-content/uploads/2016/02/How-Page-Speed-Impacts-your-Sales1.png http://infographicjournal.com/wp-content/uploads/2016/02/How...
    - icebraining 10y ago
      The first and third are from 2006 and the second is from 2008 or earlier, so they don't seem to fit with stonogo's request for references after mobile browsing became ubiquitous (the iPhone only came out in 2007, and the first Android only in late 2008).
      - DivineTraube 10y ago
        How about Googles Doubleclick (2016): 53% of mobile site visits are abandoned if pages take longer than 3 seconds to load [1]. Mobify (2016): For every 100ms decrease in homepage load speed, Mobify's customer base saw a 1.11% lift in session based conversion, amounting to an average annual revenue increase of $376,789. Similarly, for every 100ms decrease in checkout page load speed, Mobify's customers saw a 1.55% life in session based conversion, amounting to an average annual revenue increase of $526,147 [2]. Staples (2014): conversion increase per second [3]. Or the Obama campaign (2012): making the page 60% faster increased donations by 14% [4]. More new studies from recent years can be found at WPO stats [5]. [1] https://www.doubleclickbygoogle.com/articles/mobile-speed-matters/ https://www.doubleclickbygoogle.com/articles/mobile-speed-ma... [2] http://resources.mobify.com/2016-Q2-mobile-insights-benchmark-report.html http://resources.mobify.com/2016-Q2-mobile-insights-benchmar... [3] http://de.slideshare.net/cliffcrocker/velocity-ny-how-to-measure-revenue-in-milliseconds#stats-panel http://de.slideshare.net/cliffcrocker/velocity-ny-how-to-mea... [4] http://kylerush.net/blog/meet-the-obama-campaigns-250-million-fundraising-platform/ http://kylerush.net/blog/meet-the-obama-campaigns-250-millio... [5] https://wpostats.com/ https://wpostats.com/
user5994461 10y ago
Personal story (P.S. I am not the author, I just worked in startups as well): For me it didn't, especially when we were not prepared for it, and we know that we couldn't take the traffic if it happened. What really killed me instead, was when our site was slowish or half-fucked during some events. And people still managed to use it harder and harder for the entire day. And we made unusual loads of money and new customers, with a crap site xD There is of course a feeling of "how much did we miss out? that must be a lot considering how much we did get.", but it's less prominent than the feeling of "how the hell did all these people manage to pay us at all? and why the fuck did they keep using the site?". That does contradict every known blog and article out there about people just leaving.

meta_AU 10y ago

5ms average load latency. But the max looked like it was more than 5 seconds.

DivineTraube 10y ago
The JMeter load tests were conducted to test the throughput of the CDN and backend setup (browser caching was disabled). The load generating servers where hosted in Frankfurt (Germany) where the CDN (Fastly) also has an edge location. This lead to average response time of 5ms. We experienced some hickups within JMeter causing single requests to stall up to 5 seconds. For the 10 million requests we got an 99.9th percentile of below 10ms. We couldn't quite figure out why JMeter had these hiccups, maybe those were GC pauses, maybe something else, but it was consistent across different setups and servers.
- greglindahl 10y ago
  One wonders about the irony of carefully avoiding bad stuff (like GC) when serving pages, and then using a test rig that has potential GC delays to test performance.
  - erikwitt 10y ago
    You have a point there. I found jMeter, however, really easy to use. I could simply let it monitor my browser (via a proxy) while i clicked through the website and the checkout process to record the requests of an average user. Then I configured the checkout process to only be executed in 20% of the cases to simulate the conversion rate. Even executing the test distributed over 20 servers wasn't that hard. Which tools would you use to generate this amount of traffic?
    - greglindahl 10y ago
      In a previous life we started with ApacheBench, and then wrote our own async perl benchmarker because we wanted to generate steady hits-per-second instead of ApacheBench's N concurrent requests at a time. By now there's probably a tool out there that does what our custom tool did.

inian 10y ago

We also realised that tackling web performance takes a lot of effort..so have been building different tools which can automate front end optimization techniques. Our recent tool (https://dexecure.com https://dexecure.com) tackles image optimization by generating different formats (WebP, JPEG XR), different sizes of images and compressed to different qualities depending on the device and browser the user is using. All of the images are served with a fast HTTP/2 connection. We have seen people integrate with it in under 5 minutes and cut down their page size by 40%!

deleted 10y ago
[deleted]
rkwz 10y ago
+1 Images are a great starting point for improving page load performance as they sometimes represent a big chunk of the total page weight.

meira 10y ago

I Look at it only to criticise but it is really fast, congrats.

dahdum 10y ago

Great info on how to optimize. However, in basket, I clicked "Zur Kasse" to checkout, and the response took 11.08 seconds to get to the checkout page per Chrome network tab. Repeated multiple times with same result. Also, I don't see any product detail pages, categories, search result pages, or anything other than 7 products on the homepage that add directly to cart. Does this strategy scale to regular ecommerce site levels?

DivineTraube 10y ago
You're pointing out an important point: third-party services have to be fast, too. The call that starts the checkout does a synchronous request to Paypal Plus, which has very ugly request latencies from time to time. The shop is indeed quite minimal at this time. The optimizations scale very well to regular ecommerce sites, though. Detail pages and categories can be cached very well, as they only change by actions of human editors. A notable exception are recommendations. If they are item-based (e.g. a-priori algorithm) they can also be cached very well. If they are user-based (e.g. collaborative filtering) that part has to be fetched from the server-side recommendation model. The same is true for search results. The heavy-hitters, i.e. the most-searched-for keywords are cached, while the others are fetched from the database. That is the part where server-side scalability and latency optimization is of utmost importance. At Baqend we support both MongoDB full text indexes and automatic separate indexing in an ElasticSearch cluster with automatic CDN and browser caching for the most frequent search results.
- dahdum 10y ago
  Why do you need to call Paypal before the payment selection screen? Still happening for me, and there is no visible feedback when you click checkout. It just looks broken for 10 seconds. The rest of it is so well done, but I have to wonder how many sales were lost because of this checkout issue.
  - DivineTraube 10y ago
    You're absolutely right, latency in the checkout process is a conversion killer. Somehow Paypal currently seems broken, maybe it's still related to the Dyn DDOS attacks which took Paypal down completely. During our testing, Paypal had latencies of ~100-500ms but these new latency outiers of 10 seconds are a no-go. We will definitely change the code to make that API call asnychronous. Generally Paypal Plus is still quite buggy and not well documented.

user5994461 10y ago

> Furthermore, browser caching is highly effective and should always be used. It fits in all three optimization categories because cached resources do not have to be loaded from the server in the first place. That is incorrect. The browser issues requests for all cachable content with a last-modified-date [or similar special metadata], the webserver replies with a 304-not-modified + empty body, if the file was not updated. There are still HTTP requests sent, there is still network latency, there is still server processing involved. [Worst case scenario: For tiny JS/css/icon files, the latency might dominate everything and nullify the benefits of caching]. It gets more complex: Since a few years ago, Firefox stopped issuing HTTP requests ENTIRELY for some cached content. It speeds the load time but it causes caching issues. Last I checked, chrome and IE didn't adopt this behavior yet. That may or may not chance in the (near?) future. P.S. I felt like being pedantic about caching tonight. Otherwise, a nice article =)

nimrody 10y ago
> There are still requests sent, there is still network latency. [In the case of small JS/css/icon files, the latency can be as much as the transfer time]. What? When the "Expires" header indicates the item is still valid the browser should use the cached object without making any requests. Some servers (Rails for example) just serve assets with "Expires" set to some distant future time. When they want to expire these files, they simply change the name (hence the long numeric suffix appended to js/css/etc. files)
- jandrese 10y ago
  Yeah, I was wondering why I bother to set the expires header if the browser is going to ignore it and check every time anyway.
  - user5994461 10y ago
    To give a hint to the cache manager about when to remove the file from its storage ;)
  - idunno246 10y ago

sotojuan 10y ago

Very good view to an often ignored part of web development. And as usual, the Medium posts loads way slower than the actual website.

diafygi 10y ago

I work in energy, and there's a saying: "The cheapest kwh is one you don't use." Want to make your website faster? Don't send so much stuff. Removing unnecessary code or content from your site has always had the biggest impact on performance. Unfortunately, it seems that often the people in charge of increasing performance aren't the people who get to choose what has to be on the website. The Website Obesity Crisis: https://vimeo.com/147806338 https://vimeo.com/147806338 I want to share with you my simple two-step secret to improving the performance of any website. 1. Make sure that the most important elements of the page download and render first. 2. Stop.

blaze33 10y ago
100% this, there is a nice presentation about the bloated web but I couldn't find it now. Remember that performance is a feature: https://blog.codinghorror.com/performance-is-a-feature/ https://blog.codinghorror.com/performance-is-a-feature/ That being said having a fast loading site and being able to serve a spike in load are two different issues (even if having fast loading pages in the first place obviously helps). Also don't forget that measuring (page size/response times/etc.) is the the first step. You can't optimize what you don't know!
sotojuan 10y ago
Here's an easy way to do it: Want to make your website faster? Use a 3G connection when developing or testing. Chrome Dev Tools make this easy and you can also adjust the latency as needed.
- DivineTraube 10y ago
  That should be done a lot more than it's usual today. Part of "mobile first" should be testing mobile speed. One problem is of course that mobile networks vary greatly in both latency and bandwidth. A great resource on performance considerations for mobile networks is Ilya Grigoriks open book [1]. [1] https://hpbn.co/mobile-networks/ https://hpbn.co/mobile-networks/
- acqq 10y ago
  Use 2G connection to really feel the pain. More often than I'd like, I'm trying to read different content "on the go," on the places where the environment blocks the 3G signal and I'm left with the "E" on the iPhone. There are pages that will load (like HN) and the pages that are just "forget it it will never even load." That's the difference between "accessible" and "shiny but just forget it with the slow internet." I don't use blockers. It seems that's why they are becoming necessary?

CydeWeys 10y ago

It's interesting to me that the website "thinks.com" is entirely in German. I'm used to seeing sites on .com in English, and indeed I can't even think of another site right now that isn't. Why didn't you use the .de ccTLD? Given that most German websites are not using .com domains, isn't this potentially confusing, and causing you to lose traffic? You don't even own thinks.de; it's blank.

haylem 10y ago
You're mistaken. A lot of businesses in many countries use .com addresses even for their local shops. For one othing, .com stands for "commercial". .us is for USA. Regarding whether it's right to do so or not is another question. For starters, it depends on the regulations of each country, as in some of them you simply are not allowed to operate under a different TLD. But most countries are not this restrictive. One of the many things that were supposed to "make sense" at the dawn of the web, and that were quickly abused and evolved into more than what anyone could possibly have thought of at first. (No, no, I'm not thinking of HTTP at all while writing this. Why would I?)
icebraining 10y ago
I'm used to seeing sites on .com in English, and indeed I can't even think of another site right now that isn't. If you mostly frequent English sites, that's not surprising, but in reality many .com sites are not in English. Some reasons include restrictive ccTLD rules (for example, until 2012 you couldn't register a .pt domain, only .com.pt/.org.pt/etc), better recognition of the TLD by users and SEO. Some examples from the top 200 sites: http://baidu.com http://baidu.com, http://qq.com http://qq.com, http://taobao.com http://taobao.com, http://sohu.com http://sohu.com, http://naver.com http://naver.com, http://coccoc.com http://coccoc.com, http://globo.com http://globo.com
markdown 10y ago
.com domains are usually cheaper and usually much easier to register than ccTLD's. In my country, the ccTLD costs more than double the .com equivalent, and requires manual intervention to set up. I have to wait for a guy (and it's just one guy who's been handling it for over a decade) to show up for work on Monday, go through his emails, finish his coffee, and then manually set up my DNS. Given the above, .com's are always the first choice.

nucotano 10y ago

I feel concerned by this new trend of using slow languages/stacks and the "we'll fix it later" mantra. I can't believe there are webpages such as reddit with such horribly awful generation times, do their tech guys sleep well at night?

conorh 10y ago
This is not a new trend. This is a trend since the dawn of, well, as long as I've been programming, ~20 years now. Turns out that most of the time there are many more important things than your stack or language speed, and yes, often times "fix it later" is the right tradeoff.
- erikwitt 10y ago
  On the other hand, there are things where "fix it later" just won't work. Especially when it comes to scalability, which has to be considered right from the start to get it right.
  - jis 10y ago
    Security is another one where the "fix it later" mentality leaks in, with the resulting consequences!
    - halostatue 10y ago
      It’s all about the acceptable trade-offs. There are certain things that I am not willing to compromise on security; there are other things where I’m not as concerned. We currently don’t use HTTPS inside our firewall; once you’ve passed our SSL termination, we don’t use SSL again until outbound requests happen that require SSL. Should we? Well, it depends. There are things that I’m concerned about which would recommend it to us, but it’s not part of our current threat model because there are more important problems to solve (within security as well as without).
      - jis 10y ago

WhitneyLand 10y ago

Great article Erik et al. Shows how engineering requires grounding in theory, clever implementation, and lots of trial and error. Is there a particular target customer space that you are focused on?

DivineTraube 10y ago
We built Baqend around the caching algorithms that we developed at the university. Our goal was to make the performance optimizations applicable to as many contexts a possible. We went for the "serverless" pardigm and backend-as-a-service to accelerate any application (website or app) that uses our APIs and hosting. Currently most of our customers are e-commerce, web and app agencies, startups and software companies that look for web performance in combination with scalability. We're currently getting lots of request from e-commerce, so we are building out our support for shop features (e.g. advanced search, payment, content management). We are developing a Magento plugin to make the transition to our platform and its performance benefits as easy as possible.

kilroy123 10y ago

Great work. When I loaded the page I even thought to myself, oh shit this is fast. One huge problem, with most large platforms for e-commerce stores, they are terrible at speed optimization! For example, I have a store on Shopify and it's basically impossible to do most of what you explained. With Shopify, you can customize HTML / SCSS files with dynamic content. All of which gets compiled on their back-end. You have no access to the final compiled HTML and markup. You're sadly limited in what you can do. It seems you need to have a custom store to really be able to optimize this hard-core.

merb 10y ago
they could do even better. I mean something is really bad here, since their uncached css from frankfurt to my house should not take over 100ms. and they also serve images, css and js from the same domain. and they download the text's as a extra request. and somehow http2 doesn't kick in.
hbrundage 10y ago
This is largely incorrect. All the front end customizations that this article describes are possible with Shopify because you have complete control over the HTML, JS, and CSS that the platform spits out. While true that you can't "access" the final compiled HTML to edit it, the templates that power your theme are very close to that output, and not hard to change if you're familiar with HTML/CSS. The Javascript optimizations are all completely possible as well but you either have to pick a theme that has been optimized or implement them yourself in your own theme. Shopify also supports AMP and responsive themes (because it's just HTML). It is true that with Shopify or similar platforms you aren't able to make backend choices or implement caching like the article has described, and yes it's true that all the themes in the theme store aren't perfectly optimized for page load time -- but the question really is do you want to do any of this stuff yourself? Shopify has invested years in their platform to make your website as fast as possible for as little money as possible. The themes that Shopify publishes in the theme store undergo huge amounts of performance testing to ensure that you aren't losing money from latency. The platform comprises a world class CDN, and Shopify doesn't charge for bytes through it. The platform uses many layers of backend caching at the data access, logic, and rendering layers to make your shop as responsive as possible if anyone has been to it before. Shopify powers some of the biggest sales on the internet that truly dwarf Good Morning America. The platform is also geographically redundant such that an entire datacenter can fail with only a moment of visible impact to you and your customers. If what I'm saying is true and you don't actually sacrifice that much flexibility on the Shopify platform, why would you choose to have to implement all the above? Another angle is operations: How many people do you think they have monitoring it and ready to respond to any incidents? Shopify serves an order of magnitude more traffic than Baquend saw at the very peak of this occurrence every single minute of the day with a better response time on average. The Shopify platform took an army of engineers 10 years to build so it would seem unlikely that Baquend has all the same features and stability. How much do you think Baquend charged Thinks to build this? Is it more than $29 / month? Source: work at Shopify and built many of these systems.

imaginenore 10y ago

I get pretty bad layout thrashing upon load.

ecommerceguy 10y ago

FWIW there are some clever Magento shops running pretty stout at sub second load times on AWS. Puts Magento back in the upper echelon for carts again, imo.

thekonqueror 10y ago
Can you please share some URLs of faster Magento stores? I'm working on a similar project that will offer optimization as a service for e-commerce. I'm curious to see what others are doing.
- porker 10y ago
  Not a site, but what I've seen that looks really interesting is LiteSpeed's LiteMadge Cache: https://www.litespeedtech.com/solutions/magento-acceleration https://www.litespeedtech.com/solutions/magento-acceleration. Not used, only seen and wanted to understand how it works.

crdb 10y ago

I checked out Baqend ("we" in the article) and the site prevents me from navigating back when I press "back" (I think by injecting itself as the previous page - I'm not really up to date on dark patterns). This is the kind of behaviour that is an auto-no for me when buying B2B, not just by itself but because of what it signals about the company. I recommend you remove it. On the article itself: you can do very fast pages off a relational DB. In one case, the round trip on a Postgres full text search for auto complete on millions of rows from multiple tables was so fast we had to add a 10ms delay - on a $5/month VM.

daveguy 10y ago
It looks like the dark pattern they used to get that "no back" behavior is: "open in a new tab". Edit: I stand corrected, link from the article opens in a new tab, so the back issue is moot there. Definitely red flag behavior. Baqend folks, if you are listening, you should fix it, and if it is the default behavior of your framework you should definitely fix it. No one likes hijacked back buttons.
- crdb 10y ago
  How to replicate: google "Baqend", click on their page (should be top result), press back button, press "back" arrow on browser. Screenshot: http://imgur.com/a/mLXdc http://imgur.com/a/mLXdc Compare with: http://imgur.com/a/UnQOG http://imgur.com/a/UnQOG
  - DivineTraube 10y ago
    Thanks a lot, it's fixed now.
- erikwitt 10y ago
  That is definitely unintended behavior. We'll fix it! Fortunately, only www.baqend.com has this bug, it's not in our framework.
DivineTraube 10y ago
We fixed that problem and deployed it. It turned out to be the iframe with the tutorial app. That sets a new hash with a random todo list id and that captures the back button. It was not intended to keep people on our site. Thanks for pointing the issue out! BTW, I agree, RDBMSs are a great choice if the hot data set fits in main memory and queries are well-optimized through appropriate indexes. Issues usually only start to occur if 1) the data set is too large 2) queries cannot be optimized by the query optimizer and involve full-table scans 3) interleaved transactions contend on few rows.

chetanahuja 10y ago

Oh the irony. The Medium page this blogpost was hosted on is ~3.5MB in size and took ~5 seconds (on my 20Mbps cable internet connection with 11ms ping to cloudfront) to first readable render.

cpcallen 10y ago

I am amazed that it is 2016 and people talk about sub-second page loading times as if it is an accomplishment to be proud of. That it is an accomplishment of a sort (in contrast to the depressing reality of bloated websites everywhere) shows just how badly wrong we have gone. Maybe we should force web devs to go back to dialup; then we'd get sites that have the performance of http://info.cern.ch/hypertext/WWW/TheProject.html http://info.cern.ch/hypertext/WWW/TheProject.html again.