Can't get 'Block Requests Containing' to work

Web Performance Discuss Test Results
1

Hi

In http://www.webpagetest.org/result/120618_FC_AJ5/

I am using scripting to simulate a logged in user clicking on a thread page.

I’d like to block the following files and see the impact as I suspect they might be impacting UX:

ckeditor.php
ckeditor.js
vbulletin_textedit.js

How do I do this? as doing it in the Block tab doesnt seem to be working for me and I’m not sure how to do it in the script directly.

Here’s the script I am using if that helps:


logData	0
navigate	http://www.thestudentroom.co.uk/signin.php
sleep	5
setValue	name=vb_login_username	username
setValue	name=vb_login_password	password
submitForm	action=login.php?do=login
sleep	5
logData	1
navigate	http://www.thestudentroom.co.uk/showthread.php?t=1579631

Thanks :slight_smile:

2

Sorry, I’ll be a little slow to reply for the next week or so but you can try putting the block command in the script itself:

block	ckeditor texedit

https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/scripting#TOC-block

Certainly looks like a bug on my side that I need to look into though.

3

Try putting the script block command right before your last navigate in the script in case the settings are getting reset between steps (a shot in the dark but possible).

4

Thanks Patrick. That worked great.

Strangely when I block ckeditor.js and then compare in the filmstrip the moment the posts on the page are shown I see that for 50% of the time it is much slower when blocked, and 50% of the time is the same. The good results average 1.7s (same as unblocked). The bad results more like 3s.

How can it be that it takes longer with less stuff there, and only on half the runs? Does that make sense to you?

How does blocking work? is it possible that by blocking something it could hold up the page? I’m wondering if this method is going to help us identify things that are slowing down the page, or if we need to remove these type of things at source for a reliable test. What do you reckon?

In case it helps here are 2 test examples:

Not Blocked: http://www.webpagetest.org/result/120619_M7_PCT/
Blocked: http://www.webpagetest.org/result/120619_W7_P9Q/

Many thanks for your help as always.

5

Blocking basically instantly fails the request but no guarantees that it won’t cause problems with code on the page that is expecting it (javascript exceptions trying to access code that doesn’t exist).

That said, I think it just changed the timing enough that some things that were happening after onload intermittently get started before onload and push it out.

Here is one of the longer load time runs - http://www.webpagetest.org/result/120619_W7_P9Q/5/details/ - the fully loaded time is more inline with the rest of the tests.