2

We have a performance problem on our site, and we're digging in to correct some rather basic issues -- we know we have many opportunities to improve performance -- this question is about one, in particular.

Our special case is that we intentionally defer loading of one part of our page that is inherently slow until after the stuff users really wants is up and rendered. But tools like NewRelic, and Google PageSpeed all see this as a slow-loading page -- 5+ seconds.

You can see the case at at pubget.com where we display search results for research papers. We allow users get full article and display either "View" or "Buy" buttons depending on some fairly complicated rules (e.g. if their company/university has a subscription to the journal, but there's a lot more) -- these rules take time to calculate. So we load the search results, and then after the page is displayed, we do an AJAX request to get the View/Buy buttons.

The actual work of figuring out what buttons to display (and where they should link) takes about a second, more or less. It seems like the right thing to do from a user experience standpoint, but I wonder if it affects how users and Google sees our site.

(If you do look at the page, you'll see any number of other equally important things we're doing wrong. I know about these and we're going to fix them.)

3 Answers 3

1

It sounds like you're taking the right approach for your users by deferring the button loading if this is a particularly slow part. But doing this doesn't speed up the overall page load, it simply improves the user experience; so the tools you mentioned are correctly reporting your slow load times.

You said you're aware of other areas you need to improve, I'd focus on these. From a quick glance at your site I'd say the number of HTTP requests and poor time to first byte are your main problems, so work on those.

1
  • Thanks Tim. Yeah we have many fixes and simplifications in the queue so mostly curious if user experience was in conflict in any way with site performance as seem by google. I would still go for better user experience :-) Apr 5, 2013 at 20:46
0

It looks like the right approach as Tim Fountain is writing. Having had a look at Google's Page Speed tool and webapagetest.org, I would see the issues in other places than those buttons:

Google Page Speed

webpagetest.org

Both tools show that the first request takes already longer than one second. Also advertisement slows down the page as well.

Coming back to your button question - how about renaming the buttons to "Get PDF" and do the decision on click or on mouse over? This way your main page will be faster and Google will probably like it a bit better.

0

Presumably only logged in users would be able to download without buying, so you could cut the calculation out entirely for many visitors (and crawlers) with a simple rule up front like:

if (loggedIn!=yes) then displayButton(buy) else calcRules(buyOrSell)

This way crawlers & external visitors won't have to wait for you to run queries that will never relate to them. It won't help as much for logged-in users, but it sounds like you've accommodated for that with your AJAX already.

2
  • We do as much short-circuit logic as possible, but there are still many complex rules that apply differently not only by user but also by article. Apr 5, 2013 at 20:51
  • Can the "many complex rules" be evaluated server-side against each result before sending any HTML? Or have you benchmarked the "many complex rules" and found that evaluating them noticeably slows down the initial page load? Apr 16, 2016 at 0:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.