Not really related to your problem, but it hurts my eyes:

• &function(); may break your code. If you learned that from Perl 4 times, learn to get over it. The & form overrides prototype checks in Perl 5, and you usually don't want that. Remote the &. The & is mostly gone in Perl 5, it is only used to take a reference to some routine (my $ref=\&somesub;) or to dereference such a reference (&$somesub(...);). The latter also can be written without the & as $somesub->(...);.
• Indent your code properly. Perl works fine without indenting, but you will soon have problems understanding what happens.
• Properly indenting your code also removes the need to comment closing brackets. It's obvious simply by the ammount of indenting.
• (Not in your code:) If you have so much code inside a pair of brackets that you can not see both the opening and the closing bracket at the same time, consider moving that code into a new subroutine.
• (Personal style:) Don't write non-functions in a way that they look like functions. if is not a function, so leave a space between if and the opening brace.

Compare your code

eval {

local $SIG{ALRM} = sub { die("alarm\n") };

alarm 60;
&parsePageFunction();
alarm 0;
};#eval

if($@) {

if($@ eq "alarm\n") { print("Webpage Timed Out.\n\n"); }#if
else { die($@."\n"); }#else
}#if
[download]

with properly indented code:

eval {
    local $SIG{ALRM} = sub { 
        die("alarm\n");
    };

    alarm 60;
    parsePageFunction();
    alarm 0;
};

if ($@) {
    if ($@ eq "alarm\n") { 
        print("Webpage Timed Out.\n\n");
    } else { 
        die($@."\n");
    }
}
[download]

It doesn't really matter which indent style you use, but use one, and use it always. There is no perfect indent style, so find the one you like best or use the one that your team uses. (My personal preference bases on 1TBS, with only tabulators used for indent, allowing any indent width by modifying the tabulator width.)

Alexander